OpenVPN rejtelmek

Web, mail, IRC, IM, hálózatok

1. kérdés (A probléma innen indul https://hup.hu/node/179458)

Adva van két ASUS router. Az egyik (a szolgáltató által kezelt) NAT mögött a másik publikus IP címen (freeDNS) jól látható.
A jól látható működik mint OpenVPN szerver, a másik (szolgáltatói NAT mögött) kliens. A kliens oldali hálózatból látszik a szerver oldali hálózat (mini szerver SMB,), a szerver oldali hálózatból nem látszik a kliens oldali hálózat (jelenleg csak egy Raspberry Pi kamera és meteorológiai "állomás").
Van erre egyáltalán megoldás?
(A kliens oldalon nem érdemes szervert indítani - NAT mögött van, nincs publikus IP cím.)

2. kérdés
Adva van egy OpenVPN szerver (mondjuk egy szerver gépre telepítve ami router/tűzfal mögött van) és néhány kliens kapcsolódhat rá.
Belehet állítani úgy az OpenVPN szervert hogy a kliensek lássák egymást?
(Ez tulajdonképpen ugyanaz a kérdés, csak az OpenVPN oldaláról megközelítve. Lehet szellemet üldözök?)

  • 1380 megtekintés

( x-daemon | 2023. 05. 06., szo – 13:05 )

1.

hogy mukodjon routing mind az openvpn-nek tudnia kell a halozatokrol (iroute, push "route") mind a routernek (route -n megmondja mirol tud)

2.

client-to-client

neked aztan fura humorod van...

1. A lényeg hogy működhet, de olyan beállítások kellenek ami a grafikus felületről nem elérhető.
Igen emlékszem amikor (10 éve) csináltam kellet piszkálni a route-ot és a iptables-t is. A routeren hozzáférek a konzolhoz, talán ott meglehet oldani. Kérdés hogy letárolja e?

Szerinted az OpenVPN dokumentációban ez benne van?

* Én egy indián vagyok. Minden indián hazudik.

ja hogy grafikus felulet. bocs nem olvastem el hogy honnan indult, biztos abban volt.

"iptables": valoban, snat is lehet, ha nem gond, hogy a kliens es a kliens mogotti gep ugy latja, minden a vpn atjarobol jon.

nekem ugy remlik a doksibol neztem vagy 15 eve, de mar nem tudnek ra megeskudni.

neked aztan fura humorod van...

1. A lényeg hogy működhet, de olyan beállítások kellenek ami a grafikus felületről nem elérhető.

Ahogy más is jelezte, te egy site-to-site VPN-t szeretnél, a grafikus felület meg client-server állapotra van (csak?) felkészítve.

Ilyenkor a klienseden rendesen megcsinálja a szükséges route-okat és tűzfal szabályokat, de a szerver oldalon - ami esetdben kliens is akar lenni - ezek értelem szerűen hiányoznak...

 

Ezeket a szerver oldalon biztosan lehet pótolni, de hogy az adott router csoda GUI-ja mit és hogyan enged, azt neked kell kideríteni

zrubi.hu

Hozzáférek parancssorból is.
Még nem igen derítettem fel (annyira megörültem) de talán egy vim szerű szövegszerkesztő van. Persze meg kell találnom, hol vannak a konfigurációs beállítások és amitől a legjobban félek, hogy tudom a beállításimat elmenteni (reboot után is betöltődjön).

A lényeg hogy az OpenVPN tudja és nem hiszem hogy nagyon drámain átalakították volna.

Végső esetben ott van az OpenWrt, ott biztos megoldható.

* Én egy indián vagyok. Minden indián hazudik.

( Zs | 2023. 05. 06., szo – 14:23 )

1 az openvpn a szerver mögötti hálót a klienseinek akkor teszi elérhetővé, ha a szerver oldali konfig tartalmazza az erre vonatkozó sort. (push-route)
a szerver oldali konfigba további push-route sorok is felvehetőek, így megoldható az a varázslat extra tűzfal- és router nélkül, hogy a kliensek mögötti subnet is látható legyen. Ekkor annyi a feladat, hogy kliens mögötti subnet esetén nem elegendő az ott elérhető subnetet egy push-route-tal felvenni, hanem kell egy kliens specifikus konfiguráció is, amelyben az iroute opcióval a fogadó informálható, hogy az iroute-ban megadott subnet ezen kliense mögött van.

2 client-to-client - ha megadod, akkor a kliensek látják egymást. A defailt, hogy nincs megadva és így a kliensek közötti forgalom tiltott.

Az Asus routereken engedhető telnet is és ssh is. Onnantól simán be lehet lépni és az openvpn konfig is átírható. De az tény, hogy ezek után a webes felületen történő konfig módosítás újra generálja a konfigot és így a manuálisan bevésett dolgok elvesznek. Szóval elvben megoldható tisztán ezzel a csavarral - de tény, hogy az, hogy az egész Asus routeren fut, elkerülte a figyelmemet és bár a megoldás így is lehet működő képes, de semmiképp nem elegáns és nem is biztonságos amiatt, hogy a konfig fontos elemei emiatt törlődhetnek úgy, hogy fel se fog tűnni a dolog, csak később, amikor nem működik.

( x-daemon | 2023. 05. 08., h – 12:36 )

nem openwrt van rajta? nem merult fel hogy az legyen? konnyebb dolgod lenne.

neked aztan fura humorod van...

( Zsugabubus | 2023. 05. 08., h – 12:36 )

Milyen routerek ezek? Milyen sebességet tudnak OpenVPN-el? Legutóbb még a jó öreg TP-Link 1043-al próbálkoztam, de annak 14MBit/s-nél vége volt.

A sebességet nem hiszem hogy kitudom mérni. A pesti oldal 1G/50M a nógrádi végponton (elvileg) 500M/50M.

Nem tudom mi fogja itt meghatározni a VPN sebességét, a sávszélességem vagy a router képességei.

OFF: Pesti végpontban vagyok, gondoltam megmérem.
ookla >900Mbps download és 0 upload, mi van?
gcore 343Mbps download és 37 Mbps upload.
vlmi bandwithplace 55/52 Mbps
google fiber 913/52 Mbps

Most akkor mit mértem?
Ha beindítom a VPN-t, találok vlmi pont-pont tesztet akkor mit mérek?
A VPN sebességet vagy a szolgáltatók közti sebességet?

* Én egy indián vagyok. Minden indián hazudik.

Mindkét irányban a legszűkebb keresztmetszet. Papíron tehát 50/50Mbit, a gyakorlatban meg ki tudja, mert ha különböző szolgáltatók akkor még a BIX-en vagy külföldön is megfordul a csomag (ugye a upc/vodafone-nak nincs bix tagsága)... Szóval akár nagyon gyötrelmes is lehet.

"Sose a gép a hülye."

Megnéztem gyorsan párat, már most valóban nem megy nemzetközire.

"kb utána nem sokkal selective helyett open peering is lett"

Nem tudom mit értesz a nem sokkal alatt, de hónapokig telian meg más külföldi gerincen ment a forgalom.

"Sose a gép a hülye."

( zrubi v | 2023. 05. 08., h – 14:44 )

Szerkesztve: 2023. 05. 08., h – 14:45

alapvetően abba a hibába estél, hogy a VPN-től vársz olyan dolgokat, amikhez (technikailag) a VPN-nek az ég világon semmi köze.

Ezek pedik a következők:

- routing.

Persze, tud a VPN is ezzel babrálni, de ez minden esetben a kliens oldaltól függ. pl hiába küld a szerver push-route üzenetet, ha a kliens ezt ignorálja.

- tűzfal szabályok, NAT (ha szükséges)

Attól, hogy van egy felépült tunnel, a tűzfalad jó esetben nem enged mindent mindenfelé :)

