Openvpn route

UNIX haladó

Udv Mindenkinek,
Egy tobb alhalozattal, tobb szerverrel rendelkezo halozatban levo openvpn letrehozasa a feladatom, de ugy, hogy
szerver oldalon kellene szabalyozni, hogy kliensenkent csak milyen halozathoz, ill. akar csak melyik szerverhez ferhetnek hozza. Itt a lenyeg a csakon van. Az termeszetesen ok, hogy a szerveren beallitom az adott routokat, de akkor barmelyik kliens barmelyik halozathoz hozzafer. Ezt kene valamilyen modon megakadalyozni.
Azert szerver oldalon, mert a kliens konfigban barmikor valtoztathato a kliens gep gazdaja altal barmi.
Koszonok szepen elore is minden otletet.

( zrubi v | 2019. 04. 02., k – 00:29 )

A routing ezt nem oldja meg.

Erre való a hálózati szegmentáció, és a szegmensek közötti tűzfal.

Ezt a feladatot persze sokszor maga a VPN szerver is el tudja látni.

Pl ha amúgy is külön network van dedikálva a VPN klienseknek, akkor amúgy is össze kell kötni a produktív hálózattal. Ilyenkor helyben nem csak egy "accept all" szintű tűzfalszabályt kell létrehozni, hanem akár kliensenként egyesével megmondhatod hová mehet "tovább"...

--
zrubi.hu

ilyenkor, ha csak simán "össze routolod" a VPN ip tartományt a telephelyekkel, akkor várhatóan a default ACCEPT policy van érvényben a FORWARD chainben.

Ha azt akarod, hogy csak az "menjen át" a VPN serveren amit te külön engedélyezel, akkor át kell állítani a default policy-t DENY-ra, és egyesével felvenni azokat az ACCEPT szabályokat amiket valóban engedélyezni akarsz.

Hogy ez pontosan hogyan néz ki az a oprendszered default tűzfalától függ.
De az biztos hogy így megnézheted mi van jelenleg beállítva:

sudo iptables -L -n -v

--
zrubi.hu

( franklin | 2019. 04. 02., k – 04:18 )

VLANok? Persze lehet hogy az előttem szóló kolléga is pont erre gondolt a "hálózati szegmentáció"-val - nem szoktam ezt a kifejezést használni.

Értelek, bár javíts ki ha tévedek, de úgy tudom a vlan és a subnet (én úgy tudom a subnet az alhálózat) azért két külön dolog.

Táblázatba szedve:
http://www.fiber-optic-transceiver-module.com/vlan-vs-subnet.html

A tűzfal amúgy meg, igen, egyáltalán nem rossz ötlet a szabályozásra.

Subscribe - érdekel a megoldás!

Az oké, a vlan a switchek lokális adatbázisában egy azonosító, amit szükség szerint az ethernet keretekhez lehet hozzácsatolni (ún. dot1q keretek formájában), hogy a másik is switch is tudja, melyik vlanból érkezett a keret, a subnet meg egy ip alhálózat, de olyan 20 éve is antipattern volt a nem "egy vlanhoz egy subnet tartozik" alapú tervezés.

( junior013 | 2019. 04. 02., k – 09:19 )

Kérdés, mennyire kell egyedileg szabályozni? Nálam régen ccd file-okban egyedi IP-k, meg route-ok voltak kiosztva és ezek tűzfalazva, de meguntam a file-ok szerkesztgetését. Most van 4 IP subnet-em megfelelően tűzfalazva és a kliensek AD group alapján a megfelelő subnet-ből kapnak IP-t és ezzel a megfelelő hozzáférést.

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Kissé bonyolultabb a dolog:
4 OpenVPN szervert használok redundancia miatt (2 host * UDP + TCP server) és mindegyiken 4 különböző /24-es subnetet, amik úgy vannak szétosztva, hogy jogosultsági szintenként összefoghatóak 1-1 /22-be, amikre külön tűzfal szűri a forgalmat.
A szervereken beállított alap IP tartomány a legkorlátozottabb, csatlakozáskor mindenki innen kap IP-t (erre persze lehetne használni egy külön, sehova nem vezető tartományt) és a user ellenőrzése után kerül át - szükség esetén - kedvezményezettebb tartományba (dinamikusan generált temp ccd)

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"