Adott egy teljesen jól működő OpenVPN szerver Leap 15.5-ön. (IP: 10.66.4.3)
Alapból a hozzá csatlakozó felhasználók (ez csak én vagyok jelenleg) látják a teljes hálózatot.
Ehhez engedélyeztem az ip továbbítást és az openvpn szerver konfig vonatkozó része így néz ki:
server 10.8.5.0 255.255.255.0
ifconfig-pool-persist /var/run/openvpn/ipp.txt
push "route 10.66.4.0 255.255.255.0"Felvettem egy tűzfal szabályt:
ipv4 -t nat -A POSTROUTING -s 10.8.5.0/24 -o eth0 -j MASQUERADEMint írtam, a vpn így teljesen jól működik.
Viszont felmerült az igény, hogy külső felhasználók hozzáférjenek a belső hálózaton futó samba fájlszerveren (IP: 10.66.4.5) megosztott mappákhoz.
Ezt én úgy gondoltam megoldani, hogy beállítok egyedi felhasználói hozzáférést az OpenVPN szerveren és onnan csak a samba irányába engedem tovább az adott felhasználókat.
Ehhez felvettem az opnvpn szerver konfigba egy új virtuális IP tartományt és megadtam a felhasználói konfig fájlok helyét:
route 10.8.55.0 255.255.255.0
client-config-dir ccdA ccd mappában létrehoztam egy konfig fájlt a felhasználónak az alábbi tartalommal:
ifconfig-push 10.8.55.1 10.8.55.2
iroute 10.8.55.0 255.255.255.0Majd hozzáadtam egy tűzfalszabályt:
ipv4 filter FORWARD 0 -i tun0 -s 10.8.55.0/24 -d 10.66.4.5 -j ACCEPTA felhasználó és az openvpn szerver között hibátlanul létrejön a kapcsolat, a felhasználó gépe megkapja a 10.8.55.1 ip címet.
Ennek ellenére a felhasználó nem éri el a fájlszervert (10.66.4.5)
A tűzfal logban nem látszik, hogy a tun0 csatolón megjelenne eldobott forgalom.
Íme a szerver routing táblája:
# ip -4 route show
default via 10.66.4.254 dev eth0
10.8.5.0/24 via 10.8.5.2 dev tun0
10.8.5.2 dev tun0 proto kernel scope link src 10.8.5.1
10.8.55.0/24 via 10.8.5.2 dev tun0
10.66.4.0/24 dev eth0 proto kernel scope link src 10.66.4.3
Vajon mit szúrtam el vagy néztem be?
Minden ötletet szívesen fogadok.
Köszi:
Szerk.:
A hálózatban lévő eszközök:
10.66.4.254 - Router
10.66.4.3 - VPN szerver - Virtuális alháló: 10.8.5.0/24 és 10.8.55.0/24
10.66.4.5 - Fájlszerver
Az eredeti leírás, ami alapján az egészet elkezdtem/összeraktam.
- 618 megtekintés
Hozzászólások
És a cél szerver is tudja, hogy ez az új tartomány merre van?
Ha nem, akkor csak úgy fog menni, ha a VPN szerver a default GW-je. - (vagy felveszel rajta egy static route bejegyzést)
(vagy MASQ-olod, ahogy a működő tartománmyt is...)
Esetleg a szerveren lokális tűzfal?
- A hozzászóláshoz be kell jelentkezni
Nem kell beállítani a célszerveren default route-nak a VPN szervert. Két opció is van:
1, A cél szerveren fel kell venni a felhasználóknak kiosztott tartományhoz route-ként a VPN szerver IP címét
2, A hálózati routeren is meg lehet csinálni ugyanezt. Véleményem szerint ez lenne célszerűbb, hiszen így később ha mást is el kell érniük, akkor nem kell minden szerveren egyesével külön managelni a route-okat.
- A hozzászóláshoz be kell jelentkezni
(vagy MASQ-olod, ahogy a működő tartománmyt is...)
Ez volt a megoldás!
ipv4 -t nat -A POSTROUTING -s 10.8.55.0/24 -d 10.66.4.5 -o eth0 -j MASQUERADEKöszönöm
- A hozzászóláshoz be kell jelentkezni
Ezzel annyi bajod lesz, hogy nem fogod tudni felhasználóhoz kötni a kapcsolatokat, mert minden VPN felhasználó tevékenysége a VPN szerver IP címével fog látszani a Samba (és összes többi) szerveren...
Sokkal jobb megoldás lenne az előbb javasolt módszer, hogy a hálózat router-én fel kellene venni egy statikus útvonalat, hogy a VPN kliens tartományok átjárója a VPN szerver címe, és akkor megoldódik az elérés is, és a VPN kliensek kapcsolatainak azonosíthatósága is.
- A hozzászóláshoz be kell jelentkezni
Ezzel annyi bajod lesz, hogy nem fogod tudni felhasználóhoz kötni a kapcsolatokat, mert minden VPN felhasználó tevékenysége a VPN szerver IP címével fog látszani a Samba (és összes többi) szerveren...
Köszi, ez nem elhanyagolandó tényező.
Sokkal jobb megoldás lenne az előbb javasolt módszer, hogy a hálózat router-én fel kellene venni egy statikus útvonalat, hogy a VPN kliens tartományok átjárója a VPN szerver címe,
Tudsz adni valami támpontot, hogy miként is kellene ezt?
- A hozzászóláshoz be kell jelentkezni
Mi a központi router, a default gateway a hálózatban? Annak ismeretében lehet tanácsot adni statikus útvonal felvételének mikéntjére.
- A hozzászóláshoz be kell jelentkezni
Mikrotik hEX S
- A hozzászóláshoz be kell jelentkezni
Hát ez egyszerű:
/ip route add comment="OpenVPN egyik subnet" distance=1 dst-address=10.8.5.0/24 gateway=10.66.4.3
/ip route add comment="OpenVPN másik subnet" distance=1 dst-address=10.8.55.0/24 gateway=10.66.4.3Ezzel eléred, hogy a 10.66.4.0/24 hálózatban aki a 10.8.5.0/24 és 10.8.55.0/24 címeket próbálja elérni, az a default gw-n keresztül simán eléri az egyes gépek route táblájának módosítása nélkül.
- A hozzászóláshoz be kell jelentkezni
Kipróbáltam. Nem működik.
Szerintem alapvetően azért, mert routeren nem jelenik meg 10.8.55.0/24 tartományból érkező forgalom.
Csakhogy tiszta legyen (számomra is).
A routeren NAT került beállításra, ami szerint a 1194-es porton érkező kéréseket a 10.66.4.3 címre irányítja. A VPN kliens így közvetlenül kapcsolódik a VPN szerverhez a tun0 csatolón keresztül és ott kap egy (a VPN szerver által generált) virtuális IP címet a 10.8.55.0/24 tartományból. Evvel annyit értünk el, hogy a kliens látja a szervert. Ahhoz, hogy a VPN szerverhez kapcsolódva a kliens hozzáférjen a belső hálózathoz, a szerveren futó tűzfalon kell kiengednünk a tun0 csatolón keresztül.
Ezért gondolom a VPN szerveren kell megfelelő tűzfal szabályokat beállítani.
- A hozzászóláshoz be kell jelentkezni
Ha jól értem, akkor a router mögött van egy, a hálózat tekintetében kutya közönséges gép és ez terminálja a VPN forgalmat. Ezen a ponton a VPN kliens a fogadó gépet látja - az óhaj viszont az lenne, hogy lásson mindent is, amit a fogadó gép lát.
Ha ez valóban alapban egy szimpla mezei host, akkor default nincs bekapcsolva a forwarding. Egy cat /proc/sys/net/ipv4/ip_forward informatív a témában, ha a kimenet 0, akkor nincs bekapcsolva.
Át kel gondolni a csomagok útvonalát is. Az "oda" iránnyal nem lesz gond, mert a kliens --> fogadó --> célgép irány működni fog. A probléma az, hogy a célgép --> VPN kliens irány esetén mivel a célgépnek tippje nincs, merre keresse a VPN klienst, a választ a default gw.-nek küldi el, aki viszont ezzel szintén nem fog tudni mit csinálni. Tehát a megoldási lehetőségek:
- a legrondább, de minimális erőfeszítést igénylő megoldás, hogy a VPN fogadó gépen állítasz egy NAT szabályt, olyasmit, hogy iptables -t nat -A POSTROUTING -i tun0 -o eth0 -j MASQUERADE - ebben az esetben minden, a tunelből jövő forgalom úgy megy tovább a hálón, mintha a VPN szervertől jönne a csomag. Ekkor a célgép nem a VPN kliens felé akarja a csomagot visszaküldeni, hanem a VPN fogadó felé, aki viszont ismert subnetben van. Ennek a megoldásnak viszont hátránya, (ahogy azt már írták mások is), hogy a VPN mögötti összes kliens forgalma minden célgépen úgy jelenik meg, mintha a VPN fogadó akart volna kommunikálni.
- az elegáns megoldás, hogy minden érintett géppel tudatod, hogy a VPN klienesek által használatos subnet merre érhető el. Mivel több célsubnet is van, ezért ez jó eséllyel a routeren is igényel beállítást, hogy a másik subnetből a VPN felé tartó forgalom a VPN server felé küldendő tovább. Ez ugyan korrekt megoldás, viszont nem egyszerű.
- átgondolod a helyzetet és a VPN fogadót a routerre teszed. Ekkor mindenhol mindenkinek minden route irány jó lesz - viszont ennek ára, hogy a VPN fogadót át kell helyezned. Itt gyanítom egyéb okok fognak a háttérben állni, amiért ez esetleg nem/nehezen oldható meg.
- A hozzászóláshoz be kell jelentkezni
Ha jól értem, akkor a router mögött van egy, a hálózat tekintetében kutya közönséges gép és ez terminálja a VPN forgalmat.
Jól érted.
az óhaj viszont az lenne, hogy lásson mindent is, amit a fogadó gép lát.
Ez megoldott és működik.
Az óhaj az lenne, hogy a VPN szerver által létrehozott alhálóból (10.8.55.0) IP címet kapó kliensek számára csak és kizárólag egyetlen célgép legyen a belső hálózaton.
Ehhez elsődlegesen a VPN fogadó gépen kell egy tűzfal szabály, ami kiengedi a tunelből a forgalmat a megadott irányba. A leírás szerint ezt az alábbi szabállal érhetem el:
iptables -A FORWARD -i tun0 -s 10.8.55.0/24 -d 10.66.4.5 -j ACCEPTÁm hiába, esetünkben a 10.8.55.1 IP címmel rendelkező kliens egyáltalán nem lát semmit a belső hálóból.
Az alábbi nat szabály lehetővé teszi, hogy a kliens csak a célszervert érje el és az ott engedélyezett műveleteket elvégezze.
ipv4 -t nat -A POSTROUTING -s 10.8.55.0/24 -d 10.66.4.5 -o eth0 -j MASQUERADEAz eredeti problémám itt meg is oldódott, ám erre volt az a jogos felvetés, hogy
VPN mögötti összes kliens forgalma minden célgépen úgy jelenik meg, mintha a VPN fogadó akart volna kommunikálni.
Nyilvánvaló van az a helyzet, amikor ennek nincs jelentősége. Ám amikor szeretném tudni, hogy pontosan melyik kliens kotorászott a célgépen, akkor azt miként lehet megoldani?
Úgy gondolom, hogy elsődlegesen a VPN szerveren futó tűzfalon kell megfelelően kiengedni a subnet forgalmat és másodlagosan kell a hálózati beállításokkal foglalkozni.
- A hozzászóláshoz be kell jelentkezni
Ahhoz, hogy a VPN fogadón ne kelljen maszkolni a kimenő forgalmat és a VPN kliensei mégis tudjanak kapcsolódni a belső hálózat bármely gépéhez, ahhoz szükséges az, hogy tudják: merre érhető el az a gép, amely a VPN-en keresztül forgalmaz.
Más szavakkal: egy kapcsolat akkor lesz működő képes, ha nem csak az A host tudja, hogy merre kell küldeni a csomagot, ha a B hostot el akarja érni, hanem a B hostnak is tudnia kell, hogy merre kell küldenie a (válasz)csomagot ahhoz, hogy az az A host felé induljon. Amikor te kialakítasz egy VPN fogadót és a működéséhez létre hozol egy új subnetet, akkor megváltoztatod az eredeti hálózat topológiáját! Innen kezdve megjelenik egy új router, amelyen keresztül a VPN subnet(és így a VPN-ben lévő gépek) elérhetőek lesznek. De ha a hálózat nem rendelkezik azzal az infóval, hogy van egy új router, amelyen egy új subnet elérhető, akkor az oda szánt csomagokat rossz irányba, a default gw felé fogja route-olni. Na most ezen a ponton minimum, hogy a hálózati routeren be kell állítani, hogy a VPN szerveren keresztül elérhető a VPN subnet.
... no, milyen jó, hogy visszaolvastam a te hozzászólásodat is meg az enyémet is. Mert amit ugyan leírtam, az igaz - de általánosan, neked meg egyetlen host kell csak. Ezen a ponton amit írtam, az igaz - viszont ebben a speciális esetben van más megoldás is, ami neked jó lehet... :-)
Szóval: a VPN szerverre húzz fel két IP címet is a helyi hálózatból, a nat tábla POSTROUTING láncán viszont ne MASQUERADE targetet használj, hanem SNAT --to-source $MASIKIP ahol a MASIKIP a VPN szerverre felhúzott másik IP cím. Ekkor minden VPN forgalom a belső hálón valós IP-vel jelenik meg, de már nem a VPN fogadó IP-je lesz, hanem az extra IP a hálózatból.
Nna, itt meg tartok tőle, túlságosan leegyszerűsítettem a feladatot: ez akkor jó, ha a VPN-ből csak egy kliens jön. De az viszont továbbra is igaz, hogy egyetlen gép elérése a cél. Az megoldható, hogy a cél gépen egy extra route-ot felvegyél? Tehát a 10.66.4.5 gépen mondj valami olyasmit, hogy route add -net 10.8.55.0 netmask 255.255.255.0 gw $VPNSERVER_HELYI_IP - ekkor a 10.66.4.5 tudni fogja, hog ya VPN-beli IP címeket a VPN fogadó felé kell visszaküldeni.
No igen. Viszont ha a 10.66.4.5 nem abban a subnetben van,ahol a VPN szerver, akkor ez nem fog menni - akkor ő mindenkép a számára def.gw router felé fogj a válasz csomagot indítani és ekkor a routeren kell ezt a sort felvenni, hogy a router küldje el jó helyre a csomagot. De ebben az esetben nem csak a 10.66.4.5 válasza fog jó irányba menni, hanem az adott subnet összes gépének forgalma. Hogy ez probléma-e, azt te tudod - ha igen, akkor a megfelelő iptables szabállyla a többiek elérése tiltható.
- A hozzászóláshoz be kell jelentkezni