Hlavní navigace

Vlákno názorů ke zprávičce DNS-SD objevování a přímé propojení účastníků za NATem Wireguard tunelem od Ondřej Novák - Přišlo mi, že NAT tunelling je v dnešní...

  • Aktualita je stará, nové názory již nelze přidávat.
  • 23. 5. 2020 13:35

    Ondřej Novák

    Přišlo mi, že NAT tunelling je v dnešní době nefunkční, protože jsem si s tím hrál už před drahnou dobu a začaly se objevovat NATy, které pro každou čtveřici IP external:port:IP internal:port přidělí jiný port na NATu. Takže bubble packet neprošel a nebylo možné tedy otevřít přímou komunikaci.

    Opravte mne, jestli to je jinak. Mám ale pocit, že N2N tohle dělá s tím, že má fallback přes centrální uzel a poslední dobou mi všechno běhá přes centrální uzel s tím, že se nepodaří prorazit cestu přes NATy

  • 23. 5. 2020 14:23

    Ondřej Caletka

    Je to možné. Já bych tedy předpokládal, že zejména velké hardwarově podporované NATy se budou snažit držet co nejméně stavu a tedy používat Full-cone. Proti tomu Linuxový plně softwarový NAT používá conntrack, který sám o sobě eviduje pětici adresa:port:a­dresa:port:pro­tokol, takže přes ten to nejspíš neproleze. Asi to chce vyzkoušet.

  • 23. 5. 2020 16:38

    Adam Kalisz

    Zdá se, že normální upstream Linux full cone NAT nepodporuje, ale modul, který tuto funkcionalitu zprostředkovává existuje a je snad i nějakým způsobem podporovaný jako doplněk pro OpenWRT: https://github.com/Chion82/netfilter-full-cone-nat
    Jistě existuje prostor nějaké obecnější řešení stabilizovat a do Linuxu poslat... možná je něco takového https://github.com/andrsharaev/xt_NAT krok tím správným směrem.

    Ve FreeBSD nějaké pokusy snad taky byly: https://reviews.freebsd.org/D11137

    Na druhou stranu musím říct, že full cone NAT z hlediska omezování příchozích spojení a tedy jakéhosi omezování provozu z venku je asi nejhorší řešení. Vím, NAT není firewall, ale realita je taková, že v praxi právě port restricted cone efektivně omezuje možnost dostat se za NAT nějakou "hole punching" metodou.
    Jelikož CG-NAT asi full cone bude, tak při nasazení vlastního routeru je šance na úspěch poměrně vysoká.

    Taky pokud router mám nějakým způsobem pod kontrolou, tak tam můžu přidat explicitní pravidla na port forwarding a potom nemusím řešit informaci o portu který nějak dynamicky musím zaznamenat, ale jen nějak kontrolovat, kterou IP router právě má - což je mnohem jednodušší.

    A nejlepší řešení nakonec stejně zůstává mít správně a plošně nasazené IPv6 a částečně asi i nedělat ze zákazníka blbce a nechat jej např. v nějakém pokročilém nastavení skutečně něco užitečného taky nastavit. Potom bychom se nemuseli zabývat rovnáky na ohýbáky, ale něčím skutečně užitečným. Celý NAPT, STUN apod. by potom byly spíš takové akademické hrátky. Paradoxně myslím, že nás "řešení" NATu stálo víc času a námahy, než kolik by stál úplný přechod na IPv6 a vypnutí IPv4.
    Myslím, že kdyby se usneslo, podobně jako s uhlím, že se v roce 2030 IPv4 přestane routovat mezi autonomnímy systémy, že by se situace celkem rychle zlepšila. 10 let je myslím na relevantní systémy času dost. Však nějaké firmy a instituce určitě ještě někde interně používají IPX, token ring apod. podobně by to měly s IPv4...

  • 23. 5. 2020 17:27

    BobTheBuilder

    Jo, bylo by to dobrý, ale jak toho dosáhnout? Vlastní IPv6, které člověk mohl mít, i když na něj ISP z vysoka, SIXXS, skončilo a když jste za kdovíjakým NATem, tak si nepomůžete nijak. ISP možná můžete donutit nebo vyměnit (alespoň teoreticky), ale mobilní operátoři na IPv6 naprosto kašlou. Pikantní je to teď u Vodafonu, když v koupeném UPC máte veřejnou IPv6 adresu, na kterou se z mobilu nedostanete.
    Jinak VDSL modem (co jsem potkal) má možnost IPv6 firewall nastavit, UPC modem taky.
    Tady by pomohlo buď Lukašenkovo běloruské řešení (IPv6 je pro ISP povinné), nebo alespoň nařídit, že bez IPv6 se služba musí povinně nazývat "zmršený internet".

  • 23. 5. 2020 20:58

    Adam Kalisz

    Edit: Se to nějak roztáhlo, jak jsem nad tím přemýšlel - asi budu muset psát na blog, nebo na to udělat Orgpage na https://orgpad.com/about :-)

    Tak on celkem určitě během tak roku nebo dvou přijde určitý zlom, kdy i poměrně konzervativní operátoři do nějaké míry IPv6 nasadí. Ano, zjistili jsme jako komunita, že CG-NAT umíme a i když je drahý, není to tak zlé abychom opustili poměrně lukrativní trh. Částečná komoditizace v profesionálním síťovém hardwaru tomu finančnímu pohledu dost pomohla.

    Problém je tak trochu v koordinaci přechodu - velmi podobné, jako když se kdysi všude muselo podporovat IE6 nebo "HTTPS si můžou dovolit jen banky a velké obchody", jenom tak nějak ve větším a složitějším. V podstatě je nějaký český operátor chybou zaokrouhlení ve světovém měřítku, takže chtě nechtě půjdou s davem. Jak tedy přesvědčit/ pohnout davem?

    Např. kdyby AWS, Azure a GCP řekli, že budou promítat tržní cenu IPv4 do ceny VM a že VM můžete mít o x levněji když nebudete používat IPv4, tak by to byla určitá iniciativa. Oni tedy něco podobného tak trochu místy dělají, ale z mého pohledu to pořád ještě dost dusí.
    V USA podobný nátlak vznikl znovu myslím poslední měsíc na federální úrovni - tam existuje nařízení a poměrně ambiciózní plán na realizaci přechodu/ implementaci IPv6, není to sice úplně poprvé, co někdo něco takového ustanovil, ale tentokrát to má podstatně vyšší váhu myslím. Každopádně to musí zohlednit všichni výrobci, kteří chtějí vládě nějak dodávat hardware a software. Ta kritéria jsou veřejná a dají se klidně v určitém rozsahu použít při výběrových řízeních i ve firmách - Proof of Concept klidně může požadovat, že se ten checklist musí předvést v demu nebo testovací fázi. Testovat objednávku je u větších zákazníků celkem běžné a prakticky vždy se pokračuje k finalizaci koupě. Někdy se ale dá aspoň zatlačit na cenu a pokud by to nešlo, tak od smlouvy ustoupit.
    U služeb které IPv6 nepoužívají se může člověk aspoň dotázat, jaké jsou v tom ohledu plány. Takový postřeh se hodí třeba tehdy, kdy zrovna s někým už osobně vyřešil nějakou jinou chybu užitečným debuggingem - to mají lidi (často už trochu s lepším postavením ve firmě) tendenci poslouchat. U některých IT firem bývají lidi typu Radek Zajíc, kteří jenom čekají na obhajobu pro management, že zákazníci IPv6 chtějí.
    V některých firmách se veřejné IPv4 nemůže prostě jen tak použít. Musí se objednat. U IPv6 pro to není tak moc důvod, protože obyčejně je k dispozici celý prefix aspoň /56 a za ten nebylo nutné platit, takže alokace je otázkou napsat do správného řádku v Excelu nebo ideálně IPAM (ale buďme realisti) na co že se to používá. V Německu např. něco pro interní zaměstnance, kteří ale v dnešní době pracují často i z domu by reálně tak 80-90% nemělo problém přistoupit na čistě IPv6 bránu z domu. Rozšíření IPv6 na domácích přípojkách je v Německu dost vysoké.

    Killer feature taky rozhodně může být, že je to levnější. Podívejme se třeba na SpaceX - vystřelit něco malého na oběžnou dráhu si dnes může dovolit i hodně zapálený jednotlivec. Místo luxusního auta bude mít malý satelit... to by asi u jiných firem nebylo možné, tam by ani životní obrat nadprůměrného softwarového inženýra nemusel stačit.
    Může ale taky být, že je to ve finále jednodušší. DHCP pool např. nikdy nedojde pokud rozdělujete z /64 prefixu, v prefixu /48, který firmy dostanou bez jakékoliv obhajoby je 64k takových podsítí, tedy něco ekvivalentního /16 v IPv4 akorát tedy podsítí/ administračních celků. Spíš bych to tedy připodobnil v reálu např. /8 v IPv4, kde by poslední oktet byl "nafukovací" a stále veřejně routovatelný. :-)
    No a když jste LIR, tak dostanete /32 bez diskuze, když zvednete ruku, tak 8x tolik (/29) a když to rozumně obhájíte, tak v podstatě cokoliv, klidně i /19 nebo /20 pokud vím - většina firem ale není Deutsche Telekom nebo France Telekom a určitě ně US DoD (/13, tedy asi 50% toho, co aktuálně spravuje RIPE NCC pro celý region), AWS dává regionům pro EC2 podle všeho prefixy /36 až /33 (http://ipv6.ec2-reachability.amazonaws.com/) - když si to tak srovnáte v hlavě, tak při prefixu je to pořád 1 milion zákazníků s /56 prefixem na region. A to potřebujete už opravdu hodně velkou infrastrukturu, aby vám jeden /56 prefix nestačil - to už se nejspíš budete stejně bavit s nějakým zástupcem Amazonu, který vám bude s infrastrukturou radit. I těch nějvětších regionů by mohl Amazon mít 16k, pokud má /19 prefix. I takto velkých prefixů je možné přiřadit 64k a potom je ještě 7x tolik rezervovaných - Ondřej mě jinak rád opraví ;-)

    Jinak firmy Amazon i Microsoft prý RFC1918 prostor už vyčerpaly - takže i na interní funkce musí asi používat teď taky NAT nebo se musí vyvarovat překryvům jinou technologií nebo organizací.

    I pokud někdo má jen malou firmu a nějaké adresy a překryvy VPN apod. se ho netýkají, pro ty je v podstatě jedno, jestli použijí IPv4 nebo IPv6. Tam tedy IPv6 v současném stavu přinejmenším nevadí. Já si ale myslím, že IPv6 prostě v určitém ohledu dospělo. Už se nemluví ani tak o tom, proč nasadit a co je IPv6, ale kdy a jak nasadíme IPv6 abychom se zbytkem světa mohli komunikovat nativně. I když podpora IPv6 ještě není v některých produktech vůbec a jinde spíš druhořadá, renomovaní výrobci v podstatě 80% nebo tak funkcionality na IPv6 mají, rozumní poskytovatelé minimálně firmám IPv6 poskytnout umí a IPv6 je tak rozumně použitelná.

    Asi uvidíme, kam se s IPv6 dobereme, ale poslední dva roky mám pocit se opravdu dost věcí posunulo. Jistě k tomu pomohl razantní růst cen IPv4/ problematika získání dostatečného počtu IPv4 a další nasazování IPv6 ve světě, které obloukem obhajuje další nasazování. Podle Googlu jsme si za poslední 2 roky pomohli ze ca. 20% na něco přes 30%. Poslední 2 měsíce jsou i výkyvy v používání IPv6 výrazně menší, jak lidi jsou víc doma místo v práci. Vím o institucích, kde se ještě nenasadilo, ale kde se tak posledních 6 měsíců podnikají konkrétní kroky k zavedení IPv6, jako školení, příděly prefixů nebo spojená administrativa s těmito příděly. Jedna z těchto institucí má něco jako /16 z IPv4 - takže srovnatelné např. s menším ISP. V regionu takové věci rozhodně zvyšují povědomí a tlak na další nasazování. O2 se možná taky v Čr v mobilní síti pochlapí na podzim (https://twitter.com/O2GuruCZ/status/1259368190901211138)

    23. 5. 2020, 21:00 editováno autorem komentáře