Názory k článku Záhada síťové černé díry: když ping funguje, ale data neprojdou

Nedávno jsem tohle řešil na serveru s 2x VPN (OpenVPN + Wireguard). Říkám tomu porod. Komplikovaný porod trojčat.

já zas s ppoe + 6in4

Teda nevim ....

ale ping -s je jedna z prvnich veci ktery zkousim kdyz je nekde nejakej problem ... a samo je ta size vzdy nasobne vetsi nez predpokladana maximalni MTU. Specielne v kombinaci s -f to celkem dobre odhali spolehlivost toho spoje.

Jinak nefukcni v6 kvuli 150tiletym postupum kopirovanym z hentoho internetu na tema "a zakazte icmp" sem videl osobne mnohokrate. Ona totiz spousta soudruhu netusi, ze u v6 neni arp, a misto toho je tam prave icmp.

Jo, obcas se s timhle taky potkam. Dnes uz tedy podstatne mene casto nez drive.

Pekne jednoduse a jasne popsane. Diky.

Já se s tím tedy nesetkal nikdy.

Mně tohle dělá hotspot z Androidu pořád (O2 mobilní data).

Nemělo by tyhle ICMP unreachable pustit pravidlo "iptables ... -m state --state related ..."?

Jinak připomenu že i PPPoE je tunel, takže tenhle problém se týká kdejaké domácí linky.

A na mikrotiku je kouzelné pravidlo "clamp mss to pmtu" ale aby fungovalo tak musí napřed fungovat path MTU discovery.

No a konkretne na Mikrotiku PMTUD nebude fungovat na IPSec tuneloch, pretoze to nie su interfaces, ale policies.

Pokud spravujete firewall, berte ICMP nikoliv jako bezpečnostní hrozbu, ale jako kritickou infrastrukturu.

Kdyby to vedel kazdy.
Co kdyz treba externi firma udela bezpecnostni audit. Delaji to tak, aby mohli rict, ze nasli "az 20 chyb, z toho 5 kritickych" a management chce, aby se veci opravili. A pritom jsou kriticke chyby i treba to, ze prez traceroute zjisti jak vypada sit a daji to do diagramu. Nebo ze kdyz maji utocnici klientovu cookie, tak vidi jeho data. Nebo ze si session drzime dele, takze utocnik s klientovou cookie ma vice casu nez kdyby se vyzadoval login kazdou hodinu. Sem tam se najde i zranitelnost, ale je to spis vyjimka a kazdy vi, ze se vybiraji firmy, co naleznou vice nez 1 vec.

A kdyz se nekdo ohradi, tak je reakce jako "chceme udelat vsechno proto, aby nas nehackli".

Pohroma ve forme preskolenych lidi z uradu prace ktere jen kontrolujou papiry nebo spusti pentest scan aniz by vedeli co to znamena je zlo.
Jedine co plati je dokumentovat a kdyz se problem kvuli "bezpecnosti" obevi tak odpalit z archivu dokumentaci k manazerum.
Moji zbrani je dlouha pamet archivu alias "protoze jste to tak chteli".

Nikdy plošně neblokujte ICMP. Typy 3 (Destination Unreachable) a 4 (Fragmentation Needed) jsou pro IPv4 nezbytné. U IPv6 navíc povolte Packet Too Big a Neighbor Discovery — bez nich síť nefunguje vůbec.

Fragmentation Needed není typ 4, ne? Jedná se o kód 4 ICMP typu 3, ne?

Tohle obcas stale vidam. Ani ne tak ne verejnem internetu (myslim si ze byvala nekde dlouho verejne hall of shame) jako v korporatnich sitich. Ne v core ale na nejakych okrajovych castech nebo startup akvizicich.

Díky za pěkný přehled.

Já tohle začal daleko víc řešit spolu s příchodem IPv6, kde si už brány nemůžou pomoct fragmentováním a PMTU s procházejícími PTB (packet-too-big) zprávami jsou velmi důležité. Stejně tak i nasadit zmíněný MSS clamping.

