OpenVpn klienseknek publikus ip-t, hogyan?

 ( PcZolee | 2013. augusztus 22., csütörtök - 13:21 )

Sziasztok.

A következőt szeretném megoldani. Van egy távoli szerver, ami openvpn szerverként üzemel, itt van pár publikus ip-m, ezek az eth0:1, eth0:2, eth0:3, eth0:4 inteface-kre vannak beállítva, és semmire nincsenek használva.

Azt szeretném megoldani, hogy ezt a 4 ip-t openvpn-en keresztül kioszthassam klienseknek (4 kliens lenne, aki kapna, mert 4 ip-m van), úgy, hogy az ip-kre érkező forgalom is a kliensek irányába menjen tovább. Tehát úgy nézzen ki a dolog, mintha a klienseknek ez lenne a publikus ip-jük.

Köszönöm az ötleteket.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Érdekes ötlet. :)

Szerintem csinálj a klienseknek egy normál OpenVPN-t, amiben a default route is megy a tunnelbe. Aztan a szerveren a tunnelből jövő forgalomnak SNAT-al beállítod a megfelelő publikus IP címet, ami így kimegy a netre. A netről bejövő forgalmat meg DNAT-al átirányítod a VPN tunnelen keresztül a kliensnek.

Tehát a lényeg, hogy nem adod oda közvetlenül a kliensnek az IP címet, hanem NAT-olsz a tunnelen keresztül.

+1

Hmm, hát nem akartam ennyit natolni, de ha más megoldás nincs, megpróbálom, köszi az ötletet.

<= Powered By Ubuntu & Gentoo Linux =>

'Software is like sex: It's better when it's free!'
By Linus Torvalds

Mondjuk, hogy 10.50.0.0/24-ből kap címet kap a vpn kliens, a konkrét cím: 10.50.0.6.
Az eth0:0-án fel van véve egy publikus ip (pl: 1.2.3.4).

Ez így jó lehet:

iptables -t nat -A POSTROUTING -s 10.50.0.0/24 -o eth0:0 -j SNAT --to 1.2.3.4
iptables -t nat -A PREROUTING -d 1.2.3.4 -j DNAT --to 10.50.0.6

<= Powered By Ubuntu & Gentoo Linux =>

'Software is like sex: It's better when it's free!'
By Linus Torvalds

Válaszolok is magamnak ;), igen, ez így jó!

<= Powered By Ubuntu & Gentoo Linux =>

'Software is like sex: It's better when it's free!'
By Linus Torvalds

Vagy használj bridge módot. (TUN helyett TAP)

A NAT-olás szerintem biztonságosabb ilyen esetben mint a bridge ugyanarra az interface-re.

Jó-jó, de tudok bridgelni virtuális interface-re is külön-külön (eth0:x)? Mert ha igen, akkor ok.

<= Powered By Ubuntu & Gentoo Linux =>

'Software is like sex: It's better when it's free!'
By Linus Torvalds

Érdekes módon, nekem a tun valahogy lassabb mint a tap, pl a ping idők 2x annyik tun-nal, mint tap-al (p2p-re is tap-ot használok emiatt). Tapasztalt más is ilyet? Egyébként azt hiszem a legjobb a tap lesz bridge-vel ez alapján: http://serverfault.com/questions/431531/tunneling-a-public-ip-to-a-remote-machine

<= Powered By Ubuntu & Gentoo Linux =>

'Software is like sex: It's better when it's free!'
By Linus Torvalds

Anno kellett ilyet csinálnom. Mivel sok IP-ről volt szó, ezért a komplett /25 tartományt megkaptuk. A gép saját IP-vel gurult, a valós IP-ket osztotta. A tun driver limitációk miatt vitán felül tap kellett.
Később szolgáltató váltás történt, ez persze tartomány váltással is járt - és elbuktuk a gép külön dedikált IP címét. Ekkor a dolog fejre állt, mert a kliens pofára esett azon a tényen, hogy a fogadó IP ugyanabban a tartományban van, mint amit a VPN-en is oszt. Szerencsére sikerült külön IP-t szerezni - viszont a taromány nincs hozzánk route-olva. Emiatt egy meglehetőst csúnyácska megoldás született:
- a masinának van egy saját egyedi IP-je, ezen jönnek be a kliensek
- az openvpn úgy van belőve, hogy a tap és eth0 bridge-ben van és erre a bridge-re két IP is van húzva
- a konfigban csúnya módon az van hazudva, hogy a masina IP-je a GW IP. A valóságban persze nem, de így a redirect gw ezt az IP-t címzi ki és így működik is a stuff. de randa, illetve van egy IP-je a gépnek, amit nem használunk.

