Kvifor ein VPN kan sjå tilkopla ut medan ingenting verkar

Klienten din rapporterer tilkopla medan grensesnittet er oppe og nettlesaren får tidsavbrot, og ingen av dei tre påstandane er falske. Tilkopla skildrar eit lag som ikkje har noko med sida du bad om å gjere. Å avgjere kva lag som rapporterer krev éin ny førespurnad og eitt blikk på teljaren som ville prova at trafikken flytta seg. Ein omstart kastar det provet og byggjer opp att tilhøva du prøvde å observere.

Tre ulike ting som vert kalla tilkopla

Nedst kan tilkopla tyde at ein klientprosess køyrer og held ein socket mot ein peer. Over det kan det tyde at det finst eit grensesnitt med ei adresse, som ein permanent eining eller ein gjenopprettingsrutine kan lage utan ein levande sesjon bak. På kontrollnivå kan det tyde at ein assosiasjon vart forhandla, noko som ikkje seier noko om korvidt ein einaste pakke har krossa under han. Kvar av dei overlever feil som dei andre ikkje overlever, og ein klient viser vanlegvis den sterkaste han kan påberope seg.

Eit grønt ikon og ein daud tunnel er derfor sameinlege og ikkje motstridande; dei rapporterer om ulike objekt. Det er heile grunnen til at denne feilen stadig vert feildiagnostisert som ein klientfeil.

Send éin ufarleg førespurnad til ein destinasjon du faktisk treng før du rører daemonen, og hald den påkravde blokka for direkte trafikk på plass medan du arbeider. Ein omstart slettar rekkjefølgja av hendingar og gjenopprettar dei deretter nær nok til å skjule årsaka, og difor kjem same saka tilbake ei veke seinare utan noko nytt i seg. Éin førespurnad, éi teljaravlesing og utløysaren som framkalla feilen er minimumsprovet.

Kva teljar provar at pakkane flytta seg

I IPsec er IKE-assosiasjonen og CHILD-assosiasjonen separate objekt, og berre child ber teljarane som svarar på dette spørsmålet. List child, sjå om pakkane aukar i begge retningar, og samanlikn det med det applikasjonen prøver å gjere. Ein installert assosiasjon på null er eit anna funn enn ein som aukar medan applikasjonen framleis feilar; det første tyder at trafikken ikkje vert vald, det andre at han flyttar seg og at feilen er lenger framme. Les teljarane to gonger, nokre sekund frå kvarandre, fordi éin prøve ikkje kan vise ein trend.

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

Nullteljarar peikar på valet: ruting, policy, eit namnerom pakken forlét, eller eit grensesnitt klienten aldri batt seg til. Aukande teljarar peikar bort frå tunnelen, så hald fram med vidaresending i den fjerne enden, namneoppslag, returvegen og destinasjonstenesta, i den rekkjefølgja. Ein protokoll utan eit eige child-objekt legg fram det same provet på sine eigne premiss, så bruk det han rapporterer om peer-tilstand og pakketal i staden for å låne IPsec-ordforrådet. Formen på avlesinga tyder meir enn verktøyet som laga henne.

Kvar feilen sit etter at teljarane flyttar seg

Ein gateway som svarar på si eiga administrasjonsadresse provar at gatewayen køyrer, ikkje at noko bak han tener førespurnaden din, så test den fjerne sida og ikkje boksen i midten. Namneoppslag skjuler feil best, fordi ein resolver som ikkje kan nåast gjennom tunnelen, får tidsavbrot akkurat som ei daud samband. To oppslag skil dei tilfella, og begge er billeg. Spør først resolveren tunnelen pressar på, og spør deretter ein offentleg resolver om same namn.

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

Eit namn som vert løyst gjennom den offentlege resolveren men ikkje gjennom tunnelresolveren, tyder at DNS-vegen er broten, medan eit namn som vert løyst gjennom begge og framleis får tidsavbrot i nettlesaren, peikar på returvegen eller på tenesta. Viss ping på adresse lukkast og applikasjonen framleis nektar, leverte nettet førespurnaden og tenesta avviste han, noko som er eit heilt seinare stadium.

Noter utløysaren, og endre så éin ting

Noter kva som gjekk føre feilen: ein periode med inaktivitet, ei nettverksendring, ei nøkkelfornying, ein gjenoppteken berbar eller eit gjenoppretta system. Dei gjev ulike mekanismar, og berre det gjenoppretta systemet reparerer vanlegvis seg sjølv, noko som nettopp er tilfellet som ikkje lærer deg noko. Ein omstart fjernar rekkjefølgja av hendingar og gjenopprettar deretter tilhøve som er nær nok til å skjule årsaka. Skriv ned utløysaren medan han framleis kan gjerast om att.

Gjer så éi understøtta retting og gjer den opphavlege førespurnaden om att saman med utløysaren som framkalla feilen. Inaktivitet er den enklaste utløysaren å gjere om att, så det er den snøggaste stadfestinga på at rettinga tok mekanismen og ikkje symptomet.

Det du vil rapportere, er prov for at trafikken du meinte å sende, nådde tenesta du meinte å nå. Eit ikon som vert grønt, ei bufra side som lastar og ein teljar som flyttar seg provar alle mindre enn éin fullført førespurnad mot den tiltenkte destinasjonen. Hald førespurnaden, teljaravlesinga og utløysaren saman, så neste person kan skilje ei retting frå eit tilfelle.