6in4 na 1:1 NAT

[y,]

Uvedomil jsem si, ze bych uvital, kdybych se mohl lepe seznamit s ipv6 na prakticke bazi. Chtel jsem si nastavit 6in4 he.net -- mam turris, cili to teoreticky neni tak slozite.
Komplikace je v tom, ze ackoliv mam prirazenou externi IP(v4), muj poskytovatel to dela jinak. Uprimne receno, nevim jak, ale z chovani mi to prijde jako 1:1 NAT, kdy vsechno, co prijde na verejnou adresu A preposle na interni adresu. Na interface mam kazdopadne videt jenom lokalni adresu (10.x rozsah), ale jinak vsechny porty otevrene na mem firewallu jsou z venku (pres tu externi adresu) dostupne.
Z meho omezeneho chapani sitariny je duvod nefunkcnosti 6in4 pod NAT to, ze IP nema porty, cili NAT nedokaze sledovat/multiplexovat spojeni, ale tenhle problem u 1:1 NAT neni, myslim.
Zatim jsem ve fazi "zkusil jsem to a nejde to", ale nevim, na co bych se mel zamerit pri zkoumani? Nejaky napad? Mam to rovnou vzdat?

[Reklama]

[uuuuuuuu]

Pouziti tunelu 6 4 by neslo?

[y,]

To bohuzel nevim, jakou technologii, nebo poskytovatele myslite :/
Jenom pro jistotu dodavam, ze k tomu rozhrani, na kterem visi ta externi IP nemam zadny pristup.

[David]

Asi Vám to moc nepomůže, ale používám he.net IPv6 tunel jak u routeru, kde mám přidělenou přímo veřejnou IP, tak i u jiného routeru, který má jen privátní adresu (tedy asi NAT 1:1) - funguje to v obou případech.

[Ondřej Caletka]

Uvedomil jsem si, ze bych uvital, kdybych se mohl lepe seznamit s ipv6 na prakticke bazi. Chtel jsem si nastavit 6in4 he.net -- mam turris, cili to teoreticky neni tak slozite.
Komplikace je v tom, ze ackoliv mam prirazenou externi IP(v4), muj poskytovatel to dela jinak. Uprimne receno, nevim jak, ale z chovani mi to prijde jako 1:1 NAT, kdy vsechno, co prijde na verejnou adresu A preposle na interni adresu. Na interface mam kazdopadne videt jenom lokalni adresu (10.x rozsah), ale jinak vsechny porty otevrene na mem firewallu jsou z venku (pres tu externi adresu) dostupne.
Z meho omezeneho chapani sitariny je duvod nefunkcnosti 6in4 pod NAT to, ze IP nema porty, cili NAT nedokaze sledovat/multiplexovat spojeni, ale tenhle problem u 1:1 NAT neni, myslim.
Zatim jsem ve fazi "zkusil jsem to a nejde to", ale nevim, na co bych se mel zamerit pri zkoumani? Nejaky napad? Mam to rovnou vzdat?

NAT 1:1 by u 6in4 tunelu neměl být problém, pokud ISP neblokuje jiné protokoly než UDP a TCP, v tomto konkrétním případě protokol číslo 41 – tedy IPv6 uvnitř IPv4. Navíc si He.net vynucuje, aby vnější IPv4 adresa odpovídala na ICMP ping. Jinak by mělo stačit naklikat tunel u he.net a následně jeho paramatry přímo v nastavení WAN ve forisu. A pak samozřejmě debugovat nejdřív pomocí ping6 z routeru, pak z počítače za ním.

Pokud to nefunguje, můžete zkusit požádat ISP, aby přenos protokolu 41 prověřil.

[Reklama]

[SB]

Zkoušel jste hledat? https://forum.root.cz/index.php?topic=18709.msg268924#msg268924

[y,]

Diky  obema za info, budu se holt muset vic snazit. Jsem si jisty, ze poskytovatel na mne pusti uplne vsechno, takze problem bude nekde v mych rukach (nebo hlave).

[PetrM]

Taky jsem s tím na Turrisu bojoval.

Podmínkou bylo založit tunel na veřejnou IPv4, ale v routeru použít dresu za NATem. Jinak všechno podle návodu na sterým Turris fóru a jelo to...

[y,]

Aha, tim by se to vysvetlovalo, ja udelal presne co rikate. Az budu mit volneji, zkusim.

[y,]

Aha, tim by se to vysvetlovalo, ja udelal presne co rikate. Az budu mit volneji, zkusim.

Tedy neudelal, jak rikate -- dal jsem tam svoji "verejnou" misto adresy interface.

