VPN-klienter når servern men inte LAN: vilken lösning?

Klienten pingar tunneladressen hos OpenVPN-servern och får svar, försöker sedan nå en värd i serverns LAN och får ingenting. Den uppdelningen begränsar felet avsevärt: tunneln är uppe, vidarebefordran fungerar förmodligen, och svaret lämnar nätverket genom en dörr som inte leder tillbaka. Det finns tre lösningar, och den rätta beror på vad du kontrollerar och vad du är beredd att avstå från. Besvara de tre frågorna nedan i ordning, så är valet inte längre en smaksak.

Bekräfta först vilken riktning som är trasig

Förfrågan kommer in på tunnelgränssnittet med en källadress från VPN-poolen. Servern vidarebefordrar den till LAN-värden, och den värden svarar till den gateway som dess egen tabell pekar ut, vanligen LAN-routern. Har routern ingen rutt till poolen dör svaret där eller vandrar mot internet.

Testa båda maskinerna innan du ändrar någon av dem. Fråga serverns rutttabell hur den skulle nå en klient; fråga LAN-värden hur den skulle nå samma adress. Den första uppslagningen pekar oftast på tunneln och den andra på LAN-routern, och den skillnaden är felet på en rad. Två uppslagningar är billigare än en brandväggsrevision och de avgör problemets riktning.

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

Om LAN-värden redan pekar på VPN-servern är problemet en brandväggsregel eller en MTU-gräns och inte en saknad returväg. Lägg inte till en rutt för att laga ett filter.

Fråga ett: kan du ändra routern i det fjärran LAN:et?

När LAN-routern är din är en statisk rutt för VPN-poolen med VPN-serverns LAN-adress som nästa hopp det rena svaret. Den håller klienternas källadresser intakta, vilket spelar roll när LAN-värdar loggar, filtrerar eller hastighetsbegränsar efter adress. Den kräver inte heller någon översättning på servern, så tunneln förblir en ren routingväg. Den förpliktelse den skapar är dokumentation, eftersom pool, rutt och serverkonfiguration måste stämma överens.

Den faller tyst den dag någon ändrar poolen. Skriv ner värdet en gång och behandla en ändring på någon av de tre platserna som en ändring av alla tre.

En NAS eller en Layer 3-switch som är värd för tjänsten behöver samma rutt, om den inte skickar allt via en router som har en. Kontrollera enheten som avslutar subnätet, inte bara den som vetter mot internet. Små nätverk har ofta tre enheter med en åsikt om routing.

Fråga två: kan LAN:et sluta se klientadresser?

När routern tillhör någon annan kräver översättning på VPN-servern inget samarbete. LAN-värden ser serverns LAN-adress, svarar den, och servern översätter tillbaka. Det är därför apparater och NAT-baserade fjärråtkomstroller beter sig så.

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

Priset är tillskrivning: adresser per klient försvinner från LAN-loggarna. Varje allowlist på LAN-värden måste då namnge servern i stället för poolen.

Välj översättning när samarbete inte är tillgängligt, inte när det bara är obekvämt. Det döljer klienten för varje framtida utredning, även de där du behöver veta vilken bärbar dator som öppnade en anslutning. Det kan också bryta protokoll som bäddar in adresser i nyttolasten, eftersom översättningen sitter i headern. Ingen av lösningarna är mer avancerad; de svarar på olika frågor om ägande.

Fråga tre: är servern själv klient hos en annan tunnel?

Föreställ dig den andra topologin: VPN-servern ringer också upp en kommersiell leverantör, så den har två tunnlar och två uppsättningar adresser. Trafik som den vidarebefordrar för sina egna klienter lämnar genom leverantören, och den routar inte svar tillbaka till pooladresser. Det är därför svar försvinner trots att båda tunnlarna är friska.

Lösningen är att också maskera den utgående tunneln, så leverantören bara ser serverns tunneladress. Den motsatta riktningen behöver sin egen regel, eftersom servern som inleder en anslutning till en av sina egna klienter är ett annat flöde. Utan den regeln svarar klienten på en adress den inte kan routa. Sätt den snäva regeln före varje bred masquerade så att den specifika översättningen vinner.

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-värdar lägger till ett besläktat fel som ser identiskt ut från klienten. Svaret lämnar via gränssnittet med lägre metric eftersom källadressen valdes från en annan tabell. Kontrollera returvägen med en uppslagning i stället för att anta att framvägen medför den.

Verifiera sedan båda riktningarna och båda storlekarna

Efter ändringen, pinga från klienten till en LAN-värd och sedan från LAN-värden till klienten. Den andra riktningen är den folk hoppar över, och det är den som avslöjar en ofullständig översättningsregel. Registrera båda resultaten med tidsstämpel så att en senare regression går att jämföra.

Flytta sedan riktig data, eftersom en liten ping som lyckas medan en stor överföring stannar är ett MTU-symtom. Det felet dyker upp precis efter att du gratulerat dig själv till att ha lagat rutten.

Testa till sist igen efter en omstart. Runtime-kommandon för rutter och brandvägg överlever inte en, och en lösning som försvinner vid nästa start kommer att diagnostiseras igen av någon med mindre sammanhang. Gör ändringen beständig på det sätt ditt system redan gör det, och starta sedan om en gång med avsikt.