macOS-dienestrækkefølge styrer ikke dine VPN-ruter

Noget på et websted fejler, en kollega husker, at dienestrækkefølgen findes, og Wi-Fi bliver trukket op over Ethernet. Intet ændrer sig, fordi listen aldrig har afgjort, hvor en VPN-destination ender. Apple giver VPN-forbindelser forrang over almindelige og holder dem uden for den omrokering, så kontakten svarer på et snævrere spørgsmål end det, der bliver stillet. Fejlen kræver den valgte rute og resolveren, ikke en ny rangordning.

Hvad dienestrækkefølgen ændrer, og hvad den aldrig rører

Indstil dienestrækkefølge findes under Systemindstillinger, Netværk, i Handlingsmenuen, og den rangerer almindelige forbindelser, når to eller flere er aktive. Rangeringen vælger den primære tjeneste, som leverer standardruten og en del af resolverens adfærd. Det er en afgørelse mellem ligestillede, ikke en kontakt for private destinationer bag en tunnel. En bærbar med Wi-Fi og en USB-Ethernet-adapter bruger den til at besvare et fornuftigt spørgsmål, og det spørgsmål handler ikke om tunnelen.

En VPN-profil bærer medfølgende ruter, udelukkede destinationer og nogle gange regler pr. program, og de afgør, hvad der kommer ind i tunnelen; sorteringsmenuen redigerer dem ikke. Derfor kan en split-tunnel-profil lade offentlig trafik blive udenfor, mens VPN'en stadig ligger over hver fysisk grænseflade. At trække Wi-Fi til toppen kan ikke gøre et privat område tilgængeligt, og det kan ikke stoppe en destination, som profilen allerede omfatter. Listen flytter grænseflader; profilen flytter præfikser. Apple dokumenterer forrangen på sin side om netværksdienestrækkefølge, som er værd at læse én gang, før du omarrangerer noget.

Læs den rute, maskinen faktisk valgte

Spørg maskinen, hvor en bestemt adresse fører hen, med route get 10.20.4.10, og gentag det for IPv6 med route -n get -inet6 2001:db8::10. De to familier er separate beslutninger, så en fungerende IPv4-rute siger intet om v6-versionen, og et direkte tilsluttet undernet eller et mere specifikt præfiks slår under alle omstændigheder det generelle forbindelsesmærke, hvilket netop er grunden til, at mærket fortsat vildleder folk.

Hvis outputtet nævner tunnelgrænsefladen, har profilen opfanget destinationen, og sorteringen er uden betydning. Hvis det nævner den fysiske grænseflade, gjorde profilen det ikke, og ingen mængde træk vil ændre præfixtabellen. Begge output nævner også kildeadressen, som maskinen ville bruge, og det er det felt, du skal citere, når du sammenligner to kørsler. Gem outputtet, før du ændrer noget, fordi det er det eneste bevis, du har bagefter.

DNS opløser efter navn, ikke efter grænseflade

Scopede og domænespecifikke resolvere betyder, at svaret kan variere pr. navn i stedet for pr. grænseflade. scutil --dns udskriver den resolverkonfiguration, systemet faktisk bruger, inklusive scopede poster. Dienestrækkefølgen påvirker, hvilken tjeneste der leverer standardresolveren, men en navnespecifik scope kan vinde alligevel.

Derfor kan en ping til en adresse virke, mens værtsnavnet fejler, eller omvendt. Læs begge output, før du udpeger en skyldig.

Ændr profilen, og læs derefter begge output igen

Når en destinationspolitik skal ændres, er ejeren VPN-profilen: medfølgende ruter, udelukkede ruter og de split-tunnel-regler, som leverandøren understøtter. At ændre grænseflader flytter bare diskussionen. På en Mac, der administreres eksternt, skal du gemme den aktuelle netværkstilstand først, fordi at miste tunnelen på en maskine, du ikke kan nå, er en rejse og ikke en tilbagerulning.

Genskab fejlen, læs ruten, læs resolveren, ændr én ting, og læs derefter de samme to output igen. At blande flere tjenester og profiler på én gang efterlader en maskine, som ingen kan forklare, heller ikke den, der rettede den. Testen er færdig, når begge output stemmer med den ændring, du havde til hensigt. Hvis de stadig er uenige, beskriver profilen og maskinen to forskellige politikker, og det er profilen, der skal ændres.