közvetlen VPN két NAT mögötti hálózat között?

Hálózatok egyéb

Tud-e valaki olyan fajta VPN meglétéről, amivel össze lehetne kötni közvetlenül két meglévő (otthoni) hálózatot, ahol egyikre sem igaz sem a statikus, sem a publikus IP cim megléte, hanem tipikusan valamiféle carrier grade IPv4 NAT mögött bújnak el.

Hasonló megoldások már léteznek fájlok szinkronizálására. A SyncThing egy elég menő cucc, ami demonstrálja, hogy közvetlenül tudunk kapcsolatot létesíteni két hasonlóan NAT mögé bújtatott peer között, habár a kapcsolat felépítéséhez kell egy publikusan/statikusan elérhető STUN szerver, vagy upnp funkcionalitás a routeren. Ez szerintem egy elég jó kompromisszum, hiszen ez a publikus szerver csak a kapcsolat felépítéséig szükséges (UDP hole punching), utána a forgalom már közvetlenül a két peer között tud folyni, ahol mindegyik a NAT mögött van egy-egy dedikált, dinamikusan allokált porttal cimezhető.

A jelenlegi Site-To-Site VPN-ek és tanúsítványok nem igazán barátai a NAT-nak és a változó IP címeknek és ezzel kapcsolatos DNS TTL beállításoknak. Eddig még csak olyan megoldásokat láttam, ahol legalább az egyik félnek szükséges egy publikus és statikus IP cim. Van-e valakinek ehhez ötlete?

Szerk:

Köszönöm mindenkinek a tippeket és a tapasztalatokat! egy nem teljes lista az eddigi megoldásokról:

Commerical / freemium

  • Zerotier
  • Tailscale

Open source / free

  • SoftEther
  • Tinc
  • 1466 megtekintés

( _ventura_ v | 2021. 01. 29., p – 20:24 )

Szerkesztve: 2021. 01. 29., p – 20:25

Ha nem kell nagy sávszél egy olcsó VPS is megteszi, és oda becsatlakozik mindkét hálózat és mér kész is.

Fedora 41, Thinkpad x280

( lcsaszar v | 2021. 01. 29., p – 20:27 )

Valami olyat tudok elképzelni, hogy mindkét fél bemegy valami publikus szerverre, ami aztán összeköti őket (mint a régi telefonközpontokban a dugdosós kisasszony). Egyébként hogyan tudna valaki be VPN-ezni valahova, aminek nem ismeri a címét? Talán a dinamikus DNS megoldás erre.

A SyncThing Device ID koncepció ki tudja kerülni a dinamikus DNS és egyéb dolgokat. A Device ID nem tartalmazza az IP cimet, ennek feloldásához fel kell keresni a publikusan elérhető szervert, ahol ezek a meta információk megosztásra kerülnek.

Azt remélem, hogy esetleg van már, vagy éppen születni készül egy hasonló Device ID koncepcióra alapuló VPN megoldás.

 

( answ | 2021. 01. 29., p – 20:33 )

Szerkesztve: 2021. 01. 29., p – 20:34

Nagyon jó gondolat, én is kerestem régen ilyet, de nem találtam. Írni kellene egy user mode programot, ami létrehoz egy egyszerű tunnelt ezzel a módszerrel, amin mondjuk átmegy így egy olyan VPN, ami csak egy portot használ (például Wireguard).

Azonban sajnos egy központi entitásra mindenképpen szükség lenne, amit sajnos hostolni kell -> pénzbe fog kerülni, mert nincs ingyen ebéd. STUN mellé ráadásul dinamikus DNS-t is meg kell valósítani ennek az entitásnak.

( gergov | 2021. 01. 29., p – 20:46 )

Régen a Hamachi pont ilyen volt. Ha jól emlékszem, előbb megpróbált lyukat ütni, aztán ha nem sikerült, ment a forgalom központi szerveren keresztül. A wikipedia szerint vannak free alternatívái.

Ha a biztonság miatt aggódsz és a teljesítmény kevésbé érdekes, fölé még mindig lehet kókányolni +1 réteget.

( Caro | 2021. 01. 29., p – 20:54 )

Bár nem csináltam, de azt gondolnám, hogy ipv6-on létre lehet hozni ilyen tunnelt, persze ha mindkét oldalon legalább van ipv6. Ha nincs, akkor teredo, de azért azzal nem voltak olyan jó tapasztalataim, amikor próbáltam még, nagyon túlterhelt volt.

( buccaneers v | 2021. 01. 29., p – 21:09 )

SonicWall tud site to site VPN with Dynamic DNS -t.

Kell hozzá regelni pl. dyndns.org -on DNS-t

routeren be kell kapcsolni: Exchange: Main Mode, Enable Keep Alive ,  ha szükséges windows broadcast 

Viszont jó ha tudod:

- ha DDNS-ben valami hiba van vagy változik az IP-d, akkor nincs VPN és 5 perc mire frissül.

Istennel a hazáért és a szabadságért !

