Sziasztok, van egy gondom, amiről még azt se tudom, hogy meg lehet-e oldani?
Adott két telephely, melyek között openvpn routolt hálózat tartja a kapcsolatot
debian linuxokon futva.
A szerver openvpn linuxon van fix-ip adsl WAN kapcsolat.
Nos a WAN felől kellene tudnom egy vnc kapcsolatot csinálni a kliens openvpn
hálózatban levő win32 munkaállomásra, de nem megy.
A kapcsolat a vpn két subnetje között megy rendesen, az egyik subnetből a másikba minden gond nélkül oda-vissza.
A kliens openvpn linuxon be van rakva a port forward a kliens win32 ip címére, szintén
a szerver openvpn linuxon is van port-fw a kliens linux ovpn címére, de mégsem megy.
a szerver subnet: 192.168.1.0/24
a kliens subnet: 192.168.101.0/24
ovpn subnet: 10.8.0.0/24 (tun0)
a kliensgép (win32), amin a vnc szerver fut: 192.168.101.20
ez van az ovpn kliens linuxon:
iptables -t nat -A POSTROUTING -p tcp -s 192.168.101.20/32 -j MASQUERADE
iptables -t nat -A PREROUTING -i tun0 -p tcp --dport 5900 -j DNAT --to 192.168.101.20:5900
ez pedig az ovpn szerver linuxon:
iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 5900 -j DNAT --to 10.8.0.22:5900
Mi lehet szerintetek a gond?
(a visszafelé menő csomagok útja bizonytalan, de hogy adjam meg?)
Sokat keresgéltem a googlén, találtam is sok helyet, de sehol sem tudták megválaszolni a dolgot. Linkelek egy címet, ahol ugyanez a gond:
http://forums.opensuse.org/network-internet/389105-port-forwarding-open…
Nagyon szépen köszönöm előre is, hogy foglalkoztok velem!
- 3208 megtekintés
Hozzászólások
Nagyon régen csináltam már ilyet, úgyhogy előre is bocsánatot kérek, ha butaságot írnék.
Ha jól emlékszem: ha az openvpn-t helyesen beállítottad (és egyéb tiltásokat nem léptettél életbe, akár explicite, akár default policy-vel), akkor a szerver subnet (192.168.1.0/24) bármely gépe látja a kliens subnet (192.168.101.0/24) bármely gépét; és viszont.
Ennek alapján én az ovpn kliens linuxra egyáltalán nem tennék a fenti problémával kapcsolatos iptables szabályt.
Az ovpn szerverre (amely a publikus IP-vel is rendelkezik) pedig valóban egy DNAT szabályt tennék, de
--to-nak nem az ovpn kliens címét adnám meg (= az ovpn kliensen a tun0-hoz rendelt IP címet, a 10.8.0.22-t), hanem a win32 kliens címét (192.168.101.20). Mivel ez egy PREROUTING szabály, azért a destaddr átírása után ez a csomag a "megszokott vpn-es módon" fog irányítódni, mintha csak az ovpn szerverről akarnád elérni a win32 klienst; ennek pedig a jól belőtt openvpn miatt amúgy is működnie kell.
Szerkesztés (az opensuse fórumra mutató linket megnézve): valóban, a DNAT önmagában nem elég, szükség van MASQUERADE-re is.
Másik lehetőség, hogy egyáltalán nem használsz iptables-t, hanem felteszel az ovpn szerverre egy TCP szintű port forwardert, amely (szintén a jól belőtt openvpn miatt) közvetlenül eléri a win32 kliensen a vnc szerverportot. A saját port forwarder-emet például így paraméterezném (persze nem root-ként futtatnám):
forward3 -l 5900 -r 5900 -f 192.168.101.20 -D ~/vnc.logTCP szintű port forwardert használva megoldódik az a probléma is, amely miatt fent a DNAT mellett a MASQUERADE is kell.
Vagyis összefoglalva:
1. Az ovpn kliensre nem teszel szabályt, az ovpn szerverre pedig két szabályt teszel:
iptables -t nat -A PREROUTING -i ppp0 -d PUBLIC_IP -p tcp --dport 5900 -j DNAT --to-destination 192.168.101.20:5900
iptables -t nat -A POSTROUTING -s ! 192.168.1.0/24 -d 192.168.101.20 -p tcp --dport 5900 -j MASQUERADE
Az első szabály a routing előtt becélozza a kliens subnet megfelelő (win32) gépét, a második szabály pedig az útválasztás után megváltoztatja a forrás címet, hogy a win32 gépről visszafelé jövő csomagok visszataláljanak majd az ovpn szerverhez, ill. onnan a kinti vnc klienshez.
2. Vagy TCP szintű port forwardert teszel az ovpn szerverre.
- A hozzászóláshoz be kell jelentkezni
Szia Lacos
Nagyon köszönöm a választ, először én is így próbáltam, de kihagytam a
MASQUERADE szabályt.
Holnap első dolgom lesz kipróbálni :))
Mégegyszer köszi !!!
- A hozzászóláshoz be kell jelentkezni
félmegoldás nem az eredeti kiírásra:
3. openvpn klienst a win32 állomáson futtatod, a gateway-en a használt openvpn portot továbbítod ide
- A hozzászóláshoz be kell jelentkezni
Szerintem nem a tűzfallal van gondod. Nézd meg ezt a doksit:
http://openvpn.net/index.php/documentation/howto.html#scope
Ezen belül ha jól értem ez a rész kell neked:
Including multiple machines on the client side when using a routed VPN (dev tun)
Egy a lényeg, hogy ne legyen ugyanaz a szubnet a két oldalon.
--
http://csuhai.hu
- A hozzászóláshoz be kell jelentkezni
Úgy gondolom, hogy a kliens és a szerver (kér iroda gépei) oldalon a TCP/IP alapú kummunikációnak oda-vissza kell működni, mind "tunneling" és mind "ethernet bridging" módszerrel.
Hogy a kliensek lássák egymást kell az "clien-to-client" opció a szerver konfigurációban.
Többször kértem én is segítséget itt a HUP-on:
http://hup.hu/node/57256
http://hup.hu/node/67124
Vannk benne linkek. Lassan megoldottam az ottani problémákat. Talán segítenek az ott leírtak, bár nálam ethernet bridging van: A teljes OPENVPN-bridging + router + gateway + firewall szerver kialakításához 3 láb azaz 3 hálókártya kellett:
1. eth0 WAN - itt véd a tűzfal csak 1-2 portot enged be.
2. eth1 LAN (belsőháló) ez a gateway cím a WAN felé
3. bridging on eth2 (belső hálózatban)
Attila, Perger
-----------------------------------------------------
"Az a szoftver, amelyiket nem fejlesztik, az halott!"
- A hozzászóláshoz be kell jelentkezni
Köszi mindenkinek a segítséget.
A LACOS által javasolt 1. módszer változtatás nélkül működik!!!
A két hálózat közötti kapcsolattal nem volt gond, még samba is van úgy, hogy a browsing is tökéletesen megy a két telephely között.
A gond a wan felől port forwarding volt, a LACOS által írt:
"iptables -t nat -A POSTROUTING -s ! 192.168.1.0/24 -d 192.168.101.20 -p tcp --dport 5900 -j MASQUERADE"
szabály megoldotta a problémát!
!!! SOLVED !!!
KÖSZI MINDENKINEK!!! KÜLÖNÖSEN NEKED LACOS!
Érdemes a hup-on kérdést feltenni, mert eléggé gyorsan megoldódott :)
- A hozzászóláshoz be kell jelentkezni