VPN-klanten berikke de server, mar net it LAN: hokker oplossing?

De klient pingt it tunneladres fan de OpenVPN-server en krijt antwurd, prebearret dan in host op it LAN fan de server en krijt neat. Dy splitsing ferneatet de flater danich: de tunnel is omheech, trochstjoeren wurket wierskynlik, en it antwurd giet fuort troch in doar dy't net werom liedt. Der binne trije oplossingen, en de juste ien hinget derfan ôf wat jo beheare en wat jo opjaan wolle. Beantwirdzje de trije fragen hjirûnder yn folchoarder, dan is de kar gjin kwestje fan smaak mear.

Earst fêststelle hokker rjochting stikken is

It fersyk komt binnen op de tunnelinterface mei in boarneadres út de VPN-pool. De server stjoert it troch nei de LAN-host, en dy host antwirdet oan hokker gateway syn eigen tabel ek neamt, meastentiids de LAN-router. Hat de router gjin rûte foar de pool, dan stjert it antwurd dêre of doalt it rjochting it internet.

Test beide masines foardat jo ien fan beide oanpasse. Freegje op de server oan de routingstabel hoe't dy in klient berikke soe; freegje op de LAN-host hoe't dy itselde adres berikke soe. De earste lookup wiist meastentiids nei de tunnel en de twadde nei de LAN-router, en dat ferskil is de flater yn ien rigel. Twa lookups binne goedkeaper as in firewall-audit en se bepale de rjochting fan it probleem.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

Wisset de LAN-host al nei de VPN-server, dan is jo probleem in firewallregel of in MTU-limyt en gjin ûntbrekkende weromrûte. Foegje gjin rûte ta om in filter te reparearjen.

Fraach ien: kinne jo de router fan it fiere LAN oanpasse?

As de LAN-router fan jo is, dan is in statyske rûte foar de VPN-pool mei it LAN-adres fan de VPN-server as folgjende hop it skjinne antwurd. Dy hâldt boarneadressen fan klanten yntakt, wat telt as LAN-hosts op adres logge, filterje of snelheidslimiten oplizze. Hy freget ek gjin oersetting op de server, sadat de tunnel in suver routingpaad bliuwt. De ferplichting dy't er skept is dokumintaasje, want pool, rûte en serverkonfiguraasje moatte oerienkomme.

Hy falt stil op de dei dat immen de pool feroaret. Skriuw de wearde ien kear op en behannelje in wiziging op ien fan de trije plakken as in wiziging oan alle trije.

In NAS of in Layer 3-switch dy't de tsjinst hostet, hat deselde rûte nedich, útsein as er alles troch in router stjoert dy't ien hat. Kontrolearje it apparaat dat it subnet terminearet, net allinnich dat oan de internetkant. Lytse netwurken hawwe faak trije apparaten mei in miening oer routing.

Fraach twa: mei it LAN ophâlde mei it sjen fan klientadressen?

As de router fan immen oars is, freget oersetting op de VPN-server gjin gearwurking. De LAN-host sjocht it LAN-adres fan de server, antwirdet dêrop, en de server set werom oer. Dêrom gedrage apparaten en NAT-basearre remote-access-rollen har sa.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

De priis is taskriuwung: adressen per klient ferdwine út de LAN-logs. Elke allowlist op de LAN-host moat dan de server neame ynstee fan de pool.

Kies oersetting as gearwurking net beskikber is, net as it gewoan ûnhandich is. It ferstoppet de klient foar elk takomstich ûndersyk, ek foar dy wêr't jo witte moatte hokker laptop in ferbining iepene. It kin ek protokollen brekke dy't adressen yn payloads ynbêdzje, want de oersetting sit yn de kop. Gjin fan beide opsjes is avansearre; se beantwirdzje ferskate fragen oer eigendom.

Fraach trije: is de server sels in klient fan in oare tunnel?

Stel jo de oare topology foar: de VPN-server skillet ek in kommersjele provider yn, dus hy hat twa tunnels en twa sets adressen. Ferkearen dat er foar syn eigen klanten trochstjoert, giet fuort troch de provider, en dy sil antwurden net werom nei pooladressen routearje. Dêrom ferdwine antwurden, ek al binne beide tunnels sûn.

De oplossing is ek de útgongstunnel te masqueraden, sadat de provider allinnich it tunneladres fan de server sjocht. De tsjinoerstelde rjochting hat syn eigen regel nedich, want de server dy't in ferbining nei ien fan syn eigen klanten begjint, is in oare flow. Sûnder dy regel antwirdet de klient oan in adres dat er net routearje kin. Set de smelle regel foar elke brede masquerade, sadat de spesifike oersetting wint.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

Multihomed hosts foegje in besibbe flater ta dy't fan de klient út identyk liket. It antwurd giet fuort troch de interface mei de legere metryk, om't it boarneadres út in oare tabel keazen is. Kontrolearje it werompaad mei in lookup ynstee fan oan te nimmen dat it hinnewei it ymplisearret.

Ferifiearje dan beide rjochtingen en beide grutten

Ping nei de wiziging fan de klient nei in LAN-host, dan fan de LAN-host nei de klient. De twadde rjochting is dy't minsken oerslaan, en it is dy't in ûnfolsleine oersettingsregel bleatleit. Registrearje beide resultaten mei tiidstimpels, sadat in lettere regression ferlykber is.

Ferpleats dan echte data, want in lytse ping dy't slagget wylst in grutte oerdracht stûket, is in MTU-symptoom. Dy flater ferskynt krekt nei't jo josels lokwinske hawwe mei it reparearjen fan de rûte.

Test úteinlik opnij nei in werstart. Runtime-rûte- en firewall-opdrachten oerlibje dy net, en in oplossing dy't by de folgjende start ferdwynt, wurdt wer diagnostisearre troch immen mei minder kontekst. Meitsje de wiziging permanint op de manier dy't jo systeem al brûkt, en werstart dan ien kear mei opset sin.