OpenVPN-klient berikt de tsjinner, mar net de LAN-hosts: checklist

De klient seit ferbûn, it tunneladres antwurdet op in ping, en neat op it kantoar-LAN reagearret. Ik sjoch dit nei hast elke klient-upgrade, en it earste ynstinkt is de firewall iepenje, wat meastentiids de ferkearde set is: de tunnel is goed, en de brek is op ien fan trije sprongen dy’t it pakket passearje moat. Rin it paad yn ’e folchoarder dy’t it pakket nimt, earst de klientrûte, dan it trochstjoeren op ’e tsjinner, dan de reis werom, en jo fine de eigner fan ’e flater yn in pear minuten.

Stap ien: sjoch nei de rûtbeslissing fan ’e klient

Foardat jo de tsjinner oanreitsje, bewiisje dat de klient it pakket de tunnel yn stjoert. Freegje de kernel hokker ynterface hy brûke soe foar ien spesifike LAN-host, ynstee fan ’e hiele tabel te lêzen:

ip route get 192.168.50.10

As it antwurd jo fysike adapter en de kantoarpoarte neamt, kin gjin feroaring oan ’e tsjinnerkant helpe. OpenVPN dielt rûtes allinnich as de tsjinner se triuwt, dus sykje push "route 192.168.50.0 255.255.255.0" yn ’e tsjinnerkonfiguraasje, en ferbyn de klient dêrnei opnij. De measte klienten tapasse triuwde rûtes by it ferbinen, net as jo it profyl opnij lade.

Op Windows hat deselde fraach in oar kommando. Find-NetRoute -RemoteIPAddress 192.168.50.10 prints it ynterface en de folgjende sprong dy’t de stack kieze soe, en route print -4 lit sjen oft it triuwde prefix hielendal bestiet.

Stap twa: befêstigje dat de tsjinner it pakket trochstjoert

As de klientrûte goed is, berikt it pakket de tsjinner, en de tsjinner moat ynstimme om it troch te stjoeren. De kernskakelaar is de earste poarte, en sysctl net.ipv4.ip_forward moat 1 weromjaan. It ynstelle mei echo 1 > /proc/sys/net/ipv4/ip_forward wurket oant de folgjende reboot, en dêrom komt deselde klacht wiken letter werom.

Skriuw it earne del dat in reboot oerlibbet:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

De twadde poarte is de filtertabel. In host mei Docker ynstallearre hat faak in FORWARD-belied fan DROP, en de tunnel erft dat beslút. iptables -L FORWARD -v -n lit sawol it belied as de pakkettellers sjen; as it belied DROP is, hat trochstjoeren in eksplisite tastimming nedich foar de rjochting tunnel nei LAN en ien foar it antwurd.

Stap trije: folgje it pakket it LAN op en sykje it antwurd

Hâld beide kanten fan ’e tsjinner tagelyk yn ’e gaten. Fange op ’e tunnel en op ’e LAN-ynterface, filtere op ien klient en ien host, sadat de útfier lêsber bliuwt:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

Fersiken dy’t op tun0 en wer op eth0 ferskine mei in boarne fan 10.8.0.x, folge troch stilte, betsjutte dat it pakket oankaam en it antwurd earne oars hinne gie. De LAN-host antwurdet syn standertpoarte, dy poarte hat gjin rûte foar de VPN-pool, en it antwurd stjert op ’e LAN-rûter. Pingje fan ’e LAN-host fan ’e tsjinner ôf bewiist neat oer dit paad, want dat ferkear giet nea troch de tunnel.

Stap fjouwer: kies tusken oersetting en in weromrûte

Twa reparaasjes slute it gat, en de kar hat gefolgen bûten oft ping wurket. Boarnoersetting makket de tsjinner de skynbere ôfstjoerder:

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

Behein de regel ta de pool en de LAN-ynterface, meitsje it dan permanint, oars sil de folgjende firewall-reload jo fix stil fuortsmite. De priis is identiteit: elke klient liket op ’e VPN-tsjinner yn LAN-logs en tagongsregels, en per-client policy becomes guesswork.

In statyske rûte foar 10.8.0.0/24 op ’e LAN-rûter, nei de VPN-tsjinner ta, hâldt klientadressen sichtber en is it bettere antwurd op ’e lange termyn as dy rûter fan jo is. In protte lokaasjes draaie in skoft beide, NAT foar de direkte reparaasje en de rûte sadree’t it firewallbelied skreaun is. As de tsjinner in side-oant-side partner is ynstee fan in pool, hat de tsjinnerkant ek in iroute nedich foar it ôflizzende subnet, oars bestiet de partnerrûte mar klientferkear wurdt der nea mei ferbûn.

Stap fiif: ferifiearje fan ’e klient en skriuw op wat feroare is

Slút de lus fan ’e klient ôf, net fan ’e tsjinner. Ferbyn mei in echte tsjinst op ’e LAN-host, befêstigje dan dat de oersettingstellers bewege binne mei iptables -t nat -L POSTROUTING -v -n, want in regel mei nul pakketten is in regel dy’t nea oerienkaam. conntrack -L -s 10.8.0.5 lit de stream en syn tastân sjen as jo bewiis nedich hawwe dat de weromrjochting folge wurdt.

Lit in notysje efter yn ’e tsjinnerkonfiguraasje: hokker subnet, hokker ynterface, hokker regel, en oft de LAN-rûter in rûte werom hat. De folgjende kear as in klient-upgrade in triuwde rûte wisket, makket dy notysje fan in brânbestridingssesje in fix fan ien rigel.