OpenVPN - forgalomirányítás

Hálózatok általános

Sziasztok!

 

Hogyan lehet rábeszélni az openVPN klienst hogy csak a célhálózat (192.168.76.x) felé kommunikáljon, az összes többit engedje a normál internet kapcsolaton keresztül?

  • 1023 megtekintés

( secretx v | 2020. 03. 19., cs – 15:34 )

redirect-gateway

Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

( sibike | 2020. 03. 19., cs – 15:39 )

Szerver vagy kliens oldalról szeretnéd kikényszeríteni?

( NevemTeve | 2020. 03. 19., cs – 15:44 )

Ha ez Unix, akkor egy külön scriptet lehetne tákolni, ami újra helyreállítja a routing táblát a VPN-connect után. Ha Windows... hát, végül is ott is van ROUTE.EXE, talán meg lehet próbálni valamit.

( FoREE | 2020. 03. 19., cs – 15:49 )

a kliens konfigból vedd ki a redirect-gateway sort

vagy

a szerver konfigból vedd ki a

push "redirect-gateway ..." sort

ez így jó, csak most nem megy a névfeloldás.

# Set your primary domain name server address for clients
push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"
# Prevent DNS leaks on Windows
push "block-outside-dns"

gondolom ezt kellene felülírni, de mi a kultúrált(biztonságos) megoldás? vagy simám adjam meg másodlagosnak a google DNS-t?

Bocs, nem kötekedés.

A kérdés mondatot értelmetlen.

Az openvpn kliens csak és kizárólag "a célhálozat" felé kommunikál. nálad a 10.8.0.0/x hálozaton, a szerver 10.8.0.1 és a kliensek 10.8.0.x

A szerver gép privát hálozati oldala, amit el akarnak érni a kliens gépek, nálad 192.168.76.0/24.

Szerver oldalon "push"-al tudsz átadni(lenyomni) a kliensgépeknek hálózati beállításokat. Itt ami hiányzott a push route a 192.168.76.0/24 felé. Ehhez a kliens configban kell pull opció.

kézzel probáltad winen a routot hozzáadni ami lehetséges, de hiányzott metric érték és esetleg interface is.

Viszont volt a szerver configban push block-outside-dns, ez akadályozta meg, hogy a kliens tudjon a vpn tunnel kivüli dns-t elérni.

De lehet én értem rosszul a kérdést :)

Jól látod.

Eleinte azt gondoltam meg lehet oldani kliens oldalon a feladványt (ennek az eredménye lett a route-os próbálkozás amit -így utólag látva- a dns tett tönkre).

Az iránymutatások alapján ez áttolódott szerver oldalra (így legalább a már kiadott .ovpn -t nem kell piszkálni és egységesen mindenkinek változnak a beállitásai ). Összefoglalva a szerver konfig változtatásokat ezek történtek:

- kikerült a dns-el kapcsolatos 3 sor és a push "redirect-gateway..."
- bekerült a push "route 192.168.76.0 255.255.255.0"
és mindenki boldog (egyenlőre :) )

 

Tovább olvasva a hozzászólásokat vtommy https://hup.hu/comment/2455503#comment-2455503 megoldása kliens oldalon szerintem működik (valószínűleg szerinte is, kölönben miért írta volna be :D )

<Tapló grammar nazi benyögésbe bújtatott rejtett subscribe>

és mindenki boldog (egyenlőre :) )

Valószínűleg te boldogabb vagy, mint a többiek, mert neked közben a probléma megoldásának sikerélménye is megadatott ;)

</Tapló grammar nazi benyögésbe bújtatott rejtett subscribe>

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

( STP | 2020. 03. 19., cs – 17:13 )

Netwok-manager használatakor egy pipa az egész.

A gondolatolvasó tanfolyam lehet hogy zárva van, bezzeg az egóerősítés 2.0-át kiválló eredménnyel végezted. idejössz bemondod a tutit az egy pipás megoldásoddal és amikor rákérdeznek a huncut részletekre akkor vagy hallgatsz vagy -mint esetünkben- elkezdel kérdezni, Ugye  ... Szóval gratula az offtopic-hoz
 

( vtommy | 2020. 03. 19., cs – 20:49 )

Ha jól sejtem az a gond, hogy minden home office emberke a VPN-en keresztül nézi a Netflix-et :)

A kliens konfig elejére kell ez a sor: (én közvetlen a client után szúrom be)

pull-filter ignore "redirect-gateway" 

A végére pedig:

route 192.168.76.0 255.255.255.0 vpn_gateway

Indítsd el előtte böngészőben valamelyik whatismyip oldalt, és nézd meg utána is :)

Persze ha valaki tud egyszerűbbet, ne tartsa magába, mert én jobban szeretném szerver oldalon megoldani...

Örülök, hogy ezt így megbeszéltétek egymás között, de nálam 10+ éve alap egy céges (kkv) infrastruktúra felépítésénél, hogy legyen mobil, mert bármelyik pillanatban jöhetnek meglepetések. (Ez a jelenlegi helyzet pont nem volt betervezve).

Lehetnek betegségek, leéghet, beázhat az épület, sok a külsős bedolgozó stb...

