Tunel SIT cez NAT

[xitop]

Dobrý deň. Riešim výpadky predtým 10 mesiacov bezproblémovo fungujúceho IPv6 cez IPv4 tunela. Mám podozrenie na NAT u providera.

[zákazník] ----- [provider/NAT] ---- internet ---- [broker]

Zákazník (ja) má neverejnú adresu, nakonfigovaný SIT tunel (IP protokol 41) na dohodnutú adresu tunnel brokera (Hurricane Electric). Pakety od zákazníka prejdú cez NAT u providera (Orange SK) a dostanú tam verejnú adresu. Naštastie existuje spôsob, ako túto adresu dynamicky oznámiť brokerovi. Pri paketoch od brokera spomínaný NAT prepíše adresu na súkromnú, aby prišli k zákazníkovi.

SIT protokol pozná len IP adresy zdroja a cieľa. Žiadne porty ako pri TCP, UDP. Myslím si, že ak by mal provider druhého zákazníka s tunelom na rovnaký server, NAT server nebude vedieť, či pakety od brokera má smerovať k zákazníkovi 1 alebo zákazníkovi 2, lebo jedny aj druhé budú mať protokol SIT, zdrojovú adresu brokera a cieľovú adresu providera a žiadne čísla portov na rozlíšenie. Jedine, že by NAT kontroloval aj obsah tunela, kde sú jedinečné IPv6 adresy.

Vidím to spravne?

[Reklama]

[SB]

Pro TCP a UDP musí NAT taky vrtat do vrstvy sezení, jinak by to pro víc uživatelů vůbec nejelo (aspoň jde vidět, co je to za hnus), takže vaše závěry jsou logické, akorát mi pak není jasné, jak může přes NAT fungovat ping (ICMP), který žádné rozlišující údaje neobsahuje.
A taky je divné, že vám to vůbec dosud fungovalo.

[Petr Krčmář]

NAT musí samozřejmě rozumět protokolu a ten musí mít nějaký identifikátor, podle kterého je možné párovat pakety ke konkrétnímu provozu.

V případě ICMP je to jednoduché: Echo Reply Message (čili ping) má v hlavičce unikátní identifikátor, podle kterého si ho NAT spáruje. Další varianty (třeba Destination Unreachable) kopírují za hlavičku začátek paketu, na který reagují. Z něj pak NAT vyčte unikátní identifikátory (IP adresy, porty a protokol) pro párování. Viz RFC792.

[xitop]

Pri ICMP je ID, pri TCP a UDP je to kombinácia portov, ale v hlavičke SIT sú len IPv6 adresy a tá na strane zákazníka je z /64 prípadne až /48 rozsahu. Skúsim požiadať providera o pevnú verejnú IP adresu, aby som sa vyhol NAT, len mu potom budem platiť 8€ mesačne za jeho neschopnosť dať mi IPv6.

[SB]

To může zabrat, ale taky nemusí - existují poskytovatelé-znalci, kteří propouštějí pouze některé transportní protokoly.
Dalšími řešeními jsou tunel do Hurricane přes pronajaté VPS, či úplný tunel z VPS s veřejnými rozsahy domů. To druhé řešení má výhodu, že funguje přes sebezprasenější síť poskytovatele, aniž byste se s ním musel vůbec vybavovat.

Co se zeptat poskytovatele, proč to přestalo fungovat?

[Reklama]

[SB]

Pro TCP a UDP musí NAT taky vrtat do vrstvy sezení...

Jejda, chyba, správně je transportní vrstva.

[xitop]

Aktivoval som pevnú IPv4 adresu a budem tunel pozorovať - pridal som ho do Zabbixu. Momentálne ide. Pri testoch som objavil na LTE routri veľmi dobre schovanú možnost "DMZ - bypass firewall", ktorá robí rozdiel aj keď firewall je vypnutý  . Aj to mohol byť problém.

Pre úplnosť: problémy začali v lete, tunel išiel buď bezproblémovo alebo vôbec a jednotlivé stavy trvali niekoľko dní. Reklamácia nič nevyriešila, vraj všetko, čo preverili, bolo v poriadku.

[xitop]

Ďakujem za všetky reakcie. Problém sa už viac razy neopakoval. Pre mňa je to teda uzavreté. Nie som si 100% istý, čo bolo na príčine, či to bol naozaj NAT, ale ďalšie pátranie by bolo neefektívne.