Varför en VPN kan se ansluten ut när ingenting fungerar

Din klient rapporterar ansluten medan gränssnittet är uppe och webbläsaren får timeout, och ingen av de tre påståendena är falsk. Ansluten beskriver ett lager som inte har något med sidan du bad om att göra. Att avgöra vilket lager som rapporterar kräver en ny begäran och en blick på räknaren som skulle bevisa att trafiken rörde sig. En omstart slänger det beviset och bygger upp igen de förhållanden du försökte observera.

Tre olika saker som kallas ansluten

Längst ned kan ansluten betyda att en klientprocess kör och håller en socket mot en peer. Ovanför det kan det betyda att det finns ett gränssnitt med en adress, som en permanent enhet eller en återställningsrutin kan skapa utan en levande session bakom. På kontrollnivå kan det betyda att en association förhandlades fram, vilket inte säger något om huruvida ett enda paket har korsat under den. Var och en av dem överlever fel som de andra inte överlever, och en klient visar vanligtvis den starkaste den kan göra anspråk på.

En grön ikon och en död tunnel är därför förenliga och inte motsägelsefulla; de rapporterar om olika objekt. Det är hela anledningen till att detta fel ständigt feldiagnostiseras som en klientbugg.

Skicka en ofarlig begäran till en destination du faktiskt behöver innan du rör daemonen, och håll det nödvändiga blocket för direkt trafik på plats medan du arbetar. En omstart suddar ut händelsernas ordning och återskapar dem sedan nära nog för att dölja orsaken, och därför kommer samma ärende tillbaka en vecka senare utan något nytt i sig. En begäran, en räknaravläsning och den utlösare som framkallade felet är minimibeviset.

Vilken räknare bevisar att paketen rörde sig

I IPsec är IKE-associationen och CHILD-associationen separata objekt, och bara child bär de räknare som besvarar den här frågan. Lista child, se om paketen ökar i båda riktningarna och jämför det med vad applikationen försöker göra. En installerad association på noll är ett annat fynd än en som ökar medan applikationen fortfarande misslyckas; det första betyder att trafiken inte väljs, det andra att den rör sig och att felet är längre fram. Läs räknarna två gånger, några sekunder isär, eftersom ett prov inte kan visa en trend.

swanctl --list-sas
ip xfrm state list
ip -s link show dev tun0

Nollräknare pekar på valet: routing, policy, ett namnutrymme paketet lämnade, eller ett gränssnitt som klienten aldrig band sig till. Växande räknare pekar bort från tunneln, så fortsätt med vidarebefordran i den bortre änden, namnuppslagning, returvägen och destinationstjänsten, i den ordningen. Ett protokoll utan separat child-objekt blottlägger samma bevis på sina egna villkor, så använd det den rapporterar om peer-tillstånd och paketantal i stället för att låna IPsec-ordförrådet. Avläsningens form betyder mer än verktyget som skapade den.

Var felet sitter efter att räknarna rör sig

En gateway som svarar på sin egen administrationsadress bevisar att gatewayen kör, inte att något bakom den betjänar din begäran, så testa den bortre sidan och inte lådan i mitten. Namnuppslagning döljer fel bäst, eftersom en resolver som inte går att nå genom tunneln får timeout precis som en död anslutning. Två uppslagningar skiljer de fallen, och båda är billiga. Fråga först resolvern som tunneln tvingar fram och fråga sedan en offentlig resolver om samma namn.

dig +short host.example
dig +short @10.20.0.1 host.example
ping -c 2 10.20.0.25

Ett namn som löses via den offentliga resolvern men inte via tunnelns resolver betyder att DNS-vägen är bruten, medan ett namn som löses via båda och ändå får timeout i webbläsaren pekar på returvägen eller på tjänsten. Om ping på adress lyckas och applikationen fortfarande vägrar, levererade nätet begäran och tjänsten avvisade den, vilket är ett helt senare stadium.

Notera utlösaren och ändra sedan en sak

Notera vad som föregick felet: en period av inaktivitet, en nätverksändring, en nyckelförnyelse, en återupptagen bärbar dator eller ett återställt system. De ger olika mekanismer, och vanligtvis reparerar bara det återställda systemet sig självt, vilket är precis det fall som inte lär dig något. En omstart tar bort händelsernas ordning och återskapar sedan förhållanden som ligger nära nog för att dölja orsaken. Skriv ned utlösaren medan den fortfarande går att återskapa.

Gör sedan en underbyggd korrigering och upprepa den ursprungliga begäran tillsammans med utlösaren som framkallade felet. Inaktivitet är den lättaste utlösaren att återskapa, så det är den snabbaste bekräftelsen på att korrigeringen tog mekanismen och inte symptomet.

Det du vill rapportera är bevis för att trafiken du avsåg att skicka nådde den tjänst du avsåg att nå. En ikon som blir grön, en cachad sida som laddas och en räknare som rör sig bevisar alla mindre än en slutförd begäran mot den avsedda destinationen. Håll begäran, räknaravläsningen och utlösaren tillsammans, så att nästa person kan skilja en korrigering från ett sammanträffande.