Az iránt érdeklődnék - mivel vannak itt talán nálam gyakorlottabbak - , hogy hogyan tudom egy OVPN kapcsolat mellett a belső hálózatomat és a kiszolgálókat védeni a TUN kapcsolaton keresztül bejövő kliensektől.
A problémám igazából az, hogy a TUN kapcsolaton bejövő klienseket nem tudom teljesen megbízhatónak tekinteni (főleg a miatt, hogy egy-egy netre gyakorlatilag közvetlenül kapcsolódó win-ről van szó), ezért jó lenne őket egy kissé elszeparálni a tényleges belső hálózattól. Ezt a TUN használata elég jól lehetővé teszi, hiszen egy külön (virtuális) alhálózatban gyülekeznek a kliensek. A problémám az elgondolásommal az, hogy az alagút végpontjának tüzfalazása (iptables) tönkre teszi az alagutat (ezt írja egyébként az ovpn doksija is).
Ezért érdeklődnék a gyakorlotabb kollégáktól, hogy milyen módszerrel lehetne egy kicsit még is elszeparálni az alagutat a belső hálóról (sajnos az átmenő forgalom - forward - szűrését nem tartom teljesen jó megoldásnak, mert azon a gépen, ahol az alagút végpontja van, még esetleg mindig igénybe vehetnek vagy támadhatnak olyan szolgáltatást, amely nem nekik van szánva).
- 1040 megtekintés
Hozzászólások
kliensek ----(tunnel)---->VPN szerver ---->tűzfal szerver---->belső háló
- A hozzászóláshoz be kell jelentkezni
Az ötlet jó, kár hogy nincs módomban erre külön gépet használni :-( .
Zavard össze a világot: mosolyogj hétfőn.
- A hozzászóláshoz be kell jelentkezni
Az openvpn szervert berakhatod valami virtualizációval egy guest oprendszerbe, a host-on pedig tűzfalazol... kicsit körülményesebb, és jobban meg kell tervezni, de akár ez is lehet egy pótmegoldás...
- A hozzászóláshoz be kell jelentkezni
"az alagút végpontjának tüzfalazása (iptables) tönkre teszi az alagutat"
Nemtom, mit kell érteni ez alatt, biztos vannak olyan szabályok amik árthatnak a vpnnek, de szerintem ez így mindenre nem igaz. Én olyan tűzfalszabályokat használok cégnél, amelyek az INPUT és a FORWARD szálon is szűrik a forgalmat, néhol számít hogy ez vpnes, néhol bejövő interfésztől független a szűrés.
Szóval szerintem próbálkozz nyugodtan a forward szűrésével.
- A hozzászóláshoz be kell jelentkezni
"az alagút végpontjának tüzfalazása (iptables) tönkre teszi az alagutat"
Gondolom arra gondol, hogy a VPN virtuális adapterére alkalmazott tűzfalszabályok...
- A hozzászóláshoz be kell jelentkezni
Na ez így biztos, hogy nem igaz. Írok pár példát a saját tűzfalscriptemből, nekem ezek műxenek:
VPN_IP="10.10.0.1"
VPN_IP_RANGE="10.10.0.0/24"
VPN_IFACE="tun0"
[...]
$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
$IPTABLES -P FORWARD DROP
[...]
$IPTABLES -A tcp_packets -p TCP -s $VPN_IP_RANGE --dport 135:139 -j allowed
$IPTABLES -A tcp_packets -p TCP -s $VPN_IP_RANGE --dport 445 -j allowed
$IPTABLES -A FORWARD -p tcp --dport 110 -i $VPN_IFACE -j ACCEPT
$IPTABLES -A FORWARD -p tcp --dport 137:139 -i $VPN_IFACE -j ACCEPT
[...]
Alapból a Samba elérés tilos, ellenben a vpnről (és a belső hálóról) engedélyezett.
Ha dobsz egy privit, elküldöm neked a scriptet. Bár elég nagy benne az összevisszaság, tisztítanom és egyszerűsítenem kellene már a kódot, de azért remélem el lehet benne igazodni.
- A hozzászóláshoz be kell jelentkezni
Ha dobsz egy privit, elküldöm neked a scriptet
Nekem nem kell, én is valami hasonlót használtam OpenVPN-re.
Szerintem ez teljesen kielégítő megoldás, ha nincs kéznél független tűzfal..
- A hozzászóláshoz be kell jelentkezni
Bocsánat, összekevertelek a topiknyitóval.
Tudom, tanuljak meg olvasni.... ;-)
- A hozzászóláshoz be kell jelentkezni
Sajnos nem állt módomban hamarabb válaszolni, ezért elnézést kérek mindenkitől. Köszönöm a válaszokat is, különösen a tűzfal szabályokkal kapcsolatos infókat.
Azt alatt, hogy az alagutat nem lehet tűzfalazni, konkrétan úgy értettem, hogy az INPUT láncba -i tun0 opcióval nem használható szabály. Ezt az ovpn leírásából vettem, a how-to még külön hangsújozza is a tűzfal kikapcsolását a tunnelen (mindjuk egy gyors tesztet is csináltam rá, és utána nekem tényleg nem épült fel az alagút, amíg el nem ávolítottam a rá vonatkozó szabályokat).
Ezzel együtt úgy tűnik, hogy a helyzet mégsem olyan egyértelmű, hiszen ennek elenére ezek szerint lehetséges jól megtervezett tűzfal szabályokat felépíteni rá.
Zavard össze a világot: mosolyogj hétfőn.
- A hozzászóláshoz be kell jelentkezni
ertelmes openvpn terminalo (virtual)gepen amugy sem fut semmilyen mas szolgaltatas sem (ssh sem).
(serial terminal ugye.)
- A hozzászóláshoz be kell jelentkezni
ezért jó lenne őket egy kissé elszeparálni a tényleges belső hálózattól
Miert nem probalod meg a TAP-ot? Ugy egy onnallo szegmenst is ossze tudnal allitani ezekbol a nem megbizhato gepekbol. Igaz, akkor a kliensoldalon muszaj alairt tanusitvanyt tarolni, ami mondjuk nem feltetlenul baj. Igy talan a tuzfalat/route-olast is konnyebb megcsinalni. Raadasul ezalatt is van dhcp.
A.
- A hozzászóláshoz be kell jelentkezni
Azt hiszem itt lessz a másik fele a megoldásnak.
Eredetileg azért választottam a másik módszert, mert néhány kliensnek olyan szolgáltatásokat kell malyd igénybe venne, amelyek előre nem meghatározható típusú forgalmat generálnak (ala: ms távoli eljárás hívás + dcom), és eredetileg arra gondoltam, hogy az rpc lokátor így talán megbízhatóbb lessz.
Aztán menet közben kételyeim támadtak a dologgal kapcsolatban (főleg biztonsági szempontból) ezért kezdtem el agyalni a dolgon (+nyitottam ezt a szálat) mielőtt élessé válik a cucc.
Azt hiszem még kicsit dolgoznom kell rajta, de összeségében minden értelmes lehetőség előkerült. Most már csak egy optimális határt kell húzni a lehetőségeimnek és kockázatoknak megfelelően.
Köszönöm a segítségeteket.
Zavard össze a világot: mosolyogj hétfőn.
- A hozzászóláshoz be kell jelentkezni