[MartinBeran]

Kdysi jsem měl podobný problém. Jednoho dne mi přestal fungovat IPv6 tunel od HE v podobné konfiguraci, tedy veřejná IP 1:1 NATovaná na privátní adresu nastavenou na vnějším rozhraní routeru. Dotazem u providera a experimentováním jsem zjistil, že provider nastadil nový CGNAT (Juniper), který nakonfiguroval tak, že příchozí pakety se dál překládaly staticky 1:1, ale pro odchozí pakety se překládal i zdrojový port na náhodně vygenerovaný. Protokoly mimo TCP a UDP (a ICMP) to zahazovalo - tedy i protokol 41. Technik providera tvrdil, že statický NAT nejde nakonfigurovat, podle supportu Juniperu je konfigurace správná a nikdo jiný si nestěžoval. Takže neměl zájem to dál řešit a nativní IPv6 je v nedohlednu: "Prozatím jsme tento projekt pozastavili pro nezájem ze strany uživatelů a finanční náročnosti na úpravu našeho maloobchodního IS. Na úrovni páteřní a velkoobchodní sítě vč. datacentra je IPv6 podporováno v plném rozsahu." Jediný funkční workaround, na který jsem přišel, je lehce obskurní konfigurace NATu na externím rozhraní mého routeru, která pro komunikaci patřící do tunelu (protokol 41 z privátní externí adresy na cílovou adresu druhého konce tunelu u HE) překládá privátní zdrojovou adresu na příslušnou veřejnou. Na CGNAT u providera tedy paket přijde už se správnou zdrojovou adresou a nic se nepřekládá ani nezahazuje.

[PetrM]

Technik providera tvrdil, že statický NAT nejde nakonfigurovat, podle supportu Juniperu je konfigurace správná a nikdo jiný si nestěžoval. Takže neměl zájem to dál řešit a nativní IPv6 je v nedohlednu: "Prozatím jsme tento projekt pozastavili pro nezájem ze strany uživatelů a finanční náročnosti na úpravu našeho maloobchodního IS. Na úrovni páteřní a velkoobchodní sítě vč. datacentra je IPv6 podporováno v plném rozsahu."

Tak tohle bych řešil "z důvodů nezájmu ISP o potřeby zákazníka a finanční i časové náročnosti provozu VPSky" změnou ISPíka. Nezapomeň mu to takhle zdůvodnit. Nejde jenom o IPv6, ale o přístup - osobně nemám moc rád, když si se mnou někdo vytírá zadek.

[SB]

...veřejná IP 1:1 NATovaná na privátní adresu nastavenou na vnějším rozhraní routeru. ...nový CGNAT (Juniper), který nakonfiguroval tak, že příchozí pakety se dál překládaly staticky 1:1, ale pro odchozí pakety se překládal i zdrojový port na náhodně vygenerovaný.

Už překlad na vnitřní adresy v situaci, kdy mám přidělenou nebo koupenou veřejnou adresu, mi přijde dost na hraně, protože předpokládám, že ta adresa bude končit u mě. Překládat (jakýkoliv) port je zásahem do komunikace, protože poskytovatel má routovat na síťové vrstvě a tím jeho úloha končí. (U NATu je to něco jiného, to je omrdávka a tudíž sračka z podstaty věci.)

Protokoly mimo TCP a UDP (a ICMP) to zahazovalo - tedy i protokol 41.

Filtrování provozu je jasně za hranou (nemáte-li to ve smlouvě, a to nejspíš nemáte) a případ pro ČTÚ.

...nikdo jiný si nestěžoval.

To není argument. Nebo se snad stížnost považuje za platnou od 2 uživatelů a více?

"Prozatím jsme tento projekt (IPv6) pozastavili pro nezájem ze strany uživatelů..."

Tohle je ustálená formulka poskytovatelů, která se dá omílat až do naprostého vyčerpání - uživatelé přece nikdy nebudou chtít IPv6! Co by ISP odpověděl, kdybyste jim napsal, že je vysoký zájem ze strany poskytovatelů obsahu a služeb? Zkuste mu napsat. A taky nám napište jméno těch lemplů, co neumějí nastavit síť, pochlubte se, ať ostatní vědí.

Navrhuju vytvořit zde ve fóru nástěnku lemploposkytovatelů, kde by se tito uváděli včetně jejich "konfigurací" a výmluv. Nejde o to do ní zapsat každého, kdo nechce zavést IPv6, ale každého, kdo pro to uvede kvalitní výmluvu, nebo ISP, kteří mají kvalitně oprasenou konfiguraci. Neboli POUZE KVALITU.