Tjenesterekkefølgen i macOS styrer ikke VPN-rutene dine

Noe på et nettsted feiler, en kollega husker at tjenesterekkefølgen finnes, og Wi-Fi dras over Ethernet. Ingenting endres, fordi listen aldri har bestemt hvor en VPN-destinasjon går. Apple gir VPN-tilkoblinger prioritet over vanlige og holder dem utenfor denne omorganiseringen, så bryteren svarer på et smalere spørsmål enn det som stilles. Feilen trenger den valgte ruten og resolveren, ikke en ny rangering.

Hva tjenesterekkefølgen endrer, og hva den aldri berører

Angi tjenesterekkefølge ligger under Systeminnstillinger, Nettverk, i Handlings-menyen, og den rangerer vanlige tilkoblinger når to eller flere er aktive. Den rangeringen velger den primære tjenesten, som gir standardruten og en del av resolverens oppførsel. Det er en avgjørelse mellom likeverdige, ikke en bryter for private destinasjoner bak en tunnel. En bærbar PC med Wi-Fi og en USB-Ethernet-adapter bruker den til å svare på et fornuftig spørsmål, og det spørsmålet handler ikke om tunnelen.

En VPN-profil bærer inkluderte ruter, ekskluderte destinasjoner og noen ganger regler per app, og de avgjør hva som kommer inn i tunnelen; rekkefølgemenyen redigerer dem ikke. Derfor kan en splitt-tunnel-profil la offentlig trafikk bli utenfor mens VPN-en fortsatt ligger over hvert fysiske grensesnitt. Å dra Wi-Fi til toppen gjør ikke et privat område tilgjengelig, og det kan ikke stoppe en destinasjon som profilen allerede inkluderer. Listen flytter grensesnitt; profilen flytter prefikser. Apple dokumenterer prioriteten på siden om rekkefølge for nettverkstjenester, som er verdt å lese én gang før du omorganiserer noe.

Les ruten maskinen faktisk valgte

Spør maskinen hvor en bestemt adresse går med route get 10.20.4.10, og gjenta det for IPv6 med route -n get -inet6 2001:db8::10. De to familiene er separate beslutninger, så en fungerende IPv4-rute sier ingenting om v6, og et direkte tilkoblet subnett eller et mer spesifikt prefiks slår uansett den generelle tilkoblingsetiketten, som er nettopp grunnen til at etiketten fortsetter å villede folk.

Hvis utdataene navngir tunellgrensesnittet, har profilen fanget destinasjonen, og rekkefølgen er irrelevant. Hvis de navngir det fysiske grensesnittet, gjorde profilen det ikke, og ingen mengde draing endrer prefikstabellen. Begge utdataene navngir også kildeadressen maskinen ville brukt, og det er feltet du bør sitere når du sammenligner to kjøringer. Lagre utdataene før du endrer noe, fordi det er det eneste beviset du har etterpå.

DNS løser etter navn, ikke etter grensesnitt

Begrensede og domenespesifikke resolvere betyr at svaret kan variere per navn i stedet for per grensesnitt. scutil --dns skriver ut resolverkonfigurasjonen systemet faktisk bruker, inkludert begrensede oppføringer. Tjenesterekkefølgen påvirker hvilken tjeneste som leverer standardresolveren, men et navnespesifikt omfang kan likevel vinne.

Derfor kan en ping til en adresse fungere mens vertsnavnet feiler, eller omvendt. Les begge utdataene før du velger en syndebukk.

Endre profilen, og les deretter begge utdataene på nytt

Når en destinasjonspolicy må endres, er eieren VPN-profilen: inkluderte ruter, ekskluderte ruter og alle splitt-tunnel-regler leverandøren støtter. Å endre grensesnitt flytter bare diskusjonen. På en Mac som administreres eksternt, lagre den gjeldende nettverkstilstanden først, fordi å miste tunnelen på en maskin du ikke når er en reise, ikke en tilbakerulling.

Reproduser feilen, les ruten, les resolveren, endre én ting, og les deretter de samme to utdataene igjen. Å blande flere tjenester og profiler samtidig etterlater en maskin ingen kan forklare, også personen som reparerte den. Testen er ferdig når begge utdataene stemmer med endringen du mente. Hvis de fortsatt er uenige, beskriver profilen og maskinen to forskjellige policyer, og profilen er den som må endres.