Webbservern försvinner när VPN-klienten ansluter

En tjänst som försvinner i samma ögonblick som en VPN-klient ansluter är vanligtvis inte blockerad, den svarar via fel gränssnitt. Förfrågan kommer in på det fysiska nätverkskortet, daemonen skriver ett svar och routingtabellen lämnar svaret till tunneln, eftersom tunneln har tagit över standardrutten. Den externa klienten ser aldrig ett svar på en anslutning den öppnade, så den väntar och rapporterar sedan timeout. Ingen brandväggsregel är inblandad någonstans i den sekvensen.

Symtomet: förfrågningar in, svar ut genom fel dörr

Tecknet är en inkommande anslutning som misslyckas medan allt annat på värden fungerar. Ett annat tecken är en värd som nås från LAN men inte från internet, eller en som fungerar tills tunneln återansluter och sedan stannar. I varje fall betedde sig riktningen utåt korrekt och returriktningen inte, vilket pekar på routingasymmetri och inte på policy.

Bekräfta det genom att se vart svaret tar vägen, inte genom att se hur förfrågan kommer in.

Fånga samtidigt på det fysiska gränssnittet och på tunneleenheten. Om förfrågan syns på det fysiska gränssnittet och svaret på tunneln är diagnosen klar. Ett svar som inte syns någonstans betyder att tjänsten aldrig accepterade anslutningen, vilket är en separat undersökning med en separat orsak.

Två standardrutter och ett routingbeslut

En klient som installerar en standardrutt lägger till en andra post med bättre metrik än LAN-gatewayen. Vissa klienter installerar i stället två halvområdesrutter, som täcker samma utrymme mer specifikt och vinner uppslagningen på samma sätt. Båda teknikerna låter vanliga utgående paket välja tunnelgränssnittet.

Det valet görs bara efter destination. Kärnan frågar inte varifrån ett paket kom om inte en policyregel beordrar det. Så svaret till en offentlig klientadress lämnas till tunneln, vars bortre ände tar emot ett paket med en källadress som den inte äger och kastar det eller vidarebefordrar det någonstans värdelöst. På Linux kan strikt reverse-path-filtrering också släppa den ursprungliga förfrågan innan din tjänst ens ser den, vilket ser identiskt ut utifrån. Båda symptomen kommer från samma saknade koppling mellan ett inkommande flöde och dess svar.

Tunneln beter sig korrekt hela tiden. Den fick order att bära standardrutten och det gör den exakt.

Reparera returvägen utan att bryta tunneln

Det finns tre hållbara former av reparation, och valet beror på hur mycket av värdens egen trafik som ska stanna inuti tunneln. Att utesluta tjänstens destination eller port är den minsta ändringen. Policy-routing efter källa eller markering är den mest exakta. Källöversättning är den grövsta och den lättaste att förklara två år senare.

Välj efter vad värden måste göra, inte efter vilken snutt du hittade först.

Att utesluta en destination passar en tjänst med stabil offentlig adress, och att binda daemonen till den fysiska adressen i stället för till alla adresser gör den uteslutningen säkrare. En policyregel som väljer en tabell efter källa håller värdens egna anslutningar inuti tunneln samtidigt som den skickar tillbaka tjänstens svar via WAN-gatewayen. Maskering av svar mot WAN-gränssnittet når samma väg till priset av att klientens adress döljs i tjänstens loggar. En ad hoc-ändring av standardrutten är en diagnos och inte en konfiguration, eftersom klienten skriver om rutterna vid varje återanslutning.

ip rule show
ip route get 203.0.113.9 from 192.0.2.44

När värden också routar för ett LAN bakom sig

Ett hopp längre ut kommer samma asymmetri tillbaka med fler rörliga delar. Trafik når routern från internet, vidarebefordras till en intern enhet, och den enhetens enda väg tillbaka är tunneln, så svaret når den ursprungliga klienten från leverantörens egen adress. Sedan möter anslutningsspårningen ett svar för ett flöde vars början den inte har sett, och kastar det. Klienten ser under tiden ingenting alls.

Två ändringar reparerar det: destinationsöversättning så att den inkommande anslutningen når den interna enheten, och källöversättning så att den enhetens svar ser ut att komma från routern själv.

På router-firmware är det vanliga uttrycket en policyregel som fäster portvidarebefordran vid WAN-sidan medan routerns egen trafik går genom tunneln. Utan källöversättning är det svaret adresserat till den externa klienten och den interna enheten har helt enkelt ingen rutt dit. Testa tre saker var för sig, eftersom de misslyckas av olika skäl: en anslutning som kommer utifrån, en som värden själv startar, och en namnuppslagning.