Problém s fragmenty IPv6

[AltSysRqREISUB]

Mám router ve VM, všechno linux. Do virtuálního routeru je připojeno několik rozhraní, která jsou připojená na ruzné bridge, které jsou připojené na VLANová rozhraní - tady je důležitá asi jen VLAN, přes kterou vytáčím PPPoE.

Pro ověření nastavení používám http://icmpcheckv6.popcount.org/ a všiml jsem si, že mi to teď hlásí chybu s příjmem fragmentů. To bylo s tunelem od HE. Zkontroloval jsem MTU tunelu --- 1472 na VDSL -- a ověřil přes "

Kód: [Vybrat]

ping -s 1424 -M do" a zdálo se to v pořádku. Pak jsem odpojil všechno kromě rozhraní k ISP (odpojením "kabelu" od virtuální síťovky) a vypnul firewall (nftables), ale problém zůstal. Tak jsem vypnul tunel a zapnul IPv6 od O2, ale všechno bylo pořád stejné. Pak jsem použil tcpdump, tak jak je to doporučené na odkazové stránce a fragmenty jsem viděl. Všechno jsem vrátil jak to bylo, a fragmenty opravdu chodí i na tunel od HE. jenže z nějakého důvodu po příchodu na rozhraní tunelu zmizí.

Kód: [Vybrat]

meta nftrace set 1na prerouting, input a forward je už neukazuje, na žádné další rozhraní se nedostanou. Na VPS je vše v pořádku. Ještě je zvláštní, že

Kód: [Vybrat]

ping -s 8000 funguje na i z VPS, ale ten curl jak je popsaný na stránce prostě vytuhne na tomto stavu (na routeru i za ním úplně stejně):

Kód: [Vybrat]

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100     9    0     9    0     0      2      0 --:--:--  0:00:04 --:--:-- 
Ještě jsem do VM nainstaloval OPNsense, ale curl se choval úplně stejně a dál jsem to nezkoumal, protože to asi bude stejné jako na Linuxu.

Nemáte nějaký nápad, co by to mohlo způsobovat?

[Reklama]

[Jose D]

teď hlásí chybu s příjmem fragmentů

Pro začátek zvaž, zda by nedávalo smysl uvést jakou chybu ti ten nástroj zobrazil.

[AltSysRqREISUB]

teď hlásí chybu s příjmem fragmentů

Pro začátek zvaž, zda by nedávalo smysl uvést jakou chybu ti ten nástroj zobrazil.

Píše to

The request timed out. Looks like IP fragments failed to be delivered to you.

Prostě to jen udělá požadavek a čeká na odpověď. Odpověď nepřijde, protože se ztratí fragmenty, stejně jako když dělám požadavek přes curl (projevuje se to vytuhnutím a pak to skončí až na timeout).

[Ondřej Caletka]

Pro ověření nastavení používám http://icmpcheckv6.popcount.org/ a všiml jsem si, že mi to teď hlásí chybu s příjmem fragmentů.

Tohle je skvělá služba, tu jsem neznal! Jen na IPv6 nefunguje kontrola fragmentů úplně dobře. Ve Wiresharku příchozí fragmenty vidím, ale spojení skutečně timeoutuje:

Kód: [Vybrat]