Itt ha megemlíti valaki, hogy G Suite, a legtöbb fórumban mintha sátánista lenne. Az ügyfeleim 95%-a G Suite alapokon van, a maradék osztozik O365 és egyéb valamelyik gagyi szolgáltatáson. Az elmúlt tizen évben én szerencsére ennek csak az előnyeit éltem át. Jelenleg a legtöbb ügyfelemnél fel sem merült a hogyan oldjuk meg a történetet, mert az alap rendszer van így kialakítva, tehát egyszerűen csak normál munkanapként megy tovább minden.

Gond inkább csak a nagyobb anyagokat mozgató operátori gépekkel, mérnöki tervezőgépekkel + hardverkulcsokkal volt most. A legtöbb itt is megoldható, de inkább csak az okozott gondot, hogy túl sok a gép egyszerre több ügyfélnél (+ a hiszti faktor).

Szóval akinek most kell nulláról kialakítania ezeket annak nem jósolok nagy jövőt...

Amúgy meg no offense, dőljünk hátra és élvezzük a munkánk gyümölcsét, az elégedett ügyfeleket :)

Szóval akinek most kell nulláról kialakítania ezeket annak nem jósolok nagy jövőt...

De miért? Hidd el, nálunk nem az infrastruktúra a termék, hanem a kód amit előállítunk. A cég jövőjét az határozza meg, hogy ezt hogy tudja eladni és mennyire van kereslet az általunk kínált munkára. Szerencsére nagyon is van. A munkához pedig elég egy laptop pár alapszoftverrel a felhőben lévő szolgáltatásokkal. Tehát tök jó a backup, és van is, de arra nincs szükség, hogy a polcokon rohadjon ötven laptop amiből normál esetben néhány van használatban.

Amúgy meg no offense, dőljünk hátra és élvezzük a munkánk gyümölcsét, az elégedett ügyfeleket :)

Teljesen jogos. 

A Netflixet pont nem tudom, de ha a derék admin univerzális routernek állítja be a VPN interface-t a kliens gépén, akkor minden hálózati forgalom arra próbálna menni, még akkor is, ha egyébként kérik a munkásembereket, hogy pl. a MS Teams/Skype/etc videokonferenciát ne a VPN-en keresztül nyomassák.

Kétféle koncepciót láttam, az egyik távoli asztal kapcsolattal belép a 'benti' desktop gépére és azon dolgozik; a másik megoldás az, hogy nincs ilyen közvetítő gép, hanem a fizikai gépen dolgozva igény szerint használja a céges szervereket SMB/FTP/ssh/HTTP/Sql*Net/stb módon, a VPN-kapcsolaton keresztül. Ettől még a világmindenség többi részétől nem kell elválasztani a gépet, csak a routingot és a DNS-t kell jól beállítani.

A VPN fogadó oldala két módon konfigurálható:

- megadod, hogy a VPN túloldalán milyen hálózato(ka)t érhetsz el. Ha nő a belső hálózat, akkor egyre nagyobb a lista, hogy mi mindent érhetsz el. Egy idő után ilyenkor a VPN beállítás módosul:

- nem tökölsz azzal, hogy megadd, mi minden van a VPN túloldalán, hanem egyszerűen beállítod, hogy az a default gateway. Slussz! Innen kezdve nem kell azzal szöszölni, hogy 50 subnet listáját sorolod fel, mert minden ide jön. (Megjegyzem: céges policy is előírhatja, hogy ha kapcsolódsz a céges hálózathoz, akkor a teljes neted áthalad a céges tűzfalon is, azaz a "céges védelem" mögé kerülsz.) Na ilyenkor van az, hogy a kliens nem céges forgalmai is hirtelen a VPN sávszélességét harapja.

Én azt gondoltam hogy több funkciót is biztosít, és esete válogatja, hogy ezek mely kombinációja fontos a felhasználónak vagy az adminnak. Van ahol csak az a szempont, hogy az a pár intranetes oldal ami a munkához kell elérhető legyen. Van ahol monitorozni akarják a munkát. Igények változóak, gondolom ezekre mind tud eszköz lenni.

Nyugi, csak a "a derék admin univerzális routernek állítja be a VPN interface-t" nálam kicsit pökhendi beszólásnak tűnt igy elsőre, de valószínűleg csak túlreagáltam.

Az én álláspontom az, hogy van az alap VPN felépítés (ott igenis a céges tűzfalon megy át minden forgalom és nincs külső elérése a kliensnek), meg persze van az ettől eltérő igény, ahová az OpenVPN-t ideálisan át lehet konfigurálni szinte bármire. Max mire kijátszod hogyan lesz megfelelő neked, addig átrágod magad pár száz oldalnyi leíráson.

Nyilván megint én vagyok a hülye, de most egy ilyet látok a routingban (Windows):

Destination      Netmask          Gateway      Interface     Metric
172.217.168.0    255.255.255.0    10.0.0.1     10.100.0.teve 2

Ezzel vajon mit akartak elérni a kis tudósok? Ellenőrizni, hogy én mit google-zok? A jó hír az, hogy "route delete "-re rámondja, hogy "OK", csak nem hajtja végre. Nagy dolog az ámítástechnika.