Nicméně většina těch domácích router/modemů (ASUS, TP-Link.. něco od ISP), co jsem viděl, to má dnes rovnou nastavené v pohodě a je to součástí těch základních (uživatelsky neměnných) pravidel. Jak procházení těch ICMP zpráv, tak clamping.
Takže paradoxně, pokud už mi někdo volal, nebo jsem to řešil, tak to bylo v případě, že někdo udělal upgrade, koupil si třeba Mikrotika a začal pak s čistým stolem.. pokud se nepletu, tak i ten úvodní wizard v RouterOS pro rychlou konfiguraci routeru tam ty pravidla na clamping rovnou nepřidá (ale možná se to už změnilo v posledních verzích).

Jinak ještě poznámka, ten MSS clamping funguje logicky jen pro TCP spojení (přepisuje to hlavičku v jeho SYN paketu), ale neřeší to UDP nebo ostatní protokoly.
Takže třeba HTTP/3 resp. QUIC má v sobě rovnou mechanismus RFC 8899 - DPLPMTUD (výborná zkratka ;)), který tohle řeší. Začátek komunikace je natvrdo 1200, pak se to zvýší na délku, co proleze.
Ale někdy se službami nad UDP podobná možnost není, nebo to není úplně ve vaší moci (ať už cesta nebo nějaké implementace na klientech), takže člověk musí pragamticky nastavit natvrdo MTU na straně serveru např. na 1200, aby to prolezlo všemi typy připojení a různých tunelů.

Typicky je pak problém třeba s Wireguardem na různých podivných veřejných pahotspotech. Pozdravujeme například do Českých drah.

Je to tak. Byť já řešil spíš video streaming, tak zrovna Wireguard coby jednoduchý UDP šifrovaný tunel bez dalších škálovacích mechanismů selže při menší PMTU rovnou. I kdyby tam nakrásně fungovalo PTMU discovery end-to-end a nebylo nikde filtrované, tak to vnitřní MTU tunelu je statická konfigurační volba.
A i při použití IPv4, kde se to teoreticky může fragmentovat, tak se ty další fragmenty ze "zbytkovým" payloadem vylikvidují po cestě, protože už to nemá UDP header.

A nejde zdaleka jen o public hot-spoty. Pokud to má být opravdu univerzálně přístupné, tak to chce docela snížit vnitřní MTU na WG tunelu.
viz např. IPv4, IPv6, PPoE, DS-Lite a kombinace https://docs.eduvpn.org/server/v3/wireguard.html#when
Já to leckde třeba sundaval na 1360 (což bylo shodou okoloností stejné jako jejich předchozí proprietární VPNka) a to prolézalo víceméně všude.
Jen bych nešel níž než 1280, což je předepsaná minimální MTU pro IPv6.

Díky za pěkný popis MSS Clampingu a jeho alternativ. Jen je třeba si uvědomit, že ani tohle řešení není univerzální, a zase kvůli nekorekktnímu nastavení některých síťových prvk§. Nedávno (při experimentech s MPTCP) jsme zjistili, že řada směrovačů ve veřejném internetu zahazuje TCP rozšířené hlavičky, kam se optiony jako např. MSS clamping zapisují (nevím proč, ale jsou takové). Přes takové směrovače ani MSS clamping neprojde a je třeba hledat jinou cestu.

Poprosím Martina zda by nerozšířil článek o IPv6 "špecifiká". Nedávno jsem si nedobrovolně rozšířil obzory o MSS clamping na IPv6 kvůli chování Azure cloudu. Třeba xbox.com nebo i skoda-auto.cz. Podle všeho jejich servery (firewall) blokují IPv6 ICPM a nikdy od nich tak nepřijde odpověď. Prostě ignorují "packet too big"🤷‍

Takovy tricek, na ktery jsem prisel, kdyz potrebuju ssh pres vpn a po ceste je nejaky mtu problem: staci zmensit okno terminalu :) On pak nemusi posilat tolik textu a pakety nedosahuji maximalnich velikosti :D

Hall of Shame:
Proč prosím neuvedete onen hříšný server?
Zejména pokud jeho administrace neodpovídá na reporty...
Případně eskalovat reporty výše (třeba případně až někam po CEO), ať takový "bezpečáci" zažijí nějakou "ne zcela bezpečnou chvilku "! :) )

Jsem pro tlačení standardů namísto hacků.