Portál AbcLinuxu, 4. května 2025 02:09
Aktuální verze vývojového jádra: 3.17-rc7. Citáty týdne. Foo přes UDP.
Vývojové jádro 3.17-rc7 vyšlo dne 28. září (oznámení) místo finální verze 3.17, které měl Linus v plánu. Linus k tomu řekl:
Není to proto, že by se stalo něco obzvlášť děsivého, ale upřímně řečeno, všechno jsem jen neuklidnilo tak, jak jsem doufal. I když by mi s ohledem na cestovní plány vyhovovalo, kdybych zvládl kratší cyklus vydání než obvykle, „pohodlí“ mezi kritéria vydání nepatří. Co se dá dělat.
Stabilní aktualizace: minulý týden nebyly vydány žádné stabilní aktualizace a žádná neprochází v době vzniku tohoto textu procesem kontroly.
V podstatě [je checkpatch] v pořádku jako nástroj, který upozorňuje na podmnožinu kódu, která by mohla stát za pozornost; dává ale nesprávně pozitivní i nesprávně negativní výsledky. Pokud jich však není moc, je užitečný. Za předpokladu, že nenahrazuje váš vkus. Tedy „Hele, upozorňuje na tyhle řádky; mrkneme na to, něco z toho by mohlo stát za pozornost.“, a ne „Nejsvětější orákulum promluvilo; udělej, co ti přikazuje.“
– Al Viro (odkaz)
Ve zdrojovém kódu jádra je v podstatě 1 milion „selhání“ při checkpatchi, opravdu je chceme všechny vyčistit, plýtvat přenosovou kapacitou recenzentů a správců a tvářit se, že těchto 1 milion čištění je stejně důležitých jako „ostatní“ práce, která probíhá na jádru?
– Ingo Molnar (odkaz)
Sice mi to vzalo trochu času, naučil jsem se ale jednu cennou techniku ladění:
#undef EINVAL #define EINVAL __LINE__
– Hugh Dickins (odkaz)
Tunelovací protokoly jsou v uspořádání moderních sítí stále důležitější. Díky provázání vzdálených sítí umožňují vytváření virtuálních privátních sítí, přístup k portům skrytým obvykle za firewallem a další. Tunelování může probíhat na více vrstvách úrovních; tunely SSH jsou implementovány prostřednictvím protokolu TCP, zatímco protokoly jako GRE nebo IPIP pracují přímo na úrovni protokolu IP. Zajímavé však je stále častější zájem o tunelování v rámci protokolu UDP. Oprava „foo over UDP“ (FOU) od Toma Herberta, která byla zahrnuta do dalšího stromu verze jádra 3.18, implementuje tunelování na úrovni UDP obecným způsobem.
Proč UDP? V podstatě všechna existující síťová rozhraní zahrnují hardwarovou podporu UDP, která zajišťuje podrobnosti jako kontrolní součty. UDP dodává jen tolik informací (konkrétně čísla portů), aby bylo směrování zapouzdřených paketů snadné. UDP může rovněž pracovat s protokoly jako RSS (Receive Side Scaling) nebo ECMP (Equal-cost multipath routing protocol) ke zlepšení výkonu ve vysoce propojené konfiguraci. Tunelování UDP nabízí tolik výhod, že si někteří vývojáři myslí, že se v následujících letech bude používat úplně všude.
Zapouzdření a tunelování paketů pomocí protokolu UDP je celkem snadno pochopitelný koncept. Předpokládejme, že je tunelovému rozhraní předložen jednoduchý paket TCP:
Tento paket má obvyklou hlavičku IP a TCP, následovanou daty, která chce uživatel odeslat. Proces zapouzdření udělá něco takového:
V tuto chvíli vypadá paket jako paket UDP, ve kterém je náhodou ukrytý paket TCP. Systém ho teď může přenést do cíle jako obyčejný paket UDP; na straně příjemce budou přidané hlavičky odstraněny a původní paket se vloží do zásobníku sítě.
Konfigurace tunelu FOU bude obvykle dvoustupňový proces. Odesílající a přijímací strany jsou oddělené. Toto řešení mimo jiné umožňuje asymetrickou konfiguraci, pokud by ji někdo potřeboval. Konfigurace na straně příjmu spočívá jen v nastavení portu UDP tak, aby se stal příjemcem zapouzdřených paketů. Nový dílčí příkaz „fou“ má následující tvar:
ip fou add port 5555 ipproto 4
Tento příkaz odstaví port 5555 s tím, že přicházející pakety budou mít protokol 4, tedy zapouzdření protokolu IP. Paketům přijatým na daném portu je odstraněno zapouzdření; potom jsou předány zpět do síťového zásobníku k doručení do skutečného cíle.
Situace je trochu složitější na vysílající straně, vzhledem k tomu, že musí být nastavena cílová adresa a přenos musí spolupracovat s existujícími protokoly zapouzdření. Typický příkaz může vypadat takto:
ip link add name tun1 type ipip \ remote 192.168.1.1 local 192.168.1.2 ttl 225 \ encap fou encap-sport auto encap-dport 5555
Tento příkaz vytvoří nové virtuální rozhraní (tun1) nakonfigurované pro zapouzdření IPIP. Zdrojový port pro pakety je ponechán na rozhodnutí síťového zásobníku, ale cílový port bude 5555. Uživatel samozřejmě musí zapouzdření protokolu přimět, aby toto rozhraní použilo. Nyní byla podpora této funkčnosti přidána do protokolů IPIP, SIT (tunelovacího protokolu propojujícího sítě IPv4 a IPv6) a GRE (používá se pro virtuální privátní sítě).
Některé údaje zveřejněné v sadě oprav ukazují na významné zvýšení výkonu protokolů SIT a IPIP; výkon s protokolem GRE je zhruba srovnatelný s případy nevyužívajícími FOU. Tato funkce tedy má jasný potenciál urychlit tunelování díky využití výhod stávajících optimalizací kolem odesílání a příjmu pomocí protokolu UDP. Pěkné na tom je, že nevyžaduje žádnou speciální hardwarovou podporu; stávající hardware dokáže UDP zpracovat dobře. Jedná se tedy o jednoduché řešení, které bude fungovat ve stávajících systémech – a mělo by být k dispozici ve finální verzi jádra 3.18.
Může mi někdo prosím ujasnit smysl ip-fou? Proč se nenastavují oba endpointy jako IPIP s UDP enkapsulací, stejně jako to máme u gre/gretap/sit/..?
Dovedu si představit zjednoduššení klientské části, ale není to pak jen snadná náplast pro "složitost" použití IPIP rozhraní? Jak se klient pak má vypořádat s více tunnely od různých serverů (nebo různých portů stejného serveru)?
Chápu význam samotné UDP enkapsulace a použití nad libovolným tunnelem, jen nechápu nutnost "ip fou".
Díky.
Může mi někdo prosím ujasnit smysl ip-fou? Proč se nenastavují oba endpointy jako IPIP s UDP enkapsulací, stejně jako to máme u gre/gretap/sit/..?
Můžete trochu rozvést, co konkrétně tím myslíte?
Jak se klient pak má vypořádat s více tunnely od různých serverů (nebo různých portů stejného serveru)?
V čem konkrétně vidíte problém?
Můžete trochu rozvést, co konkrétně tím myslíte?
(níže se odkazuji na původní mail)
Konkrétně nechápu rozdělení na "RX" a "TX" části, kdy se každá konfiguruje jinak. Např. klasický IPIP tunel se konfiguruje jako:
strojA$ ip link add tunel type ipip remote 2.2.2.2 local 1.1.1.1 strojB$ ip link add tunel type ipip remote 1.1.1.1 local 2.2.2.2
A to je vše. Jednoduchá enkapsulace přidáním jedné IP hlavičky.
Pokud jsem dobře pochopil, rychlostní benefity odkazovaného patchsetu spočívají v tom, že routery/switche/síťovky počítají s tím, že nad IP je buď TCP nebo UDP, ale ne už další IP - fungovat budou, ale nebudou asi moci použít hardwarové optimalizace. Řešením je tedy zabalit provoz do ještě jedné UDP hlavičky - to bych si představoval jako (cca):
strojA$ ip link add tunel type ipip remote 2.2.2.2 local 1.1.1.1 \
encap udp encap-sport 1111 encap-dport 2222
strojB$ ip link add tunel type ipip remote 1.1.1.1 local 2.2.2.2
encap udp encap-sport 2222 encap-dport 1111
Má otázka tedy je - proč se to neudělalo takto jednodušše? Proč se přidávalo celé nové API pro iproute2 s vlastní sadou příkazů?
V čem konkrétně vidíte problém?
Když si čtu původní článek znovu, nedochází mi, proč by "ip fou" měl vůbec existovat. Chápu myšlenku odstranění enkapsulace a vražení zpět do síťového stacku, ale nechápu použití. Proč tu enkapsulaci nedovede rozbalit kód tunelu? Původní email se zmiňuje, že to rozbalení dělá XFRM, tak proč nebylo použito rozhraní ip-xfrm?
Nevím, přijde mi to jako příliš nepodstatný a primitivní "hack" na to, aby měl vlastní API. Nebo se mi naopak líbí ten jednoduchý nápad a nechápu, proč je implementace limitována na IPIP - např. na několika místech používám gretap a zvýšení výkonu enkapsulací do UDP bych uvítal.
Díky.
Sice mi to vzalo trochu času, naučil jsem se ale jednu cennou techniku ladění:#undef EINVAL #define EINVAL __LINE__
To by nesměly být v jádře soubory, které mají víc než 4095 (MAX_ERRNO) řádků.
Oboje. :-)
Purista by asi používal paket pro označení celého IP paketu s UDP protokolem a datagram pro samotnou UDP hlavičku a payload, ale ono je to většinou jedno. Buď je to jasné z kontextu nebo je stejně lepší explicitně napsat, co má člověk na mysli.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.