- Névfeloldás, és IP kiosztás

Ezek például egészen biztosan máshogy kell működjenek egy kliens-server és site-to-site esetén...

 

Igen, az ilyen csoda GUI-is varázslók megpróbálják számodra ezeket is beállítani, hogy végül működjön amit szeretnél.

De ez kizárólag akkor fog menni, ha az általad kívánt 'felállást' támogatja az eszköz/GUI -> lásd client->server vs site-to-site

zrubi.hu

( kisg v | 2023. 05. 14., v – 21:50 )

Driveby comment: ~10 évig használtunk OpenVPN-t, de ma már nem javaslom, helyette WireGuardot tennék inkább. Jobb teljesítmény, egyszerű összerakni. 

Aki a Wireguard-ot ajánlgatja Openvpn helyett, az linkeljen már leírást annak megoldására , hogy Radius-ból jöjjön a kliens IP és a split route lista amit le tud utána pusholni a kliensnek AD csoporttagság alapján,továbbá a kliens certificate TPM-ből jöjjön :).

Sok mindenre jó a Wireguard, de pont komplexebb kliens vpn megoldásnak nem igazán. A wireguard fölé írt kereskedelmi megoldásokat nem ideértve.

Hát azt, hogy egy VPN csatorna mindkét oldala lássa a másik oldal teljes hálózatát, ne csak a VPN végpontot, még pont nem a "komplexebb" megoldások közé sorolnám...

Amit leírtál, valóban komplexebb, de a kérdező nem említett sem RADIUS-t, sem AD-t sem hasonlókat.

Amit viszont szeretne, oda pont jó a WG.

( STP | 2023. 05. 15., h – 23:19 )

Én biztosan site2site VPN-t használnék. És a NAT mögötti kezdeményezi a kapcsolódást.

( ggallo | 2023. 05. 15., h – 23:47 )

Ahogy a többiek írják, site-to-site kapcsolat kell. Ebben semmi varázslat nincs, annyit takar, hogy a VPN szerver oldala elküldi a kliensnek a saját alhálózatát (hogy az felvegye a route táblájába, ez sima szerver-kliens felállás eddig), és annyi kiegészítés kell, hogy a szerver maga is vegye fel a kliens alhálózatát a kapcsolat felépítésekor. Így mindkét oldalnak meglesz, mit tud elérni a VPN kapcsolat túloldalán. Az OpenVPN-nél tudtommal nincs automatizáció arra, hogy a kliens is tudna ilyen infót küldeni a szerver felé az alhálózatáról, hanem a szerveren, a kliens-specifikus konfigba kerül be "iroute" tétel, ami tartalmazza a kliens oldali hálózatot.

A másik a kliensek közötti kommunicákó engedélyezése-tiltása. Ezt az OpenVPN szerver konfigban egy "client-to-client" tétel (így ahogy írom), és már engedi is a szerver (a hiánya a tiltás).

Persze mindkét esetben a megfelelő tűzfalakon a megfelelő forgalmakat engedni kell, a tűzfalhoz sohasem nyúl az OpenVPN.