Sziasztok,
Érdekes hibába futottam bele teszt környezetben, hátha van valakinek ötlete.
A cél pofon egyszerű lenne, a router mögötti Debian 8-on futó OpenVPN szerverre a kliensek becsatlakozva szépen látják a belső LAN-t, a net felé pedig a saját GW-t használják.
OpenVPN szerver
-1db fizikai ethernet
-TUN mód (topology subnet)
-UDP és TCP külön subnettel
-"server" mód, a DHCP a VPN szerver
-push route kiküldi a LAN adatait.
-a kliensek megkapják továbbá a LAN-on dolgozó DNS-t is.
-a VPN tűzfalán a fizikai csatoló és a tun eszközök között nincs korlátozás.
EdgeRouter (csak részlegesen férek/értek hozzá)
-kértem 2db port forward-ot a VPN szerver felé
-kértem két static route-ot rá, a két VPN subnet átjárója legyen a VPN szerver.
-elvileg default a konfiguráció, a két fenti szabályt tudtommal GUI-ról készült.
Amiket tapasztalok:
A VPN kliens szépen be tud csatlakozni a belső hálózatba, de csak ICMP forgalmazás működik. Internet felé szépen megy a forgalom.
RDP-n egy belső géphez csatlakozva "AN internal error has occured" üzenetet kapok annak ellenére, hogy
telnet 3389-re nem jön hiba.
A VPN szerveren tcpdump-al figyelve a hálózati csatolót látszólag jól működik, és mégsem.
Ha maszkolom a VPN szerveren a két VPN subnetet a fizikai csatolón kifelé, akkor minden hibátlanul megy.
Az itt leírt probléma kísértetiesen hasonlít az enyémre:
https://community.ubnt.com/t5/EdgeMAX/OpenVPN-server-behind-edgerouter/…
Van valakinek tippje hogy hol lehet a hiba?
Minden ötlet, tipp jól jön.
Köszönöm.
udv
letix
- 1643 megtekintés
Hozzászólások
Ami kimaradt:
Természetesen nem csak az RDP nem megy, hanem egy egyszerű megosztás megnyitás sem. Csak ICMP.
A LAN kliensről szépen pingelhető a VPN kliens, amikor be van csatlakozva, illetve a VPN szerver két belső lába is. Tehát az EdgeRouter statikus route jól megy.
Köszönöm.
-----------------------------------------
Linux parancsok, kezdőknek
- A hozzászóláshoz be kell jelentkezni
MTU?
- A hozzászóláshoz be kell jelentkezni
Köszi a válaszod.
Igen ez jutott még eszembe, holnap kipróbálom, hátha.A VPN oldalon biztos hogy default értéken van és szuerintem az Edge oldalán is.
Érdekes, hogy ugyanezen VPN konfiggal és az EdgeRouter helyett egy szimpla Debian + iptables párossal szépen működik.
udv
letix
-----------------------------------------
Linux parancsok, kezdőknek
- A hozzászóláshoz be kell jelentkezni
Ha jól veszem ki, a VPN szerver ugyanazon a LAN-on kommunikál a router-el, mint az összes többi gép.
A gépek def. gw-e az EdgeRouter, így a VPN felé menő csomagok oda mennek, majd onnan static route alapján a VPN szerverre, onnan a VPN klienshez. Befelé viszont a VPN szerver direktben küldi a belső gépnek a csomagot, hiszen ugyanazon a subneten csücsül.
Valószínűleg az Edge router az, ami nem tud mit kezdeni az established csomagokkal, miután a syn nem ment ár rajta.
(Ha a szerver-router és a LAN-router vonal két külön subnet, akkor passz)
----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
- A hozzászóláshoz be kell jelentkezni
hmm, az MTU módosítással egyelőre nincs siker.
junior013:
Igen, jól értelmezed a felállást, mind a szerver, mint a GW mind pedig a VPN egyetlen lába egy azon subneten van.
Ha kapna mégy egy belső hálózati csatolót, és azon tolnám ki a LAN felé a VPN forgalmat (maszkolás nélkül) az már jobb lehetne?
Köszi,
letix
update:
Az Edge eszközön ha figyelem a VPN kliens forgalmát, ez jön:
X.X.100.250 RDP server
X.X.98.2 VPN kliens
X.X.100.5 GW.
10:45:51.905448 IP X.X.100.250.3389 > X.X.98.2.2761: Flags [S.], seq 2387021982, ack 3538723781, win 64000, options [mss 1460,nop,wscale 0,nop,nop,sackOK], length 0
10:45:51.905625 IP X.X.100.250.3389 > X.X.98.2.2761: Flags [S.], seq 2387021982, ack 3538723781, win 64000, options [mss 1460,nop,wscale 0,nop,nop,sackOK], length 0
10:45:51.972259 IP X.X.100.250.3389 > X.X.98.2.2761: Flags [P.], seq 1:20, ack 20, win 63981, length 19
10:45:51.972532 IP X.X.100.5.3389 > X.X.98.2.2761: Flags [P.], seq 2387021983:2387022002, ack 3538723800, win 63981, length 19
-----------------------------------------
Linux parancsok, kezdőknek
- A hozzászóláshoz be kell jelentkezni
Másik csatoló nem feltétlen kell, de az egyszerű megoldás az lenne, ha a jelenlegi LAN subnet számára a VPN server lenne a def. gw és az továbbítana (akár ugyanazon a fizikai LAN-on) másik IP subnet-en mindent az Edge router felé (masq. természetesen nem kell, csak static route-ok az Edge routeren)
----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
- A hozzászóláshoz be kell jelentkezni
Nos, valószínűleg az Edge eszközzel lesz gond, méghozzá a static route-okkal.
Látszólag megy velük a dolog, de mégsem.
Ha kiveszem a route-okat a routerről és kézzel felveszem az egyik LAN kliensre, úgy szépen megy minden, ahogy kell.
Ez is előrelépés..
-----------------------------------------
Linux parancsok, kezdőknek
- A hozzászóláshoz be kell jelentkezni
Ez logikus, hiszen a LAN kliens egyből jó gw-nek küldi a VPN felé szánt csomagokat. Kb. ugyanazt kapod, mintha a VPN server lenne a def. gw-d, csak hát baromi macerás minden kliensre beállítgatni static route-ot :/
----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
- A hozzászóláshoz be kell jelentkezni
Nos megvan a megoldás.
Amíg a NAT Hairpin be volt kapcsolva az Edge Router-en, addig nem volt hajlandó működni rendesen a VPN maszkolás nélkül.
Kikapcsolva minden szépen működik.
Köszi a hozzászólásokat!
udv
letix
-----------------------------------------
Linux parancsok, kezdőknek
- A hozzászóláshoz be kell jelentkezni
Ez viszont kicsit növeli a rejtélyt, mert a Hairpin elvileg csak arra vonatkozik, ha a router külső IP-jét szólítod meg bentről a router pedig visszaforwardol-ja ugyanarra a belső hálózatra.
Mondjuk, az lehet, hogy a Hairpin miatt a LAN klienstől a VPN felé menő forgalmat az EdgeRouter Masq-olta, mert az is belső IF-ről belső IF-re ment.
----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
- A hozzászóláshoz be kell jelentkezni
Ez a Hairpin NAT számomra újdonság, de kicsit utánaolvasva tényleg a hozzászolásod második felében leírt helyzet állhat fenn.
Korábban egy tűzfalon láttam olyan maszkolási megoldást (SNAT), melyben megmondta a szabály, hogy csak akkor maszkolja a forgalmat kimeneti interfészen, ha a csomag célja nem a belső hálózat, bár jelen esetben ugye ezen forgalmazás kimeneti eszköze nem a WAN irányába menne..
Már ha jól értelmezem ezt a helyzetet.. :)
Köszi!
udv
letix
-----------------------------------------
Linux parancsok, kezdőknek
- A hozzászóláshoz be kell jelentkezni
Mondjuk ezt igy illik megcsinálni. A tűzfal azért tűzfal, hogy mindenfele kósza forgalmak ne maszkaljanak össze-vissza.
- A hozzászóláshoz be kell jelentkezni