Mac-VPN fastnar på ”Kopplar från”: vad som faktiskt körs

Frånkoppling är en övergång, inte en stoppad tunnel. Kontrollera vilken komponent som äger nedmonteringen, läs rutter och DNS, och hoppa över breda processdödningar.

”Kopplar från” är ett tillstånd som klienten rapporterar medan den monterar ned en tunnel, inte en dom om att trafiken har stannat. På en Mac går den nedmonteringen som en kort sekvens, och etiketten ändras först när komponenten som äger anslutningen rapporterar tillbaka. När ett steg väntar på en hjälpare, ett plugin eller ett policybeslut kan etiketten stå kvar efter att gränssnittet är borta, eller tunneln kan fortsätta vidarebefordra medan menyn fortfarande visar den. Behandla texten som ”nedmontering pågår, resultatet är okänt” och ta reda på vilken halva som är sann.

Två fel ser likadana ut från menyraden och kräver motsatta åtgärder. I det ena bär tunneln fortfarande paket och bara visningen är inaktuell. I det andra är tunneln borta men en separat policy håller trafiken blockerad, vilket ofta är avsiktligt. Rutter och DNS-tillstånd skiljer dem snabbare än någon menyåtgärd.

Vad etiketten följer

En VPN-klient håller en liten tillståndsmaskin, och menyraden är en projektion av den. För en anslutning som macOS själv hanterar sitter maskinen i systemets VPN-ramverk. För en apphanterad tunnel sitter den i appen och dess privilegierade hjälpare. Det sista steget i en stopp är inte att stänga en socket. Det är att släppa det som gjorde tunneln funktionsduglig: utun-gränssnittet, rutterna som pekade på det, resolverposterna som klienten matade in, och varje brandväggsregel eller policy som blockerade trafik medan anslutningen var uppe.

Dessa steg är åtskilda, så en stopp kan fastna på vilket som helst av dem. En hjälpare som slutar svara, en rutt som även ett andra gränssnitt gör anspråk på, eller en resolverpost som en annan profil äger kan låta klienten vänta. Etiketten är en rapport om klientens egen framdrift, vilket gör den auktoritativ om avsikten och opålitlig om nätet.

Hitta komponenten som äger anslutningen

För inbyggda konfigurationer skriver scutil --nc list ut de tjänster systemet känner till och deras status, och scutil --nc status "Work VPN" ger detaljer för en tjänst. En tunnel som hålls av en tredjepartsapp kanske inte syns i listan alls, så ett tomt resultat är inte bevis för att inget är anslutet.

När profilen tillhör en app, lita på dess statusvy och den dokumenterade ”Koppla från”-kontrollen. Att stänga fönstret är inte en stoppbegäran om en bakgrundshjälpare äger tunneln; ikonen försvinner och hjälparen håller gränssnittet vid liv. Apples referens för VPN-inställningar täcker de inbyggda kontrollerna och varifrån hanterade inställningar kommer.

Läs gränssnitt, rutter och DNS

Tre kontroller besvarar det mesta av frågan utan att röra anslutningen. Det är tolkningen tillsammans som avgör, eftersom var och en för sig vilseleder.

scutil --nc list
netstat -rn -f inet | head -20
ifconfig | grep -A 3 '^utun'
scutil --dns | head -30
  • utun-gränssnitt finns, standard- eller delad rutt går genom det, resolver pekar mot leverantören: tunneln är fortfarande uppe och etiketten är inaktuell.
  • ingen utun, vanlig standardrutt, DNS från DHCP, inget internet: en policy som blockerar vid frånkoppling gör sitt jobb.
  • ingen utun, ingen rutt, resolver pekar fortfarande mot leverantören: nedmonteringen stannade halvvägs, och DNS är resten som måste rensas.

Skicka sedan en begäran till en intern värd som bara ska svara genom tunneln och en till en offentlig värd. Nåbarhet skiljer policy från resttillstånd utan att göra kontrollen till en mätövning. Spara fjärrarbete först om vägen fortfarande svarar, och ordna en andra väg in innan du ändrar nätverket på en maskin du administrerar på distans.

Varför breda dödningar och borttagning av profilen vilseleder

Processnamn som pppd, racoon och configd tillhör bestämda implementationer. Att döda dem kan påverka andra anslutningar, lämnar rutter och utun-gränssnitt efter sig och ger dig ingen uppgift om vilket steg som fastnade. Ett gammalt processnamn är inte heller bevis för att det äger den aktuella profilen.

Att ta bort och återskapa profilen är en större ändring än att rensa en fastnad övergång. Det kan kasta hanterade inställningar och lokalt identitetsmaterial utan att förklara vad som misslyckades, och på en Mac under uppsikt återställs den kanske bara. Spara borttagningen för en konfiguration som verkligen är föråldrad och diagnostisera i stället övergången.

En stoppsekvens som lämnar spår

Ordningen nedan låter anslutningens egna kontroller styra och skapar en anteckning om fastnandet kommer tillbaka. Den hindrar dig också från att göra ett visningsproblem till en nätverksändring.

  1. Spara fjärrarbete och bekräfta att du når Macen på annat sätt om den är på distans.
  2. Anteckna klientens namn, version och profil. Fånga ett kort fönster med log show --last 5m --predicate 'subsystem == "com.apple.networkextension"'; äldre versioner behåller mindre historik, så kör det strax efter fastnandet.
  3. Använd den dokumenterade ”Koppla från”-kontrollen, vänta och upprepa sedan gränssnitts- och ruttkontrollerna.
  4. Om etiketten är inaktuell men tunneln är nere, låt den stå och låt klienten uppdatera sig i stället för att tvinga processer.
  5. Om nedmonteringen verkligen fastnade, starta om klienten och planera sedan en omstart av Macen när arbetet är sparat. Hanterade maskiner kräver administratörens procedur.

Efter återhämtningen, bekräfta att den vanliga standardrutten och DHCP-resolvern är tillbaka och att blockerad trafik antingen är återställd eller fortfarande avsiktligt blockerad. Anteckna profilen och klientversionen tillsammans med symptomet, så att nästa förekomst börjar med bevis i stället för en gissning i menyraden.

Relaterade artiklar