Mindkét végpontnak lesz dyndns-ből vagy más, hasonló szolgáltatásból feloldható IP-címe, és ezzel a névvel "célozzák meg" egymást. Ehhez a dyndns-es "trükkhöz" csak annyi kell, hogy a megcélzott fél IP-je feloldható legyen ilyen módon a nevéből - nálam egy Asus router tette így a dolgát: "jár" hozzá egy asus-os dinamikus dns szolgáltatás, és azt bekapcsolva működött a vpn "kintről" befelé, névvel hivatkozva a vpn szerverre.

UDP-nél van egy trükk: ha a két host egymás publikus IP:port -jára azonos percben forgalmat küld, azzal mindkét fél felnyitja az addig lezártnak tűnő UDP adatutat a tűzfalban.
Innentől ha ismered a túloldali UDP portot, már csak a túloldali publikus IP cím kell. És persze hogy a NAT vagy CGNAT routeren ne legyen más host által elfoglalva az a port, mert addig porthűen fordítanak IP-t.
És éppen ezért a "szerencse kell"-ért száműzendő a jövőben a NAT.

Nem két kliens, hanem site2site vpn, ahol az egyik várja, hogy a másik kapcsolódjon hozzá. Amelyikhez kapcsolódni kell, annak ha van dyndns-ből IP-címre feloldható neve, _és_ nincs dupla nat mögött, és a saját nat-boxon a megfelelő port be van forgatva egy belső gépre (vagy a vpn a natolós dobozon van végződtetve), akkor a kapcsolódni kívánó gépen a dyndns-es névvel hivatkozva a másik félre, szépen elkezdenek beszélgetni L3-on.
Ha mindkét oldalon "sima" nat van, akkor bármelyik fél lehet a kezdeményező. Ha az egyik oldalon van dupla nat, a másikon szimpla, akkor ahol dupla nat van, onnan kell kezdeményezni a kapcsolódást. Ha mindkét oldalon dupl anat van - na az a copás, de ott a dyndns sem működik helyesen.

Szerintem te keversz itt valamit. Mindkét oldali NAT-ról beszélünk most dupla NAT-ként. Ráadásul valószínűleg CGNAT, így nincs lehetőség portok átirányítására. A dinamikus DNS pedig bármennyi NAT esetén működik, mert ha nem ad meg a kliens IP címet, akkor a szerver azt az IP címet állítja be, amit ő lát. Tehát az IP cím bármennyi felfűzött NAT esetén jó lesz, csak éppen port nem lesz :) De az egyébként sem a dinamikus DNS feladata, hanem az upnp-é vagy az STUN-é. STUN is akárhány NAT-on keresztül működik (ott csak a NAT típusa lehet a probléma), upnp már nem. TURN pedig mindenen keresztül működik. Egyébként nem kell mindent előről kitalálni, elég ha implementálod ICE-t és akkor a legjobb kapcsolódási mód lesz választva + lesznek candidate kapcsolatok is, amire azonnal lehet váltani, ha közben esetleg változnának a link paraméterei.

Nem keverek semmit.  Ahol CGNAT _is_ van, onnan kell indítani a kapcsolódást. Ha mindkét oldalon van, akkor a normál módszerek nem működnek, mert nincs 1:1 megfeleltetés IP:port alapon a kiszolgálói oldalon.

Használtam OpenVPN-t CGNAT+NAT mögül dinamikus IP-n lógó NAT-olós router mögötti VPN szerverehez kapcsolódva (a dinamikusan kiosztott IP-t dyndns-ből név alapján feloldva), és működött. Amikor a kapcsolat ez utóbbi vége is CGNAT mögé került, akkor természetesen nem ment, de ezt írtam is.

"A dinamikus DNS pedig bármennyi NAT esetén működik, mert ha nem ad meg a kliens IP címet, akkor a szerver azt az IP címet állítja be, amit ő lát. " - azaz fals, használhatatlan információt fog tárolni, mert az az IP amit a kliens küld, az a CGNAT-on (adott szolgáltató hálózatán) kívül értelmezhetetlen, ha meg nem küld a kliens, akkor meg a szolgáltatói CGNAT-os poolból az az IP, amin a dyndns frissítésére használt tcp-session kilépett a CGNAT mögül, ami dettó nem alkalmas arra, hogy azon az adott eszközt el lehessen érni.

Nem false, mert az a te külső IP címed. Általában nem is változik per kliens (tehát nem per session kapod). Ugyanúgy működhet NAT kerülési technika. Az hogy te még nem láttál ilyet, attól mêg van és működik is például VoIP esetén. Azért használják ritkán, mert garantálni nehéz a kapcsolat felépülését (ezért inkább tiltják direkt médiát a legtöbb környezetben, ezzel pedig a szervert terhelik). A legtöbb NAT típus megkerülhető, nem probléma ha mindkét fél NAT mögött van, direkt kommunikáció lehetséges.

