Hvad der faktisk ændrer sig, når du skifter gemte VPN-konfigurationer på macOS
At skifte en gemt Mac-VPN er ikke et profilbytte. Se hvad der ændrer sig i ruter, DNS og legitimationsoplysninger, og hvordan du bekræfter den tunnel, du rent faktisk fik.
Du åbner VPN-listen, vælger den anden gemte post og forventer et rent skift: en ny udgangsadresse og alt andet uændret. Det er den antagelse, du først skal opgive. På macOS er en gemt VPN en fuld netværkstjeneste og ikke en forudindstilling, så skift af tjenester kan ændre routing, DNS og godkendelse på samme tid. Menulinjen viser, hvilken tjeneste der er aktiv; den viser ikke, om tunnelen under den svarer til det, du havde tænkt.
Den gemte liste er ikke en profilvælger
Hver post i Systemindstillinger > Netværk er sin egen tjeneste med sin egen serveradresse, konto, godkendelsesmetode, DNS-servere og indstillinger som Send al trafik over VPN-forbindelsen. Ældre versioner har den samme liste i Systemindstillinger. To poster kan pege på det samme værtsnavn og stadig opføre sig forskelligt, fordi protokollen eller klientudvidelsen bestemmer, hvordan tunnelen bygges.
Tredjepartsklienter har separate lister. Tunnelblick læser konfigurationer fra sin egen mappe, WireGuard holder sin egen tunnelliste, og OpenVPN Connect gemmer profiler inde i appen. Nogle registrerer en konfiguration i systemet; andre holder alt inde i appen og optræder aldrig på den indbyggede liste. «Skift til den gemte» betyder derfor forskellige handlinger afhængigt af, hvilken app der ejer profilen.
scutil --nc list udskriver de VPN-tjenester, der er registreret i systemkonfigurationen, med navnene i citationstegn. Brug præcis disse navne, når du script’er et skift, og antag ikke, at listen dækker hver tredjepartstunnel.
Hvad et skift faktisk ændrer
Fire ting flytter sig sammen, når den aktive tjeneste skifter. Standardruten følger den nye tunnel, hvis tjenesten sender al trafik; resolverlisten skifter til de DNS-servere, tjenesten angiver; nye forbindelser tager den nye tunneladresse som kilde; og de legitimationsoplysninger, der bruges, tilhører den nye tjeneste. En indbygget konfiguration og en appprofil kan ikke udskifte hinanden, selv når begge ender ved samme gateway.
| What you assume | What the system does |
|---|---|
| Same server name means same tunnel | Protocol, certificate and account are per service |
| All traffic follows the active VPN | Only when Send all traffic over VPN is on |
| DNS switches with the VPN | Only if that service defines DNS servers |
| Disconnect ends the connection | On Demand or a management profile can reconnect |
| Open sessions survive the switch | TCP sessions tied to the old address stall |
DNS-delen snyder folk. macOS opretholder en resolverrækkefølge, og scutil --dns viser, hvilke resolvere der er i brug, og på hvilken grænseflade. En VPN-tjeneste uden konfigurerede DNS-servere kan efterlade Wi-Fi-resolveren som den, der svarer, så du får en ny offentlig adresse med den gamle DNS-adfærd og konkluderer, at skiftet virkede halvt.
Hvorfor den gamle konfiguration kommer tilbage
Hvis du afbryder, og den samme tjeneste genopretter forbindelse et øjeblik senere, så kig på On Demand først. En regel for tilslutning efter behov kan bringe en tjeneste tilbage, når en app opløser et matchende domæne, og en administrationsprofil kan håndhæve den samme regel. Sletning af posten løser det sjældent: en profilinstalleret konfiguration vender normalt tilbage ved næste profilopdatering, og en manuel kan efterlade sin adgangskode i Keychain, mens tjenesten er væk.
At starte en anden tjeneste stopper ikke altid den første. Afhængigt af klient og protokol kan du ende med to tunneler og to sæt ruter, og tjenesterækkefølge plus rutespecificitet afgør, hvilken der bærer trafikken, ikke det ikon, du sidst klikkede på. Tjek grænsefladerne, før du antager, at et skift er sket.
Bekræft tunnelen, ikke fluebenet
Gå gennem systemets eget billede, før du rører indstillingerne.scutil --nc status "Name" rapporterer, hvad systemet tror;ifconfig viser, om en utun-grænseflade har en adresse;netstat -rn -f inet viser, hvor standardruten peger;scutil --dns viser den resolver, der faktisk bruges. Åbn derefter en frisk forbindelse og bekræft udgangsadressen, for en side, der allerede var logget ind, bruger måske stadig en socket bundet til den gamle tunnel.
Hvis DNS stadig svarer fra det lokale netværk, så sammenlign tjenestens konfigurerede servere med resolverlisten. Hvis standardruten stadig peger på den fysiske grænseflade, er tjenesten split-tunnel eller ikke fuldt forbundet. Begge er konfigurationsresultater, ikke bevis på en defekt klient.
En skifterækkefølge, der undgår overraskelser
- Noter den aktuelle tjeneste, og om en profil styrer den.
- Afbryd den først, når de to tunneler ikke kan eksistere sammen.
- Forbind målet, og vent på Forbundet, ikke Forbinder.
- Tjek standardruten, resolverlisten og en frisk udgangsadresse.
- Genstart apps, der holder langvarige sessioner.
Behold den gamle post, indtil den nye består disse tjek, og giv hver post et særskilt navn; identiske etiketter gør den næste fejl sværere at tilskrive. Apples Mac-hjælp beskriver den indbyggede side på Opsæt en VPN-forbindelse på Mac, som er referencepunktet, man bør tjekke, før man redigerer en administreret konfiguration.
Hvis valget springer tilbage, så behandl det først som politik eller On Demand. Bekræft, hvem der ejer konfigurationen, og om den er sat til automatisk forbindelse, og afgør derefter, om du skifter en tjeneste, eller kæmper mod en profil.