Nettjeneren forsvinner når VPN-klienten kobler til

En tjeneste som forsvinner i det øyeblikket en VPN-klient kobler til, er vanligvis ikke blokkert, den svarer gjennom feil grensesnitt. Forespørselen kommer inn på det fysiske nettverkskortet, daemonen skriver et svar, og rutetabellen gir svaret til tunnelen, siden tunnelen har overtatt standardruten. Den eksterne klienten ser aldri et svar på en tilkobling den åpnet, så den venter og rapporterer deretter tidsavbrudd. Ingen brannmurregel er involvert noe sted i den sekvensen.

Symptomet: forespørsler inn, svar ut gjennom feil dør

Tegnet er en innkommende tilkobling som feiler mens alt annet på verten virker. Et annet tegn er en vert som er nåbar fra LAN, men ikke fra internett, eller en som virker til tunnelen kobler til på nytt og deretter stopper. I hvert tilfelle oppførte retningen utover seg pent, og returretningen ikke, noe som peker på ruteasymmetri og ikke på policy.

Bekreft det ved å se hvor svaret går, ikke ved å se hvordan forespørselen kommer inn.

Fang samtidig på det fysiske grensesnittet og på tunneleenheten. Hvis forespørselen vises på det fysiske grensesnittet og svaret på tunnelen, er diagnosen ferdig. Et svar som ikke vises noe sted, betyr at tjenesten aldri godtok tilkoblingen, noe som er en egen undersøkelse med egen årsak.

To standardruter og én rutebeslutning

En klient som installerer en standardrute, legger til en annen oppføring med bedre metrikk enn LAN-gatewayen. Noen klienter installerer i stedet to halvområderuter, som dekker samme rom mer spesifikt og vinner oppslaget på samme måte. Begge teknikkene lar vanlige utgående pakker velge tunnelegrensesnittet.

Det valget tas bare etter destinasjon. Kjernen spør ikke hvor en pakke kom fra med mindre en policy-regel ber den om det. Så svaret til en offentlig klientadresse gis til tunnelen, hvis fjerne ende mottar en pakke med en kildeadresse den ikke eier og forkaster den eller videresender den et ubrukelig sted. På Linux kan streng reverse-path-filtrering også droppe den opprinnelige forespørselen før tjenesten din i det hele tatt ser den, noe som ser identisk ut utenfra. Begge symptomene kommer fra den samme manglende koblingen mellom en innkommende strøm og svaret dens.

Tunnelen oppfører seg riktig hele veien. Den fikk beskjed om å bære standardruten, og det gjør den nøyaktig.

Reparer returveien uten å ødelegge tunnelen

Det finnes tre varige former for reparasjon, og valget avhenger av hvor mye av vertens egen trafikk som skal bli inne i tunnelen. Å utelukke tjenestens destinasjon eller port er den minste endringen. Policy-ruting etter kilde eller merke er den mest presise. Kildeoversettelse er den groveste og den letteste å forklare to år senere.

Velg etter hva verten må gjøre, ikke etter hvilken snutt du fant først.

Å utelukke en destinasjon passer for en tjeneste med stabil offentlig adresse, og å binde daemonen til den fysiske adressen i stedet for til alle adresser gjør den utelukkelsen sikrere. En policy-regel som velger en tabell etter kilde, holder vertens egne tilkoblinger inne i tunnelen mens den sender tjenestens svar tilbake gjennom WAN-gatewayen. Maskering av svar til WAN-grensesnittet når samme vei på bekostning av å skjule klientens adresse fra tjenestens logger. En ad hoc-endring av standardruten er en diagnose og ikke en konfigurasjon, fordi klienten skriver om rutene ved hver gjentilkobling.

ip rule show
ip route get 203.0.113.9 from 192.0.2.44

Når verten også ruter for et LAN bak seg

Ett hopp lenger ute kommer den samme asymmetrien tilbake med flere bevegelige deler. Trafikk når ruteren fra internett, videresendes til en intern enhet, og den enhetens eneste vei tilbake er tunnelen, så svaret når den opprinnelige klienten fra leverandørens egen adresse. Deretter møter tilkoblingssporing et svar for en strøm den ikke har sett starte, og forkaster det. Klienten ser i mellomtiden ingenting i det hele tatt.

To endringer reparerer det: destinasjonsoversettelse slik at den innkommende tilkoblingen når den interne enheten, og kildeoversettelse slik at den enhetens svar ser ut til å komme fra ruteren selv.

På ruter-fastvare er det vanlige uttrykket en policy-regel som fester portvideresendingen til WAN-siden mens ruterens egen trafikk går gjennom tunnelen. Uten kildeoversettelse er det svaret adressert til den eksterne klienten, og den interne enheten har rett og slett ingen rute til det. Test tre ting hver for seg, fordi de feiler av ulike grunner: en tilkobling som kommer utenfra, en som verten selv starter, og et navneoppslag.