Ezen dokumentum alapján sajnos a tinc nem teljesen csak STUN+hole punching, hanem TURN is. Tehát előfordulhat, hogy keresztül megy a harmadik routeren a teljes forgalma két másiknak. Ez pedig egy mobilnetnél nem biztos, hogy szerencsés. Tény viszont, hogy így mindig lesz kapcsolati lehetőség + lehet hogy kikapcsolható ez a funkció. A másik furcsaság, hogy azt írják dinamikus publikus IP-nél is működik, ami egy olyan központi entitás nélkül, aminek fix az IP címe vagy dinamikus DNS-t alkalmaz számomra elképzelhetetlen. Szerintem itt valami csúsztatás van és legalább egy peernek szüksége van ezekre (ahogy ugye NAT nélküliségre is szüksége van legalább egy peernek).

Szerk: kikapcsolható a TURN funkció tincben (igaz csak experimental jelenleg)

DirectOnly = yes | no (no) [experimental]
When this option is enabled, packets that cannot be sent directly to the destination node, but which would have to be forwarded by an intermediate node, are dropped instead.

Én ezen rész elolvasása után lettem optimista:

It could be that some daemons are located behind a Network Address Translation (NAT) device, or behind a firewall. In the above scenario with three daemons, if A and C are behind a NAT, B will automatically help A and C punch holes through their NAT, in a way similar to the STUN protocol, so that A and C can still communicate with each other directly. It is not always possible to do this however, and firewalls might also prevent direct communication. In that case, VPN packets between A and C will be forwarded by B.

Nem hiszem. Az én EdgeRouter -ben az alapértelmezett IPv6 tűzfalszabály tiltja a kapcsolatok felépítését/kezdeményezését kívülről. Tehát nem lehet ICMPv6 pinget fogadni, nem lehet TCPv6 vagy UDPv6 kapcsolatot kívülről indítani, ha nincs rá explicit szabály.

Remélem a többi router is hasonlóan alapértelmezett beálltásokkal rendelkezik...

( pepo v | 2021. 01. 30., szo – 17:00 )

Pingeléssel tartsd fenn a kapcsolatot, különben elhajítja a VPN. Máshogy nem fog menni.

READY.
󠀠󠀠‎‏‏‎▓

( Zs | 2021. 01. 30., szo – 17:54 )

Amazontol VPN: https://youtu.be/m-i2JBtG4FE - 2 userig ingyenes, annyi most pont elég is lesz. Ha beállítod, hogy mindkét router ebbe a VPN-be csatlakozzon, máris látják egymást direktben. Innen már csak konfiguráció kérdése.

( MGy v | 2021. 01. 31., v – 11:56 )

Javaslom a softether-t tud jelszavas és tanúsítvány alapú azonosítást is és a dinamikus DNS és a NAT traversal is benne van.
A kezeléséhez a konfig fájl íráson kívül van nagyon kézreálló admin kliens és a kliens manager is odaadható egységsugarú felhasználónak. Ezt használom a covid miatti sok home-office igényre. Eddig stabil.

Nem hátrány, hogy nyílt forráskódú és támogat Windowst Linuxot és Macet is (az utóbbit nem használtam). És még sok más.
A japán Tsukuba egyetemen fejlesztik.

( uid_4672 | 2021. 01. 31., v – 12:04 )

ha a NATnál tudsz port forwardot, akkor sima wireguard ?

Az a baj, hogy ez a lehetőség egyre jobban kezd megszűnni. Nagyok sok szolgáltató már Carrier Grade NAT-ot alkalmaz a fogytában lévő IPv4 címek miatt, ami azt jelenti, hogy több előfizető kapja meg ugyanazt a publikus IP címet egy időben. Ez általában abban mutatkozik meg a felhasználói oldalon, hogy a router a PPPoE vagy DHCPv4 bejelentkezés/felcsatlakozás után egy 100.64.0.0/10 tartományban lévő IP címet kap/érzékel, de amikor felkeressük a "what is my ip" weboldalakat, akkor láthatjuk, hogy az IP cím nem ugyan az, átesett egy további címfordításon a szolgáltató által. Sajnos ez azt vonja maga után, hogy nincs kontroll ezen publikus IP cím portjai felett, a vissza fele irányú ICMP/TCP/UDP kapcsolat kezdeményezése nem lehetséges. Nem tudunk egy hello world web szervert a 80 as porton szolgáltatni.

Közben találtam egy wireguard barkácsolásos cikket is, ami ezt a problémát próbálja áthidalni. A coreDNS -t használja egy publikusan elérhető meta-adat kicserélő szervernek, ami segítségével valahogy megtörténik a közvetlen kapcsolat felépítés.

https://www.jordanwhited.com/posts/wireguard-endpoint-discovery-nat-tra…

Ez még elég kezdeti fázisban van, nem éppen egy "Turnkey solution".

( bAndie9100 | 2021. 02. 02., k – 10:38 )

peervpn.

kell neki is egy initiator node. de ha mind két nat-mögötti node tud a kinti node-dal kommunikálni, akkor egymásra találnak és onnastól közvetlen megy a kommunikáció.