Tjenesterekkefølgen i macOS styrer ikke VPN-rutene dine

Noe på et nettsted feiler, en kollega kommer på at tjenesterekkefølgen finnes, og Wi-Fi blir dratt over Ethernet. Ingenting forandrer seg, fordi listen aldri har bestemt hvor en VPN-destinasjon ender opp. Apple gir VPN-tilkoblinger forrang foran vanlige og holder dem utenfor denne omrokeringen, så bryteren besvarer et snevrere spørsmål enn det som stilles. Feilen krever den valgte ruten og resolveren, ikke en ny rangering.

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

Angi tjenesterekkefølge finnes under Systeminnstillinger, Nettverk, i Handlings-menyen, og den rangerer vanlige tilkoblinger når to eller flere er aktive. Rangeringen velger den primære tjenesten, som leverer standardruten og deler av resolverens oppførsel. Det er en avgjørelse blant likestilte, ikke en bryter for private destinasjoner bak en tunnel. En bærbar datamaskin med Wi-Fi og en USB-Ethernet-adapter bruker den til å besvare et fornuftig spørsmål, og det spørsmålet handler ikke om tunnelen.

En VPN-profil bærer inkluderte ruter, ekskluderte destinasjoner og av og til regler per program, og disse avgjør hva som kommer inn i tunnelen; rekkefølgemenyen redigerer dem ikke. Derfor kan en splitt-tunnel-profil la offentlig trafikk bli stående utenfor mens VPN-en fortsatt ligger over hvert fysiske grensesnitt. Å dra Wi-Fi øverst gjør ikke et privat område tilgjengelig, og det kan ikke stoppe en destinasjon som profilen allerede omfatter. Listen flytter grensesnitt; profilen flytter prefikser. Apple dokumenterer forrangen på siden om rekkefølge for nettverkstjenester, som er verdt å lese én gang før du omrokerer 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 atskilte 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 nøyaktig grunnen til at etiketten fortsetter å villede folk.

Hvis utdataene navngir tunellgrensesnittet, har profilen fanget destinasjonen, og rekkefølgen er uten betydning. 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

Avgrensa og domenespesifikke resolvere betyr at svaret kan variere per navn i stedet for per grensesnitt. scutil --dns skriver ut resolverkonfigurasjonen systemet faktisk bruker, inkludert avgrensa 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 synder.

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 gjeldende nettverkstilstand først, fordi å miste tunnelen på en maskin du ikke når, er en reise og 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.