Tjänstordningen i macOS styr inte dina VPN-rutter
Tjänstordningen väljer mellan vanliga gränssnitt. En VPN ligger redan ovanför dem, och de inkluderade rutterna kommer från profilen, inte från den listan.
Något på en webbplats misslyckas, en kollega minns att tjänstordningen finns, och Wi-Fi dras ovanför Ethernet. Ingenting ändras, eftersom listan aldrig har avgjort vart ett VPN-mål tar vägen. Apple ger VPN-anslutningar prioritet framför vanliga och håller dem utanför den här omordningen, så reglaget svarar på en snävare fråga än den som ställs. Felet behöver den valda rutten och resolvern, inte en ny rangordning.
Vad tjänstordningen ändrar, och vad den aldrig rör
Ange tjänstordning finns under Systeminställningar, Nätverk, i Åtgärds-menyn, och den rangordnar vanliga anslutningar när två eller fler är aktiva. Den rangordningen väljer den primära tjänsten, som levererar standardrutten och en del av resolverns beteende. Det är en avgörelse mellan likar, inte en omkopplare för privata mål bakom en tunnel. En bärbar dator med Wi-Fi och en USB-Ethernet-adapter använder den för att svara på en rimlig fråga, och den frågan handlar inte om tunneln.
En VPN-profil bär inkluderade rutter, uteslutna mål och ibland regler per app, och de avgör vad som kommer in i tunneln; ordningsmenyn redigerar dem inte. Därför kan en split-tunnel-profil lämna offentlig trafik utanför medan VPN:en fortfarande ligger över varje fysiskt gränssnitt. Att dra Wi-Fi högst upp gör inte ett privat intervall nåbart och kan inte stoppa ett mål som profilen redan inkluderar. Listan flyttar gränssnitt; profilen flyttar prefix. Apple dokumenterar prioriteten på sin sida om ordning för nätverkstjänster, som är värd att läsa en gång innan du ordnar om något.
Läs rutten som datorn faktiskt valde
Fråga datorn vart en viss adress tar vägen med route get 10.20.4.10, och upprepa det för IPv6 med route -n get -inet6 2001:db8::10. De två familjerna är separata beslut, så en fungerande IPv4-rutt säger ingenting om v6, och ett direkt anslutet subnät eller ett mer specifikt prefix slår ändå den allmänna anslutningsetiketten, vilket är precis varför etiketten fortsätter att vilseleda folk.
Om utdata namnger tunnelgränssnittet har profilen fångat målet och ordningen är irrelevant. Om de namnger det fysiska gränssnittet gjorde profilen inte det, och ingen mängd dragande ändrar prefixtabellen. Båda utdata namnger också källadressen som datorn skulle använda, och det är fältet att citera när du jämför två körningar. Spara utdata innan du ändrar något, eftersom det är det enda beviset du har efteråt.
DNS löser efter namn, inte efter gränssnitt
Resolvers med omfång och domänspecifika resolvers innebär att svaret kan variera per namn i stället för per gränssnitt. scutil --dns skriver ut den resolverkonfiguration som systemet faktiskt använder, inklusive poster med omfång. Tjänstordningen påverkar vilken tjänst som levererar standardresolvern, men ett namnspecifikt omfång kan ändå vinna.
Därför kan en ping till en adress fungera medan värdnamnet misslyckas, eller tvärtom. Läs båda utdata innan du väljer en syndabock.
Ändra profilen och läs sedan båda utdata igen
När en målpolicy måste ändras är ägaren VPN-profilen: inkluderade rutter, uteslutna rutter och alla split-tunnel-regler som leverantören stöder. Att ändra gränssnitt flyttar bara diskussionen. På en Mac som hanteras på distans, spara först det aktuella nätverkstillståndet, eftersom att förlora tunneln på en maskin du inte kan nå är en resa, inte en återställning.
Reproducera felet, läs rutten, läs resolvern, ändra en sak och läs sedan samma två utdata igen. Att blanda flera tjänster och profiler samtidigt lämnar en maskin som ingen kan förklara, även personen som lagade den. Testet är klart när båda utdata stämmer med den ändring du avsåg. Om de fortfarande är oense beskriver profilen och maskinen två olika policyer, och profilen är den som måste ändras.