Webserveren forsvinder, når VPN-klienten opretter forbindelse

En tjeneste, der forsvinder i det øjeblik, en VPN-klient opretter forbindelse, bliver normalt ikke blokeret, den svarer gennem den forkerte grænseflade. Forespørgslen ankommer på det fysiske netkort, daemonen skriver et svar, og routingtabellen giver svaret til tunnelen, fordi tunnelen har overtaget standardruten. Den eksterne klient ser aldrig et svar på en forbindelse, den åbnede, så den venter og rapporterer derefter en timeout. Ingen firewallregel er involveret noget sted i det forløb.

Symptomet: forespørgsler ind, svar ud ad den forkerte dør

Tegnet er en indgående forbindelse, der fejler, mens alt andet på værten virker. Et andet tegn er en vært, der kan nås fra LAN, men ikke fra internettet, eller en der virker, indtil tunnelen genopretter forbindelsen og derefter stopper. I hvert tilfælde opførte retningen fremad sig pænt, og returretningen gjorde ikke, hvilket peger på routingasymmetri snarere end på politik.

Bekræft det ved at se, hvor svaret går hen, ikke ved at se forespørgslen ankomme.

Optag samtidigt på den fysiske grænseflade og på tunneleenheden. Hvis forespørgslen vises på den fysiske grænseflade, og svaret vises på tunnelen, er diagnosen færdig. Et svar, der ikke vises nogen steder, betyder, at tjenesten aldrig accepterede forbindelsen, hvilket er en separat undersøgelse med en separat årsag.

To standardruter og én routingbeslutning

En klient, der installerer en standardrute, tilføjer en anden post med en bedre metrik end LAN-gatewayen. Nogle klienter installerer i stedet to halvområderuter, som dækker samme plads mere specifikt og vinder opslaget på samme måde. Begge teknikker efterlader almindelige udgående pakker med at vælge tunnelegrænsefladen.

Det valg træffes alene efter destination. Kernen spørger ikke, hvor en pakke kom fra, medmindre en policy-regel beder den om det. Så svaret til en offentlig klientadresse gives til tunnelen, hvis fjerne ende modtager en pakke med en kildeadresse, den ikke ejer, og kasserer den eller videresender den et ubrugeligt sted hen. På Linux kan streng reverse-path-filtrering også droppe den oprindelige forespørgsel, før din tjeneste overhovedet ser den, hvilket ser identisk ud udefra. Begge symptomer kommer fra den samme manglende sammenkædning mellem en indgående strøm og dens svar.

Tunnelen opfører sig korrekt hele vejen igennem. Den fik besked om at bære standardruten, og det gør den præcis.

Ret returvejen uden at ødelægge tunnelen

Der findes tre holdbare former for reparation, og valget afhænger af, hvor meget af værtens egen trafik der skal blive inde i tunnelen. At udelukke tjenestens destination eller port er den mindste ændring. Policy-routing efter kilde eller mærke er den mest præcise. Kildeoversættelse er den groveste og den letteste at forklare to år senere.

Vælg efter, hvad værten skal gøre, ikke efter hvilket uddrag du fandt først.

At udelukke en destination passer til en tjeneste med en stabil offentlig adresse, og at binde daemonen til den fysiske adresse i stedet for til alle adresser gør den udelukkelse sikrere. En policy-regel, der vælger en tabel efter kilde, holder værtens egne forbindelser inde i tunnelen, mens den sender tjenestens svar tilbage gennem WAN-gatewayen. Maskering af svar til WAN-grænsefladen når samme vej på bekostning af at skjule klientens adresse i tjenestens logfiler. En ad hoc-ændring af standardruten er en diagnostik og ikke en konfiguration, fordi klienten omskriver ruter ved hver genopkobling.

ip rule show
ip route get 203.0.113.9 from 192.0.2.44

Når værten også router for et LAN bag sig

Et hop længere ude vender den samme asymmetri tilbage med flere bevægelige dele. Trafik når routeren fra internettet, videresendes til en intern enhed, og den enheds eneste vej tilbage er tunnelen, så svaret når den oprindelige klient fra udbyderens egen adresse. Forbindelsessporing møder derefter et svar for en strøm, den ikke har set begynde, og kasserer det. Klienten ser i mellemtiden slet ingenting.

To ændringer reparerer det: destinationsoversættelse, så den indgående forbindelse når den interne enhed, og kildeoversættelse, så den enheds svar ser ud til at komme fra routeren selv.

På routerfirmware er det sædvanlige udtryk en policy-regel, der fæstner port-forwarding til WAN-siden, mens routerens egen trafik kører gennem tunnelen. Uden kildeoversættelse er det svar adresseret til den eksterne klient, og den interne enhed har simpelthen ingen rute til den. Test tre ting hver for sig, fordi de fejler af forskellige grunde: en forbindelse, der ankommer udefra, en som værten selv starter, og et navneopslag.