«Kobler fra» er en tilstand klienten rapporterer mens den river ned en tunnel, ikke en dom om at trafikken har stoppet. På en Mac går den nedrivingen som en kort sekvens, og etiketten endres først når komponenten som eier forbindelsen melder tilbake. Når ett trinn venter på en hjelper, en plugin eller en policyavgjørelse, kan etiketten bli stående etter at grensesnittet er borte, eller tunnelen kan fortsette å videresende mens menyen fortsatt viser den. Behandle teksten som «nedriving pågår, resultatet er ukjent» og finn ut hvilken halvdel som er sann.

To feil ser like ut fra menylinjen og krever motsatte reaksjoner. I den ene bærer tunnelen fortsatt pakker, og bare visningen er utdatert. I den andre er tunnelen borte, men en egen policy holder trafikken blokkert, noe som ofte er med vilje. Ruter og DNS-tilstand skiller dem raskere enn noen menyehandling.

Hva etiketten følger

En VPN-klient holder en liten tilstandsmaskin, og menylinjen er en projeksjon av den. For en forbindelse som macOS selv administrerer, sitter maskinen i systemets VPN-rammeverk. For en app-administrert tunnel sitter den i appen og dens privilegerte hjelper. Det siste trinnet i en stopp er ikke å lukke en socket. Det er å frigjøre det som gjorde tunnelen funksjonsdyktig: utun-grensesnittet, rutene som pekte på det, resolveroppføringene klienten la inn, og enhver brannmurregel eller policy som blokkerte trafikk mens forbindelsen var oppe.

Disse trinnene er atskilte, så en stopp kan henge i hvilket som helst av dem. En hjelper som slutter å svare, en rute som et andre grensesnitt også gjør krav på, eller en resolveroppføring som en annen profil eier, kan la klienten vente. Etiketten er en rapport om klientens egen fremdrift, noe som gjør den autoritativ om intensjonen og upålitelig om nettverket.

Finn komponenten som eier forbindelsen

For innebygde konfigurasjoner skriver scutil --nc list ut tjenestene systemet kjenner og statusen deres, og scutil --nc status "Work VPN" gir detaljer for én tjeneste. En tunnel som holdes av en tredjepartsapp, vises kanskje ikke i den listen i det hele tatt, så et tomt resultat er ikke bevis for at ingenting er tilkoblet.

Når profilen tilhører en app, stol på dens statusvisning og den dokumenterte «Koble fra»-kontrollen. Å lukke vinduet er ikke en stoppforespørsel hvis en bakgrunnshjelper eier tunnelen; ikonet forsvinner, og hjelperen holder grensesnittet i live. Apples referanse for VPN-innstillinger dekker de innebygde kontrollene og hvor administrerte innstillinger kommer fra.

Les grensesnitt, ruter og DNS

Tre kontroller svarer på det meste av spørsmålet uten å røre forbindelsen. Det er tolkningen sammen som teller, fordi hver enkelt alene villeder.

scutil --nc list
netstat -rn -f inet | head -20
ifconfig | grep -A 3 '^utun'
scutil --dns | head -30
  • utun-grensesnitt til stede, standard- eller delt rute gjennom det, resolver peker på leverandøren: tunnelen er fortsatt oppe, og etiketten er utdatert.
  • ingen utun, vanlig standardrute, DNS fra DHCP, ingen internett: en policy som blokkerer ved frakobling, gjør jobben sin.
  • ingen utun, ingen rute, resolver peker fortsatt på leverandøren: nedrivingen stoppet halvveis, og DNS er resten som må ryddes.

Send deretter én forespørsel til en intern vert som bare skal svare gjennom tunnelen, og én til en offentlig vert. Rekkevidde skiller policy fra resttilstand uten å gjøre kontrollen til en måleøvelse. Lagre fjernarbeid først hvis veien fortsatt svarer, og sørg for en annen inngang før du endrer nettverket på en maskin du administrerer eksternt.

Hvorfor bredt drap og sletting av profilen villeder

Prosessnavn som pppd, racoon og configd tilhører bestemte implementasjoner. Å drepe dem kan påvirke andre forbindelser, etterlater ruter og utun-grensesnitt, og gir deg ingen oversikt over hvilket trinn som hang. Et gammelt prosessnavn er heller ikke bevis for at det eier den gjeldende profilen.

Å slette og gjenopprette profilen er en større endring enn å rydde en fastlåst overgang. Den kan kaste administrerte innstillinger og lokalt identitetsmateriale uten å forklare hva som feilet, og på en Mac under oppsyn blir den kanskje bare gjenopprettet. Spar sletting til en konfigurasjon som virkelig er utdatert, og diagnostiser overgangen i stedet.

En stoppsekvens som etterlater spor

Rekkefølgen nedenfor lar forbindelsens egne kontroller styre og lager en registrering hvis fastlåsingen kommer tilbake. Den hindrer deg også i å gjøre et visningsproblem til en nettverksendring.

  1. Lagre fjernarbeid, og bekreft at du kan nå Macen på en annen måte hvis den er ekstern.
  2. Noter klientens navn, versjon og profil. Ta opp et kort vindu med log show --last 5m --predicate 'subsystem == "com.apple.networkextension"'; eldre versjoner beholder mindre historikk, så kjør det rett etter fastlåsingen.
  3. Bruk den dokumenterte «Koble fra»-kontrollen, vent, og gjenta deretter grensesnitt- og rutekontrollene.
  4. Hvis etiketten er utdatert, men tunnelen er nede, la den stå og la klienten oppdatere seg i stedet for å tvinge prosesser.
  5. Hvis nedrivingen virkelig hang, start klienten på nytt, og planlegg deretter en omstart av Macen når arbeidet er lagret. Administrerte maskiner trenger administratorprosedyren.

Etter gjenoppretting, bekreft at den vanlige standardruten og DHCP-resolveren er tilbake, og at blokkert trafikk enten er gjenopprettet eller fortsatt blokkert med vilje. Noter profilen og klientversjonen sammen med symptomet, slik at neste forekomst starter med bevis i stedet for en gjetning fra menylinjen.

Relaterte artikler