Tunel SIT cez NAT

Tunel SIT cez NAT
« kdy: 20. 09. 2021, 11:29:17 »
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?
« Poslední změna: 20. 09. 2021, 11:41:31 od Petr Krčmář »


SB

  • ****
  • 296
    • Zobrazit profil
    • E-mail
Re:Tunel SIT cez NAT
« Odpověď #1 kdy: 20. 09. 2021, 17:38:13 »
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.

Re:Tunel SIT cez NAT
« Odpověď #2 kdy: 20. 09. 2021, 22:43:07 »
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.

Re:Tunel SIT cez NAT
« Odpověď #3 kdy: 21. 09. 2021, 08:41:52 »
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

  • ****
  • 296
    • Zobrazit profil
    • E-mail
Re:Tunel SIT cez NAT
« Odpověď #4 kdy: 21. 09. 2021, 12:55:58 »
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?


SB

  • ****
  • 296
    • Zobrazit profil
    • E-mail
Re:Tunel SIT cez NAT
« Odpověď #5 kdy: 21. 09. 2021, 12:57:01 »
Pro TCP a UDP musí NAT taky vrtat do vrstvy sezení...

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

Re:Tunel SIT cez NAT
« Odpověď #6 kdy: 23. 09. 2021, 14:48:36 »
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.

Re:Tunel SIT cez NAT
« Odpověď #7 kdy: 13. 10. 2021, 18:08:54 »
Ď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.