$ curl -v -s http://icmpcheckv6.popcount.org/frag -o /dev/null -6
* Expire in 0 ms for 6 (transfer 0x5609092c7610)
*   Trying 2a01:7e01::f03c:91ff:fe16:a2e9...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x5609092c7610)
* Connected to icmpcheckv6.popcount.org (2a01:7e01::f03c:91ff:fe16:a2e9) port 80 (#0)
> GET /frag HTTP/1.1
> Host: icmpcheckv6.popcount.org
> User-Agent: curl/7.64.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Sun, 17 Feb 2019 16:42:27 GMT
< Content-Type: text/plain; charset=utf-8
< Connection: close
< Transfer-Encoding: chunked
<
{ [14 bytes data]
* Recv failure: Spojení zrušeno druhou stranou
* Closing connection 0

Ve wiresharku to vypadá takhle:

Kód: [Vybrat]

    4 0.035154828 JÁ → ONI HTTP 178 GET /frag HTTP/1.1
    5 0.067141431 ONI → JÁ TCP 86 80 → 45658 [ACK] Seq=1 Ack=93 Win=28672 Len=0 TSval=2835193871 TSecr=4138280037
    6 0.067171239 ONI → JÁ TCP 244 80 → 45658 [PSH, ACK] Seq=1 Ack=93 Win=28672 Len=158 TSval=2835193871 TSecr=4138280037 [TCP segment of a reassembled PDU]
    7 0.067196896 JÁ → ONI TCP 86 45658 → 80 [ACK] Seq=93 Ack=159 Win=64896 Len=0 TSval=4138280069 TSecr=2835193871
    8 0.126013863 ONI → JÁ IPv6 574 IPv6 fragment (off=0 more=y ident=0xee4e5889 nxt=6)
    9 0.126074900 JÁ → ONI ICMPv6 622 Parameter Problem (erroneous header field encountered)
   10 0.126106083 ONI → JÁ IPv6 574 IPv6 fragment (off=512 more=y ident=0xee4e5889 nxt=6)
   11 0.126119450 JÁ → ONI ICMPv6 622 Parameter Problem (erroneous header field encountered)
   12 0.126130690 ONI → JÁ TCP 283 80 → 45658 [ACK] Seq=159 Ack=93 Win=28672 Len=1213 TSval=2835193871 TSecr=4138280037 [TCP segment of a reassembled PDU]
Je vidět, že můj počítač aktivně odmítá hned přijetí prvního fragmentu ICMPv6 chybu Parameter Problem s podproblémem „erroneous header field encountered“ a offsetem chyby 40, tedy za posledním bajtem IPv6 hlavičky. V hlavičkových souborech Linuxu se o vyslání této chyby stará funkce icmpv6_param_prob a hodnota „erroneous header field encountered“ je kódovaná definicí ICMPV6_HDR_FIELD.

Grepování zdrojáků jádra mě dovedlo do souboru resassembly.c. A k vyvolání této výjimky dojde v okamžiku, kdy je přijat fragment kratší než minimální MTU pro IPv6, což je 1280. Protože služba posílá fragmenty délky 512 bajtů, nemůže to s aktuálním Linuxem fungovat nikdy.

Ovšem pokud fragmenty nevidíš ani v tcpdumpu/tsharku/wiresharku, je problém i někde jinde.

[AltSysRqREISUB]

...

To jsou skvělé zprávy. Děkuji za vysvětlení a analýzu. Trochu mne jen mrzí, že jsem na tom promrhal spoustu času. Celé je to o to víc matoucí, že to dříve fungovalo a na Debianích VPS to funguje také. Ta změna do jádra asi přišla nedávno.

Ovšem pokud fragmenty nevidíš ani v tcpdumpu/tsharku/wiresharku, je problém i někde jinde.

To jsem asi napsal nějak špatně. V tcpdumpu je vidím. Jen v "nftrace" ne.

[Reklama]

[AltSysRqREISUB]

Ještě jedna věc, která s tímto souvisí...
Je ta změna v Linuxu opravdu bezpečná pro IPv6? U IPv4 ji podle zprávy z commitu z obav neudělali, ale nezdá se mi bezpečná ani u IPv6. Na obrázku je záznam z komunikace s OVDR CZ.NICu (tcpdump -vvi tun-ipv6 | grep frag). Taky posílá fragmenty menší než MTU. A shodou okolností jsem doufal, že vyřešení problému z úvodního příspěvku vyřeší i problémy s vytuhávám načítání některých stránek na "rozpoznávání hostitele". Taky to začalo nedávno. Skoro jistotou se to děje na čemkoliv od wikia.com (třeba https://fallout.fandom.com). Napodruhé se to už načte (někdy se prohlížeči nechce přestat načítat a je potřeba ho zavřít a spustit znovu), kešuju odpovědi v unboundu, tak možná proto to pak už nějakou dobu funguje.
Myslíš, že bys mi to mohl nějak potvrdit, alespoň jestli čtu ten tcpdump správně.

[Ondřej Caletka]

Ta změna je skutečně od jádra 4.19. Myslím, že to je bezpečné, na rozdíl od IPv4, kde je minimální MTU definované tak nízko, že o něm nemá cenu mluvit (68 Bajtů, navíc to zřejmě není úplně jednoznačné), je u IPv6 jasně řečeno, že každá linka má minimálně 1280 B. Akceptování menších fragmentů naopak může být bezpečnostní riziko, protože fragmenty často používají útočníci k ošálení First Hop Security funkcí na switchích.

Markovi Majkowskemu, který testovací nástroj napsal jsem problém nahlásil.

ODVR posílají UDP odpovědi o velikosti payloadu 1240 B, což spolu s 40B IPv6 hlavičkou dává přesně 1280, tedy minimální MTU. Můj Linux to v každém případě neodmítá. I když, jak to teď testuju, tak mi to úplně dobře neprochází a to dokonce u dvou různých operátorů. Oni fragmentovaný provoz nemají rádi – v normálním provozu se prakticky nevyskytuje, zato při zaplavovacích útocích tvoří velkou část provozu a nedá se prakticky nijak filtrovat.

Takže je možné, že problém s fragmenty skutečně někde bude.

[AltSysRqREISUB]

Tak to jsem tcpdump opravdu četl špatně (bral jsem 1232 místo celé velikosti payloadu, kterou jsem nějak přehlédl). Můj Linuxový router také ODVR neodmítá, jen jsem neposlouchal všechna rozhraní a  tak neviděl jak šly fragmenty dál.
Ještě jednou děkuji, představa, že mám v síti rozbitou podporu IPv6 mne ničila.

[Michal Kubeček]

Nezahazují se samozřejmě všechny fragmenty kratší než IPV6_MIN_MTU (1280), ale jen ty, které nejsou poslední. Idea je taková, že standardní implementace seká paket podle MTU a do posledního fragmentu dá zbytek. Cílem toho patche bylo omezit rizika útoků typu FragmentSmack, které se snaží zatížit CPU příjemce posíláním velkého počtu nesmyslných fragmentů (ideálně co nejkratších).

Bohužel se ukázalo, že existují i reálné implementace, které rozdělují paket do fragmentů jinak, takže ten commit se asi v dohledné době bude revertovat, ale nejdřív bude potřeba změnit implementaci fragment queue pro IPv6 na rbtree (místo lineárního seznamu), stejně jako to už je u IPv4.

[Michal Kubeček]

...takže ten commit se asi v dohledné době bude revertovat, ale nejdřív bude potřeba změnit implementaci fragment queue pro IPv6 na rbtree (místo lineárního seznamu), stejně jako to už je u IPv4.

Ta změna už je v net-next stromě a měla by se tedy dostat do 5.1-rc1.

[Michal Kubeček]

U IPv4 ji podle zprávy z commitu z obav neudělali

Jen pro úplnost: důvod, proč analogické omezení u IPv4 neprošlo, byl především ten, že u IPv4 může fragmentovat kdokoli po cestě, takže se může stát, že už jednou fragmentovaný paket bude muset někdo cestou přefragmentovat na o něco kratší MTU. V takovém případě je normální, že někde uprostřed vznikne krátký fragment i při té "standardní" strategii, např. 3000 → 1500+1500+40 (MTU 1500) → 1480+40+1480+40+40) (MTU 1480).

[Ondřej Caletka]

...takže ten commit se asi v dohledné době bude revertovat, ale nejdřív bude potřeba změnit implementaci fragment queue pro IPv6 na rbtree (místo lineárního seznamu), stejně jako to už je u IPv4.

Ta změna už je v net-next stromě a měla by se tedy dostat do 5.1-rc1.

To je ale škoda. Tohle chování dávalo smysl a podle mě by byla lepší cesta jít s tím do IETF a takovéto chování standardizovat. Byť to bude jistě náročné, vzhledem k tomu, že se jedná o editaci RFC 8200, což je po tolika letech konečně Internet Standard.

[Ondřej Caletka]

Markovi Majkowskemu, který testovací nástroj napsal jsem problém nahlásil.

Marek dnes upravil velikost IPv6 fragmentů na 1280, takže v tuhle chvíli už test funguje i pro jádra 4.19 - 5.0.