U UDP není nikdy jisté, že projde :). Možné jsou v zásadě dvě cesty:
První varianta je čistější z hlediska vrstvového modelu, druhá bude nejspíše spolehlivější, ale vždycky záleží na konkrétní aplikaci.
*) Ani 1254 není úplně bezpečné, někdo na cestě může do paketů přidávat další hlavičky s volbami.
> *) Ani 1254 není úplně bezpečné, někdo na cestě může do paketů přidávat další hlavičky s volbami
No, já teda nevím, ale IP hlavička je konstantní velikosti při průchodu Internetem, nic se do ní přidávat nemůže, volby mají tu stejnou velikost už od zdroje. (Nebo alespoň nevím o IP option, která by to dělala)
To ale není zásah do IP hlaviček původního paketu.
(minimálně u příchozího konce tunelu bych dokonce tvrdil, že tunelující paket je nově vytvořený paket, který končí svou životnost na konci tunelu a tedy už se jedná spíš o úroveň nad L3, kde se obsah paketu předá aplikační úrovni, která s ním potom něco udělá)
Uz jsem videl, ze Cisco VPN koncentrator propisoval nektere flagy TCP hlavicky z/do vnitrni IP hlavicky. Jedna strana TCP spojeni pak pouzivala Window Scaling, zatimco druha ne.
Cisco ma dokonce pro tyhle "chyby" option, kterym muzete ocurat MTU discovery.
Muzete prochazejicim spojenim navrdro vnutit max. velikost packetu na kterou prijdou.
Cisco VPN koncentrátor není technicky vzato router, ale aplikační brána.
A navíc moc nechápu to přepisování z vnitřní hlavičky do vnější nebo naopak. Pokud se bavíme o standardním routovaném provozu, tak tam žádná vnitřní hlavička není. Taky se třeba nebavíme o NAT, kde se tím taky dalo argumentovat.
Jasně, napsal jsem blbost, omlouvám se. Všechno od IPv6 záhlaví dál se na routerech nepřepisuje, jenom maximálně analyzuje. Správně tedy v hvězdičce u původního příspěvku mělo být uvedeno toto:
*) Ani 1254 není úplně bezpečné, někdo může mít operační systém nastaven tak, aby přidával další volitelné hlavičky.