Tenesterekkjefølgja i macOS styrer ikkje VPN-rutene dine

Noko på ein nettstad feilar, ein kollega hugsar at tenesterekkjefølgja finst, og Wi-Fi vert drege over Ethernet. Ingenting endrar seg, fordi lista aldri har avgjort kvar ein VPN-destinasjon går. Apple gir VPN-tilkoplingar prioritet over vanlege og held dei utanfor denne omorganiseringa, så brytaren svarar på eit smalare spørsmål enn det som vert stilt. Feilen treng den valde ruta og resolveren, ikkje ei ny rangering.

Kva tenesterekkjefølgja endrar, og kva ho aldri rører

Angi tenesterekkjefølgje ligg under Systeminnstillingar, Nettverk, i Handlings-menyen, og ho rangerer vanlege tilkoplingar når to eller fleire er aktive. Den rangeringa vel den primære tenesta, som gir standardruta og ein del av resolveren si åtferd. Det er ei avgjerd mellom likeverdige, ikkje ein brytar for private destinasjonar bak ein tunnel. Ein berbar PC med Wi-Fi og ein USB-Ethernet-adapter brukar ho til å svare på eit fornuftig spørsmål, og det spørsmålet handlar ikkje om tunnelen.

Ein VPN-profil ber inkluderte ruter, ekskluderte destinasjonar og stundom reglar per app, og dei avgjer kva som kjem inn i tunnelen; rekkjefølgjemenyen redigerer dei ikkje. Difor kan ein splitt-tunnel-profil la offentleg trafikk bli utanfor medan VPN-en framleis ligg over kvart fysiske grensesnitt. Å dra Wi-Fi til toppen gjer ikkje eit privat område tilgjengeleg, og det kan ikkje stoppe ein destinasjon som profilen allereie inkluderer. Lista flyttar grensesnitt; profilen flyttar prefiks. Apple dokumenterer prioriteren på sida om rekkjefølgje for nettverkstenester, som er verdt å lese éin gong før du omorganiserer noko.

Les ruta maskinen faktisk valde

Spør maskinen kvar ein bestemd adresse går med route get 10.20.4.10, og gjer det same for IPv6 med route -n get -inet6 2001:db8::10. Dei to familiane er separate avgjerder, så ei fungerande IPv4-rute seier ingenting om v6, og eit direkte tilkopla subnett eller eit meir spesifikt prefiks slår uansett den generelle tilkoplinga-etiketten, som er nettopp grunnen til at etiketten held fram med å villede folk.

Viss utdataene namngir tunellgrensesnittet, har profilen fanga destinasjonen, og rekkjefølgja er irrelevant. Viss dei namngir det fysiske grensesnittet, gjorde profilen det ikkje, og inga mengd draging endrar prefikstabellen. Båe utdataene namngir òg kjeldeadressa maskinen ville bruke, og det er feltet du bør sitere når du samanliknar to køyringar. Lagre utdataene før du endrar noko, fordi det er det einaste beviset du har etterpå.

DNS løyser etter namn, ikkje etter grensesnitt

Avgrensa og domenespesifikke resolverar tyder at svaret kan variere per namn i staden for per grensesnitt. scutil --dns skriv ut resolverkonfigurasjonen systemet faktisk brukar, inkludert avgrensa oppføringar. Tenesterekkjefølgja påverkar kva teneste som leverer standardresolveren, men eit namnspefikt omfang kan likevel vinne.

Difor kan ein ping til ei adresse fungere medan vertsnamnet feilar, eller omvendt. Les båe utdataene før du vel ein syndebukk.

Endre profilen, og les deretter båe utdataene på nytt

Når ein destinasjonspolicy må endrast, er eigaren VPN-profilen: inkluderte ruter, ekskluderte ruter og alle splitt-tunnel-reglar leverandøren støttar. Å endre grensesnitt flyttar berre diskusjonen. På ein Mac som vert administrert eksternt, lagre den gjeldande nettverkstilstanden først, fordi å miste tunnelen på ein maskin du ikkje når er ei reise, ikkje ei tilbakerulling.

Reproduser feilen, les ruta, les resolveren, endre éin ting, og les deretter dei same to utdataene igjen. Å blande fleire tenester og profilar samstundes lèt att ein maskin ingen kan forklare, også personen som reparerte han. Testen er ferdig når båe utdataene stemmer med endringa du meinte. Viss dei framleis er usamde, skildrar profilen og maskinen to ulike policyar, og profilen er den som må endrast.