Vad som faktiskt ändras när du byter sparade VPN-konfigurationer på macOS
Att byta en sparad Mac-VPN är inte ett profilbyte. Se vad som ändras i rutter, DNS och inloggningsuppgifter, och hur du verifierar den tunnel du faktiskt fick.
Du öppnar VPN-listan, väljer den andra sparade posten och förväntar dig ett rent byte: en ny utgångsadress och allt annat oförändrat. Det är antagandet du först bör släppa. På macOS är en sparad VPN en fullständig nätverkstjänst och inte en förinställning, så ett tjänstebyte kan ändra routning, DNS och autentisering samtidigt. Menyraden visar vilken tjänst som är aktiv; den säger inte om tunneln under den matchar det du tänkte.
Den sparade listan är inte en profilväljare
Varje post i Systeminställningar > Nätverk är en egen tjänst, med egen serveradress, konto, autentiseringsmetod, DNS-servrar och alternativ som Skicka all trafik över VPN-anslutningen. Äldre versioner har samma lista i Systeminställningar. Två poster kan peka på samma värdnamn och ändå bete sig olika, eftersom protokollet eller klienttillägget avgör hur tunneln byggs.
Tredjepartsklienter har separata listor. Tunnelblick läser konfigurationer från sin egen mapp, WireGuard har sin egen tunnellista och OpenVPN Connect lagrar profiler inuti appen. Vissa registrerar en konfiguration i systemet; andra har allt inuti appen och syns aldrig i den inbyggda listan. ”Byt till den sparade” betyder därför olika åtgärder beroende på vilken app som äger profilen.
scutil --nc list skriver ut de VPN-tjänster som är registrerade i systemkonfigurationen, med namnen inom citattecken. Använd exakt dessa namn när du skriptar ett byte, och anta inte att listan täcker varje tredjepartstunnel.
Vad ett byte faktiskt ändrar
Fyra saker rör sig tillsammans när den aktiva tjänsten ändras. Standardrutten följer den nya tunneln om tjänsten skickar all trafik; resolverlistan ändras till de DNS-servrar tjänsten anger; nya anslutningar tar den nya tunneladressen som källa; och inloggningsuppgifterna som används tillhör den nya tjänsten. En inbyggd konfiguration och en appprofil är inte utbytbara, även när båda slutar vid samma 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 är den som överraskar folk. macOS upprätthåller en resolverordning, och scutil --dns visar vilka resolvers som används och på vilket gränssnitt. En VPN-tjänst utan konfigurerade DNS-servrar kan låta Wi-Fi-resolvern svara, så du får en ny offentlig adress med det gamla DNS-beteendet och drar slutsatsen att bytet fungerade halvvägs.
Varför den gamla konfigurationen kommer tillbaka
Om du kopplar från och samma tjänst återansluter strax efter, titta först på On Demand. En regel för anslutning på begäran kan få en tjänst tillbaka när en app löser ett matchande domännamn, och en hanteringsprofil kan tvinga fram samma regel. Att radera posten löser det sällan: en profilinstallerad konfiguration kommer oftast tillbaka vid nästa profiluppdatering, och en manuell kan lämna lösenordet i Keychain medan tjänsten är borta.
Att starta en andra tjänst stoppar inte alltid den första. Beroende på klient och protokoll kan du hamna med två tunnlar och två uppsättningar rutter, och tjänsteordning plus routspecificitet avgör vilken som bär trafiken, inte ikonen du klickade på sist. Kontrollera gränssnitten innan du antar att ett byte har skett.
Verifiera tunneln, inte bocken
Gå igenom systemets egen bild innan du rör inställningarna.scutil --nc status "Name" rapporterar vad systemet tror;ifconfig visar om ett utun-gränssnitt har en adress;netstat -rn -f inet visar vart standardrutten pekar;scutil --dns visar resolvern som faktiskt används. Öppna sedan en ny anslutning och bekräfta utgångsadressen, för en sida som redan var inloggad kan fortfarande använda en socket bunden till den gamla tunneln.
Om DNS fortfarande svarar från det lokala nätverket, jämför tjänstens konfigurerade servrar med resolverlistan. Om standardrutten fortfarande pekar på det fysiska gränssnittet är tjänsten delad tunnel eller inte helt ansluten. Båda är konfigurationsresultat, inte bevis på en trasig klient.
En bytesordning som undviker överraskningar
- Notera den aktuella tjänsten och om en profil hanterar den.
- Koppla från den först när de två tunnlarna inte kan samexistera.
- Anslut målet och vänta på Ansluten, inte Ansluter.
- Kontrollera standardrutten, resolverlistan och en ny utgångsadress.
- Starta om appar som håller långa sessioner.
Behåll den gamla posten tills den nya klarar dessa kontroller, och ge varje post ett eget namn; identiska etiketter gör nästa fel svårare att tillskriva. Apples Mac-hjälp beskriver den inbyggda sidan på Ställa in en VPN-anslutning på Macen, som är referensen att kontrollera innan du redigerar en hanterad konfiguration.
Om valet hoppar tillbaka, behandla det först som policy eller On Demand. Bekräfta vem som äger konfigurationen och om den är inställd på automatisk anslutning, och bestäm sedan om du byter en tjänst eller kämpar mot en profil.