Tekintve, hogy nálad milyen kevés az IP és nem hiszek abban, hogy tudsz külön IP-t keríteni az OpenVPN-nek, marad a másik, többiek által is javasolt megoldás: NAT. Első kanyarban ezzel kísérleteztem, működött is - csak nem szép abban a tekintetben, hogy a kliens nem fogja látni azt a valós IP-t, amin forgalmaz, hanem csak azt a privát IP-t, amit a VPN oszt. Előnye ugyanakkor, hogy a VPN beállításokon, klienseken nem kell konfigurálni semmit. Pár megjegyzés ehhez a megoldáshoz:
- mindkét irányt NAT-olni kell! Tehát kell egy PREROUTING az eth0:1 --> tap0 irányhoz, hogy a forgalom bemenjen, de kell egy POSTROUTING is a tap0 --> eth0:1 irányhoz, hogy a kliens a valós IP-vel menjen ki. (Illetve igazából IP-nként/kliensenként 1:1 szabály, tehát a 4 klienshez 4 PREROUTING és 4 POSTROUTING lenne.)
- innen kezdve a kliens kikerül a netre direktben, tök mindegy, hány tűzfal mögül sunnyog ki. Tehát a kliens védelméről is illik gondoskodni ilyen esetben...
- még így sem biztos, hogy happy minden, mert a kliens továbbra sem ismeri a saját valós IP-jét. Ez olyan esetben, mint pl. ftp, amikor két kapcsolat is szükséges az adat átvitelhez, okozhat problémát, amikor az openvpn kliens a túloldalt kéri, hogy nyissa meg felé az adat kapcsolatot -és ehhez a privát IP-jét adja meg, mert mást nem ismer...

Szerk:
Ja igen. Nem haszontalan engedélyezni a FORWARD ágat sem - illetve bekapcsolni kernel szinten is a csomag továbbítás engedélyezését... :-)

Routinggal meg tudod oldani. A kliensre felhuzod a publikus IP-t mondjuk az lo interfacere, a VPN-ben pedig privat cimeket hasznalsz. A vegponton beallitod a route-ot es proxy ARP-olsz egyet hogy az ottani gateway azt higyje hogy a helyi halozaton van a cim. Persze ez csak akkor mukodik, ha nem zero konfig igenyu kliens kell.

A lo interface-t nem illik ilyenre használni - ha ilyen irányú igényeink vannak, akkor arra ott a dummy0 (a megfelelő kernelmodul betöltése után).
A proxyarp szép állat, kérdés, hogy ez elég-e, megfejelve a route-olással? Nem arra gondolok, hogy a csomag nem fog eljutni a klienshez - hanem hogy a választ a kliens a nála lévő routing tábla alapján merre fogja kiküldeni? Ha a default gw. felé megy a válasz, az élből gáz. Ha azon az interface-n akar kimenni a csomag, ami IP alapján lenne illetékes, az sem fog célba érni. Persze megfelelő kliens oldali route-olással ez sem megoldhatatlan (írtad is hogy nem zéró konfig igányű kliens esetén működik csak), de miért válasszuk a bonyolultabb megoldást, ha van egyszerűbb is? (Persze ha valaki tanulni akar, akkor miért ne? De esetünkben mintha nem erről lenne szó...)

Tok mindegy, valami lokalis IP kell. Egyebkent ezt az lo dolgot elmondhatod az IPVS doksi gyartoinak is. Egyebkent javits ki, de gyakorlatilag pont tok mindegy, hogy hova veszed fel.

Köszi mindenkinek a tippeket, egyelőre tun-al oldottam meg natolva (snat és dnat, nameg forward engedve ;) ). Így úgy látom minden rendben megy, és a kliens oldalon semmit nem kell állítani, amit kell azt meg az openvpn szerver átküldi. Pont erre volt szükségem ;). Nincs olyan felhasználás, ami miatt a tap kellene, ha majd lesz, meglátjuk, azzal hogy megy ;)

<= Powered By Ubuntu & Gentoo Linux =>

'Software is like sex: It's better when it's free!'
By Linus Torvalds