Sziasztok,
Van egy szolgáltatói NAT mögötti eszköz, amit szeretnék kívülről elérhetővé tenni egy publikus IP címről. Nem tudom van-e erre jobb megoldás, de egyelőre az OpenVPN-t tanulmányozom, hogy használható-e erre a célra. Előre bocsátom a hálózatokhoz ennyire mélyen sajnos nem értek, így egyelőre csak homokozásról van szó, semmi több. :-) Ha esetleg van erre jobb és elegánsabb megoldás, akkor szívesen fogadom a javaslatokat!
Ami nagyon fontos lenne, hogy nem csak az eszköz adott portjait akarom elérhetővé tenni, hanem cakk-pakk mindenét. Igen, ez felvet némi biztonsági problémát, de egyelőre nem akarok vele foglalkozni (a későbbiekben talán ip szűréssel oldanám ezt meg).
Az ismertetett problémát én a következőképpen gondoltam megoldani:
A képen egy nagyjábóli topológia van, amin csak a lényeg látszódik. A routerek nem tudom mennyire fontosak a vpn szempontjából, ezért inkább ráraktam őket is.
Szóval, A NAT mögötti eszköz, a VPNClient2 kapcsolódna az OpenVPN szerverhez (Server), aminek két publikus IP címe van. Az egyik IP címet (87.120.0.10) dedikáltan odaadnám, pontosabban ráirányítanám a VPNClient2-re.
Ha jönne egy külső kérelem, pl. User-től az említett publikus IP címre, akkor a Server továbbítaná a kérést VPNClient2 felé, aki válaszolna rá, majd a Server ugyanígy továbbítaná a választ a User felé, tehát egy oda-vissza kapcsolat lenne közöttük.
A kérdésem, hogy ez az elképzelés így megfelelő lehet vagy komoly problémák vannak vele kapcsolatban? A VPN szerveren futna egy shorewall is, de egyelőre nem látom át, hogy hogyan tudnám az említett ip címre érkező forgalmat továbbirányítani a vpn kliens felé és fordítva. Ha jól gondolom, akkor prerouting és postrouting kellene nekem?
- 1870 megtekintés
Hozzászólások
Jól látod.
Prerouting, hogy a szerverre érkező forgalom tovább legyn lökve a client2 felé.
Postrouting, hogy a client2 úgy érezze, hogy a szerver szól hozzá és ezért a válasz csomagot arrafelé tolja vissza.
Ezen felül nem haszontalan az alapban kikapcsolt forwardingot engedélyezni, a route-olást átgondolni, de leginkább: tűzfalazni.
- A hozzászóláshoz be kell jelentkezni
A pre-részével egyetértek.
De a postroutingban miért is akarod kinyírni azt az információt, hogy mi is az eredeti forrásip? Tök értelmetlen butaság!
Azért mert látsz egy problémát, amire nem tudod mi a megoldás (pl. pbr), attól még nem kellene egy ekkora nagy butaságot elhinteni, ami legjobb megitélés szerint is csak egy harmatgyenge workaround, ami a gyakorlatban nagy valószínűséggel több további problémát fog behozni, mint amennyit megold.
- A hozzászóláshoz be kell jelentkezni
Szerintem ezt folytassuk lentebb... ;-)
- A hozzászóláshoz be kell jelentkezni
Ez egy mezei NAT-olas a megfelelo (vpn client) ip-re.
"Ami nagyon fontos lenne, hogy nem csak az eszköz adott portjait akarom elérhetővé tenni, hanem cakk-pakk mindenét."
Ezt meg felejtsd el, azt natold ki ami kell. A tobbi kuka. Kb tuzfalazas 1. szabalya.
- A hozzászóláshoz be kell jelentkezni
+1
Nem kliens oldali hálózaton vannak teendők.
- A hozzászóláshoz be kell jelentkezni
Mivel az elérendő eszköz nat mögött csücsül, amit nem a kérdező adminisztrál, így a befelé irányú natolást nem tudja megcsinálni. A megoldás ilyenkor vagy 1:1 statikus natot kérni az adott eszközre, vagy ha cgnat, akkor kérni, hogy vegyék ki belőle az adott végpontot, vagy ha egyik sem megy, akkor az érintett eszközről indítani vpn-t egy külvilágban lévő saját eszközre, ott meg routinggal/portforwarddal/egyebekkel szépen össze lehet rakni az elérést.
- A hozzászóláshoz be kell jelentkezni
Mivel az elérendő eszköz nat mögött csücsül < nem relevans, openvpn client lesz rajta, belso IP-vel, a vpn ip-re fog natolni az abra szerint.
A tobbire kb. +1, de azt nem tudjuk, hogy miert nem lehetseges ott helyben a forward(esetleg mas eszkoz hasznalja a pub ip-t pl.?), vagy, hogy van-e egyaltalan fix IP.
- A hozzászóláshoz be kell jelentkezni
A "mezei NAT" karcsú lesz. Ahogy azt a kérdező is felvetette, kelleni fog neki postrouting, igazából masquerade.
Az a helyzet, hogy nem elég a csomagot tovább lökni a megfelelő irányba: azt is biztosítani kell, hogy a válasz is ugyanazt az útvonalat használja! Ha kimaradt a MASQUERADE, akkor a client2 megkapja az eredeti forrás IP-t, tehát amikor a válasz csomagot generálja, akkor oda a cél IP-nek az eredeti forrás IP-t fogja behelyettesíteni - teljesen jogosan és logikusan -, majd utat választ ehhez az IP-hez. Ez az út nagyon nem a VPN irány lesz - így viszont az eredeti forrás gép azt fogja látni, hogy jött egy válasz valakitől, akihez nem is szólt, ellenben akinek kiabál, az nem válaszol. A MASQUERADE jutalma lesz az, hogy bár így a client2 az eredeti forrás IP-t nem látja, de a választ tuti a VPN fogadó felé fogja tolni - azon meg a tűzfal szépen visszaállítja a csomag eredeti paramétereit és kitolja az eredeti kliensnek.
- A hozzászóláshoz be kell jelentkezni
ez abban az esetben igaz, ha nem az openvpn iranyaba mutat az alapertelmezett atjaro, egyebkent nem szukseges.
- A hozzászóláshoz be kell jelentkezni
Ahogy fentebb is írtam: a probléma megoldására válaszul ne egy másik problémát hozzunk be!
Ahogy írtad is: a probléma az, hogy visszataláljon a válaszcsomag, arra amerre neki mennie kell.
De az, hogy közben tökönlövöd magad, és elrejted a vpn mögé tett szerver elől az eredeti kliens ip-ket, az azért elég erős!
Rendesen be kell állítsa a routingot és ennyi.
Ha a kliens mögött nincs másik gép/ alhálózat, akkor tök egyszerű a rule is, amit fel kell venni: ha a srcip a vpn-ipje, akkor vpn-es table, egyébként, meg mehet a default "normál"-os irányba.
A vpn-es table-be meg elég kb. a vpn alhálózatát "directly connected"-ként felvenni + defaultroute-ot a vpngw-n át.
Összetettebb esetben meg lehet connmarkolni. Arra is van tonnányi leírás. Akkor meg a rule mehet connmark alapján.
- A hozzászóláshoz be kell jelentkezni
Vesézzük ki itt a problémát.
1) Nem hangzott el, hogy az OpenVPN kliens nem csak kapcsolódik a szerverhez, de az is lesz a default gateway. Ha ez nincs így, akkor valamilyen módon biztosítani kell, hogy a visszairány jó legyen. Tehát az észrevételemnek van alapja.
2) Nincs okunk azt feltételezni, hogy a kliensen az OpenVPN kapcsolat egyben default gateway is lenne, mert ez szintén okozhat problémát. Csak hogy párat említsek: a kliens saját forgalma is át fog menni a VPN-en, pedig erre nem feltétlenül van szükség. Ha az OpenVPN persist paraméterrel fut és leül a fogadó, ugrik a kliens kapcsolata a teljes internet felé. Szóval ez a default gateway beállítás nem feltétlenül a legjobb ötlet.
3) Az általam írt megoldás valóban ad egy olyan problémát, hogy elrejti az eredeti forrás IP-t. Ami kérdés, hogy:
- szüksége van-e erre a kérdezőnek?
- ha igen, akkor nem elegendő-e ezt a szerveren naplózni?
Egyébként lőhetünk ágyuval verébre is, pl. rinetd, bár amiatt, hogy a kérdező az összes portot be akarná tolni, ez nem feltétlenül jó ötlet és a client2 továbbra sem látná a forrás IP-t.
No de akkor lássuk, mi az ultimate weapon?
Csináljuk meg úgy a tűzfalat, hogy azt mondjuk, két WAN lába van! Egyik a valós WAN láb, a másik meg az OpenVPN kapcsolat lába. Majd intézzünk policy routing-ot és mondjuk azt, hogy az innen induló és új kapcsolatot nyitó csomagok a WAN lábon lépnek ki, ellenben minden más esetben azon a lábon kell kilépnie a csomagnak, amelyiken a kapcsolat (pontosabban a kapcsolathoz tartozó korábbi csomag) bejött.
Így már jó? ;-)
Mondjuk lényegesen bonyolultabb az eredetinél, viszont valóban szebb megoldást ad.
- A hozzászóláshoz be kell jelentkezni
Szolgáltatónál jelezni, hogy neked nem jó CGNAT mögött csücsülni? A biztonsági problémákkal/tűzfalazással meg előre, még az induláskor _kell_ foglalkozni, mert utólag a "majd tiltom, ami nem kell" konvergenciája khm. nem túl jó. A nyugodt alvás záloga a mindent tilos, és ami kell, azt átgondolni, és ha tényleg, akkor kinyitni - így ugyanis biztos, hogy csak az lesz/marad nyitva, amire szükség van.
- A hozzászóláshoz be kell jelentkezni
Szerencsére nem az én internetkapcsolatomról van szó, hanem egy ismerőséé. :-) Megpróbálták felkeresni a problémával a szolgáltatójukat, de ők nem vevőek rá vagy csak borsos áron... Mivel személy szerint amúgy is érdeklődőm a VPN-ek iránt, ezért gondoltam tanulásnak jó lesz ez a kis projekt.
A tűzfalazással kapcsolatban egyébként igazad van, csak még nem teljesen tisztult le, hogy pontosan milyen szolgáltatásokat akar kilógatni a netre. Egyelőre azon vagyok, hogy legalább a nat mögötti klienst el lehessen érni publikus ip-ről, ha ez meg van, akkor tesztelgetünk még (tehát nem fog élesben menni 0-24h), aztán jöhet a védelem és az éles üzem.
- A hozzászóláshoz be kell jelentkezni
A CGNAT-mögül ki kéne szedni az ügyfelet - hacsak nem valami ócska gyagyibété-szintű "szolgáltató"-ról van szó. A fix publikus ip az persze más kérdés, azt nem osztogatják olcsón, ez igaz, de arra meg ott van az n+1 dinamikus dns szolgáltatás.
- A hozzászóláshoz be kell jelentkezni
Kicsit változtattam az ábrán, mert nem volt teljesen átgondolva:
A helyes útvonal úgy néz ki, hogy User beüti a böngészőbe a 87.120.0.10-et, az alsó routeren keresztül eléri a Server-t, majd onnan megy a NAT-olás a VPNClient2 felé a felső routeren keresztül. Bár ez a megvalósítás szempontjából lényegtelen, csak akkor már legyen jól ábrázolva az útvonal.
Most ott tartok a kivitelezésben, hogy a VPN kapcsolat él, a VPN-en keresztül az eszközök látják egymást (kliens->kliens, kliens->szerver, szerver->kliens ping megy), de a NAT-olás az istenért sem akar működni. Valamit vagy nem értek vagy nagyon elrontok.
Ha jól értem, akkor 1:1 NAT-ot kellene felhúznom?
A shorewall leírása alapján bekonfiguráltam az 1:1 NAT-ot, de amikor a publikus IP-n keresztül el szeretném érni a vpn mögött csücsülő klienst, akkor nem történik semmi. A shorewall logban sincs semmilyen bejegyzés róla. Az elérni kívánt vpn kliensen (ami a saját gépem) egyébként egy gyorsban letöltött lighttpd fut kikapcsolt tűzfallal, tehát biztosan nem blokkolja semmi a kapcsolatot.
Mit rontok el?
Az shorewall konfiguráció a következő:
https://pastebin.com/uushdy63
- A hozzászóláshoz be kell jelentkezni
a router1 es router2-t nem igazan tudom ertelmezni a feladat szempontjabol, de ettol eltekintve en igy oldanam meg:
- openvpn server config-ba (vagy a megfelelo ccd-be):
push "redirect-gateway def1"
vagy
push "redirect-gateway local def1"
ill. igeny szerint lehet meg
push "dhcp-option DNS az.en.dnsem.ipcime"
ezzel a kliens oldalrol a tortenet keszen van, a vpn-en keresztul fog kimenni az internet fele (is)
- server, iptables nat szabalyok:
SNAT internet fele a vpnclient2-nek
iptables -t nat -A POSTRUOTING -j MASQUERADE -o ens3 -s 10.0.0.10
DNAT vpnclient2 fele
iptables -t nat -A PREROUTING -j DNAT -d 87.120.0.10 --to-destination 10.0.0.10
a forwarding-ot nem art bekapcsolni a szerveren:
echo 1 > /proc/sys/net/ipv4/conf/all/forwarding (nem biztos hogy emlekezetbol helyesen irtam)
ezen tuzfal szabalyokon felul kell meg a filter tablaban rendes szurest is kesziteni ertelemszeruen.
ui.: shorewall-t nem ismerem, egyszer futottam bele, nem tetszett.
- A hozzászóláshoz be kell jelentkezni
Köszi, át fogom nyálazni a megoldási javaslatodat.
"a router1 es router2-t nem igazan tudom ertelmezni a feladat szempontjabol"
Igazából arról van csak szó, hogy a szervernek a szolgáltató két külön tartományból osztott IP címet, amiknek közük nincs egymáshoz, ezt kívántam jelezni a 2 routerrel. Megvalósítás szempontjából én úgy gondolom, hogy nincs jelentősége.
- A hozzászóláshoz be kell jelentkezni
minek ide nat? miert nem oldod meg layer2-n? gre, l2tp vagy openvpn tap device, a szerveren osszebridgelve az uplink porttal, a kliensen pedig a public ip beallitva a vpn (ppp/tap) interfacere?
- A hozzászóláshoz be kell jelentkezni
Ha nincs rá szükség, miért lenne értelme +1 fölösleges layert átszuszakolni a szerver és a kliens közt?
Nat se feltétlenül szükséges, ha már itt tartunk. Akár proxy-arpolhat is.
De a legtisztább, legkevesebb hibalehetőséget magában rejtő megoldás (szerintem) a nat + pbr a kliens oldal felől.
- A hozzászóláshoz be kell jelentkezni