OpenVPN-klienten når servern men inte LAN-värdarna: checklista

Klienten säger ansluten, tunneladressen svarar på ping, och ingenting på kontorets LAN svarar. Jag ser detta efter nästan varje klientuppgradering, och den första instinkten är att öppna brandväggen, vilket oftast är fel steg: tunneln är hel, och brottet sitter på ett av tre hopp som paketet måste korsa. Gå vägen i den ordning paketet tar den, först klientens rutt, sedan vidarebefordran på servern, sedan resan tillbaka, och du hittar felets ägare på ett par minuter.

Steg ett: titta på klientens routingbeslut

Innan du rör servern, bevisa att klienten skickar paketet in i tunneln. Fråga kärnan vilket gränssnitt den skulle använda för en viss LAN-värd, i stället för att läsa hela tabellen:

ip route get 192.168.50.10

Om svaret nämner din fysiska adapter och kontorets gateway kan ingen ändring på serversidan hjälpa. OpenVPN delar bara ut rutter när servern skjuter dem, så leta efter push "route 192.168.50.0 255.255.255.0" i serverkonfigurationen och anslut klienten igen efteråt. De flesta klienter tillämpar skjutna rutter vid anslutning, inte när du laddar om profilen.

På Windows har samma fråga ett annat kommando. Find-NetRoute -RemoteIPAddress 192.168.50.10 skriver ut gränssnittet och nästa hopp som stacken skulle välja, och route print -4 visar om det skjutna prefixet ens finns.

Steg två: bekräfta att servern vidarebefordrar paketet

Om klientens rutt är korrekt når paketet servern, och servern måste gå med på att vidarebefordra det. Kärnbrytaren är den första porten, och sysctl net.ipv4.ip_forward måste returnera 1. Att sätta den med echo 1 > /proc/sys/net/ipv4/ip_forward fungerar till nästa omstart, och det är precis därför samma klagomål kommer tillbaka veckor senare.

Skriv ned det någonstans som överlever en omstart:

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

Den andra porten är filtertabellen. En värd med Docker installerat har ofta en FORWARD-policy på DROP, och tunneln ärver det beslutet. iptables -L FORWARD -v -n visar både policyn och paketräknarna; om policyn är DROP behöver vidarebefordran ett uttryckligt tillstånd för riktningen tunnel till LAN och ett för svaret.

Steg tre: följ paketet ut på LAN och leta efter svaret

Håll koll på båda sidor av servern samtidigt. Fånga på tunneln och på LAN-gränssnittet, filtrerat till en klient och en värd så att utdata förblir läsbara:

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

Förfrågningar som dyker upp på tun0 och igen på eth0 med en källa på 10.8.0.x, följt av tystnad, betyder att paketet kom fram och svaret gick någon annanstans. LAN-värden svarar sin standardgateway, den gatewayen har ingen rutt för VPN-poolen, och svaret dör på LAN-routern. Att pinga LAN-värden från servern bevisar ingenting om denna väg, eftersom trafiken aldrig korsar tunneln.

Steg fyra: välj mellan översättning och en returrutt

Två reparationer stänger hålet, och valet har konsekvenser utöver om ping fungerar. Källöversättning gör servern till den skenbara avsändaren:

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

Begränsa regeln till poolen och LAN-gränssnittet och gör den sedan permanent, annars tar nästa brandväggsomladdning tyst bort din fix. Priset är identitet: varje klient ser ut som VPN-servern i LAN-loggar och åtkomstregler, och per-client policy becomes guesswork.

En statisk rutt för 10.8.0.0/24 på LAN-routern, som pekar mot VPN-servern, håller klientadresserna synliga och är det bättre långsiktiga svaret när den routern är din. Många platser kör båda ett tag, NAT för den omedelbara reparationen och rutten när brandväggspolicyn är skriven. Om servern är en site-till-site-peer i stället för en pool behöver serversidan också en iroute för det avlägsna subnätet, annars finns peer-rutten men klienttrafiken kopplas aldrig till den.

Steg fem: verifiera från klienten och notera vad som ändrades

Slut slingan från klienten, inte från servern. Anslut till en riktig tjänst på LAN-värden och bekräfta sedan att översättningsräknarna har flyttats med iptables -t nat -L POSTROUTING -v -n, eftersom en regel utan paket är en regel som aldrig har matchat. conntrack -L -s 10.8.0.5 visar flödet och dess tillstånd när du behöver bevis för att returriktningen spåras.

Lämna en anteckning i serverkonfigurationen: vilket subnät, vilket gränssnitt, vilken regel, och om LAN-routern har en rutt tillbaka. Nästa gång en klientuppgradering rensar en skjuten rutt förvandlar anteckningen en brandsläckningssession till en fix på en rad.