Kio vere ŝanĝiĝas kiam vi ŝaltas konservitajn VPN-agordojn sur macOS
Ŝanĝi konservitan Mac-VPN-on ne estas interŝanĝo de profilo. Vidu kio ŝanĝiĝas en itineroj, DNS kaj akreditiloj, kaj kiel kontroli la tunelon kiun vi efektive ricevis.
Vi malfermas la VPN-liston, elektas la alian konservitan enskribon kaj atendas puran ŝanĝon: novan eliran adreson kaj ĉion alian senŝanĝan. Tiun supozon unue forlasu. Sur macOS konservita VPN estas plena reta servo, ne antaŭagordo, do ŝanĝo de servoj povas samtempe ŝanĝi enitinrigon, DNS kaj aŭtentikigon. La menuobreto montras kiun servon aktivas; ĝi ne diras ĉu la tunelo sube kongruas kun via intenco.
La konservita listo ne estas profil-elektilo
Ĉiu enskribo en Sistemaj Agordoj > Reto estas propra servo, kun propra servila adreso, konto, aŭtentikiga metodo, DNS-serviloj kaj opcioj kiel Sendi la tutan trafikon tra la VPN-konekto. Pli malnovaj eldonoj tenas la saman liston en Sistemaj Agordoj. Du enskriboj povas montri al la sama gastigantnomo kaj tamen konduti malsame, ĉar la protokolo aŭ la klienta etendaĵo decidas kiel la tunelo estas konstruata.
Triapartaj klientoj tenas apartajn listojn. Tunnelblick legas agordojn el sia propra dosierujo, WireGuard tenas sian propran tunel-liston, kaj OpenVPN Connect kaŝas profilojn ene de la aplikaĵo. Iuj registras agordon en la sistemo; aliaj tenas ĉion ene de la aplikaĵo kaj neniam aperas en la enkonstruita listo. Do «ŝalti al la konservita» signifas malsamajn agojn laŭ tio, kiu aplikaĵo posedas la profilon.
scutil --nc list presas la VPN-servojn registritajn en la sistema agordo, kun nomoj en citiloj. Uzu ĝuste tiujn nomojn kiam vi skriptas ŝanĝon, kaj ne supozu ke la listo kovras ĉiun triapartan tunelon.
Kion ŝanĝo vere ŝanĝas
Kvar aferoj moviĝas kune kiam la aktiva servo ŝanĝiĝas. La defaŭlta itinero sekvas la novan tunelon se tiu servo sendas la tutan trafikon; la solvila listo ŝanĝiĝas al la DNS-serviloj kiujn la servo specifas; novaj konektoj prenas la novan tunel-adreson kiel sian fonton; kaj la akreditiloj en uzo apartenas al la nova servo. Indiĝena agordo kaj aplikaĵa profilo ne estas interŝanĝeblaj, eĉ kiam ambaŭ finiĝas ĉe la sama enirejo.
| 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 |
La DNS-parto trompas homojn. macOS subtenas ordon de solviloj, kaj scutil --dns montras kiuj solviloj estas uzataj kaj sur kiu interfaco. VPN-servo sen agorditaj DNS-serviloj povas lasi la Wi-Fi-solvilon respondi, do vi ricevas novan publikan adreson kun la malnova DNS-konduto kaj konkludas ke la ŝanĝo duone funkciis.
Kial la malnova agordo daŭre revenas
Se vi malkonektas kaj la sama servo reorientiĝas momenton poste, unue rigardu On Demand. Regulo pri konekto laŭ postulo povas revivigi servon kiam aplikaĵo solvas kongruan domajnon, kaj administra profilo povas devigi la saman regulon. Forigi la enskribon malofte riparas tion: profilo-instalita agordo kutime revenas ĉe la sekva profil-ĝisdatigo, kaj permana povas lasi sian pasvorton en Keychain dum la servo jam foras.
Startigi duan servon ne ĉiam haltigas la unuan. Laŭ la kliento kaj protokolo vi povas fini kun du tuneloj kaj du aroj da itineroj, kaj servo-ordo plus itinera specifeco decidas kiu portas trafikon, ne la ikono kiun vi laste alklakis. Kontrolu la interfacojn antaŭ ol supozi ke ŝanĝo okazis.
Kontrolu la tunelon, ne la markon
Trairu la propran vidmanieron de la sistemo antaŭ ol tuŝi agordojn.scutil --nc status "Name" raportas kion la sistemo kredas;ifconfig montras ĉu interfaco utun havas adreson;netstat -rn -f inet montras kien celas la defaŭlta itinero;scutil --dns montras la solvilon fakte uzatan. Poste malfermu freŝan konekton kaj konfirmu la eliran adreson, ĉar paĝo jam ensalutinta eble ankoraŭ uzas poŝon ligitan al la malnova tunelo.
Se DNS ankoraŭ respondas el la loka reto, komparu la agorditajn servilojn de la servo kun la solvila listo. Se la defaŭlta itinero ankoraŭ montras al la fizika interfaco, la servo estas split-tunelo aŭ ne plene konektita. Ambaŭ estas agordaj rezultoj, ne pruvo de rompita kliento.
Ŝanĝa ordo kiu evitas surprizojn
- Notu la nunan servon kaj ĉu profilo administras ĝin.
- Unue malkonektu ĝin kiam la du tuneloj ne povas kunekzisti.
- Konektu la celon kaj atendu Konektita, ne Konektanta.
- Kontrolu la defaŭltan itineron, la solvilan liston kaj freŝan eliran adreson.
- Restartigu aplikaĵojn kiuj tenas longdaŭrajn seancojn.
Konservu la malnovan enskribon ĝis la nova trapasos tiujn kontrolojn, kaj donu al ĉiu enskribo apartan nomon; identaj etikedoj malfaciligas atribui la sekvan fiaskon. La Mac-helpo de Apple priskribas la indiĝenan flankon ĉe Agordi VPN-konekton sur Mac, kiu estas la referenco kontrolenda antaŭ ol redakti administritan agordon.
Se la elekto resaltas, traktu ĝin unue kiel politikon aŭ On Demand. Konfirmu kiu posedas la agordon kaj ĉu ĝi estas agordita por aŭtomata konekto, poste decidu ĉu vi ŝanĝas servon aŭ luktas kontraŭ profilo.