OpenVPN-kliënt bereik die bediener, maar nie die LAN-gashere nie: kontrolelys

Die kliënt sê verbind, die tonneladres antwoord op ’n ping, en niks op die kantoor-LAN reageer nie. Ek sien dit ná byna elke kliëntopgradering, en die eerste instink is om die firewall oop te maak, wat gewoonlik die verkeerde stap is: die tonnel is reg, en die breuk is een van drie spronge wat die pakket moet kruis. Stap die pad in die volgorde waarin die pakket dit neem, eers die kliëntroete, dan die bediener se aanstuur, dan die terugreis, en jy sal die eienaar van die fout binne ’n paar minute vind.

Stap een: kyk na die kliënt se roetebesluit

Voordat jy aan die bediener raak, bewys dat die kliënt die pakket in die tonnel instuur. Vra die kernel watter koppelvlak dit vir een spesifieke LAN-gasheer sou gebruik, eerder as om die hele tabel te lees:

ip route get 192.168.50.10

As die antwoord jou fisiese adapter en die kantoorpoort noem, kan geen verandering aan die bedienerkant help nie. OpenVPN deel net roetes uit wanneer die bediener dit stoot, so soek push "route 192.168.50.0 255.255.255.0" in die bedienerkonfigurasie en verbind die kliënt daarna weer. Die meeste kliënte pas gestootde roetes toe wanneer hulle verbind, nie wanneer jy die profiel herlaai nie.

Op Windows het dieselfde vraag ’n ander opdrag. Find-NetRoute -RemoteIPAddress 192.168.50.10 druk die koppelvlak en volgende sprong wat die stapel sou kies, en route print -4 wys of die gestootde voorvoegsel hoegenaamd bestaan.

Stap twee: bevestig dat die bediener die pakket sal aanstuur

As die kliëntroete reg is, bereik die pakket die bediener, en die bediener moet instem om dit aan te stuur. Die kernskakelaar is die eerste hek, en sysctl net.ipv4.ip_forward moet 1 teruggee. Om dit met echo 1 > /proc/sys/net/ipv4/ip_forward te stel, werk tot die volgende herbegin, en dit is juis waarom dieselfde klag weke later terugkom.

Skryf dit neer op ’n plek wat ’n herbegin oorleef:

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

Die tweede hek is die filtertabel. ’n Gasheer met Docker geïnstalleer dra dikwels ’n FORWARD-beleid van DROP, en die tonnel erf daardie besluit. iptables -L FORWARD -v -n wys beide die beleid en die pakkietellers; as die beleid DROP is, het aanstuur ’n eksplisiete aanvaarding nodig vir die tonnel-na-LAN-rigting en een vir die antwoord.

Stap drie: volg die pakket tot op die LAN en soek die antwoord

Hou albei kante van die bediener gelyktydig dop. Vang op die tonnel en op die LAN-koppelvlak, gefiltreer na een kliënt en een gasheer sodat die uitset leesbaar bly:

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

Versoeke wat op tun0 en weer op eth0 verskyn met ’n bron van 10.8.0.x, gevolg deur stilte, beteken die pakket het aangekom en die antwoord het elders heen gegaan. Die LAN-gasheer antwoord sy verstekpoort, daardie poort het geen roete vir die VPN-poel nie, en die antwoord sterf op die LAN-roeteerder. Om die LAN-gasheer vanaf die bediener te ping, bewys niks oor hierdie pad nie, want daardie verkeer kruis nooit die tonnel nie.

Stap vier: kies tussen vertaling en ’n terugroete

Twee herstellings sluit die gat, en die keuse het gevolge buite of ping werk. Bronvertaling maak die bediener die skynbare sender:

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

Beperk die reël tot die poel en die LAN-koppelvlak, en maak dit dan blywend, of die volgende firewall-herlaai verwyder jou regstelling stilweg. Die koste is identiteit: elke kliënt lyk soos die VPN-bediener in LAN-logs en toegangsreëls, en per-client policy becomes guesswork.

’n Statiese roete vir 10.8.0.0/24 op die LAN-roeteerder, wat na die VPN-bediener wys, hou kliëntadresse sigbaar en is die beter langtermynantwoord wanneer daardie roeteerder joune is. Baie terreine hardloop ’n ruk lank albei, NAT vir die onmiddellike herstel en die roete sodra firewallbeleid geskryf is. As die bediener ’n werf-tot-werf-eweknie eerder as ’n poel is, het die bedienerkant ook ’n iroute vir die afgeleë subnet nodig, anders bestaan die eweknie-roete maar kliëntverkeer word nooit daarmee geassosieer nie.

Stap vyf: verifieer vanaf die kliënt en teken op wat verander het

Sluit die lus vanaf die kliënt, nie die bediener nie. Verbind aan ’n werklike diens op die LAN-gasheer, bevestig dan dat die vertalingtellers beweeg het met iptables -t nat -L POSTROUTING -v -n, want ’n reël met nul pakkette is ’n reël wat nooit gepas het nie. conntrack -L -s 10.8.0.5 wys die vloei en sy toestand wanneer jy bewys nodig het dat die terugrigting nagespoor word.

Los ’n nota in die bedienerkonfigurasie: watter subnet, watter koppelvlak, watter reël, en of die LAN-roeteerder ’n roete terug dra. Die volgende keer wanneer ’n kliëntopgradering ’n gestootde roete uitvee, maak daardie nota ’n brandbestrydingsessie ’n eenreël-regstelling.