La servo-ordo de macOS ne regas viajn VPN-itinerojn

Io en retejo malsukcesas, kolego memoras, ke servo-ordo ekzistas, kaj Wi-Fi estas trenita super Ethernet. Nenio ŝanĝiĝas, ĉar tiu listo neniam decidis, kien iras VPN-celo. Apple donas al VPN-konektoj prioritaton super ordinaraj kaj tenas ilin ekster tiu reordigo, do la ŝaltilo respondas pli mallarĝan demandon ol tiu, kiun oni starigas. La malsukceso bezonas la elektitan itineron kaj la solvilon, ne novan rangigon.

Kion servo-ordo ŝanĝas, kaj kion ĝi neniam tuŝas

«Agordi servo-ordon» troviĝas sub Sistemaj agordoj, Reto, en la Agoj-menuo, kaj ĝi rangigas ordinarajn konektojn kiam du aŭ pli estas aktivaj. Tiu rangigo elektas la ĉefan servon, kiu provizas la defaŭltan itineron kaj parton de la solvila konduto. Ĝi estas decido inter egaluloj, ne ŝaltilo por privataj celoj malantaŭ tunelo. Tekomputilo kun Wi-Fi kaj USB-Ethernet-adaptilo uzas ĝin por respondi al prudenta demando, kaj tiu demando ne temas pri la tunelo.

VPN-profilo portas inkluzivitajn itinerojn, ekskluzivitajn celojn kaj foje regulojn laŭ aplikaĵo, kaj tiuj decidas, kio eniras la tunelon; la ordiga menuo ne redaktas ilin. Tial disig-tunela profilo povas lasi publikan trafikon ekstere, dum la VPN ankoraŭ superas ĉiun fizikan interfacon. Treni Wi-Fi al la supro ne povas igi privatan gamon atingebla, kaj ĝi ne povas haltigi celon, kiun la profilo jam inkluzivas. La listo movas interfacojn; la profilo movas prefiksojn. Apple dokumentas la prioritaton sur sia paĝo pri ret-servo-ordo, kiun indas legi unufoje antaŭ ol vi reordigos ion ajn.

Legu la itineron, kiun la maŝino efektive elektis

Demandu la maŝinon, kien iras specifa adreso, per route get 10.20.4.10, poste ripetu tion por IPv6 per route -n get -inet6 2001:db8::10. La du familioj estas apartaj decidoj, do funkcianta IPv4-itinero diras nenion pri la v6, kaj rekte konektita subreto aŭ pli specifa prefikso superas la ĝeneralan konekto-etikedon ĉiuokaze, kio estas ĝuste la kialo, ke la etikedo daŭre misgvidas homojn.

Se la eligo nomas la tunelan interfacon, la profilo kaptis la celon kaj la ordigo estas sensignifa. Se ĝi nomas la fizikan interfacon, la profilo ne faris tion, kaj neniu kvanto da trenado ŝanĝos la prefikso-tabelon. Ambaŭ eligoj ankaŭ nomas la fontadreson, kiun la maŝino uzus, kaj tio estas la kampo, kiun vi citu kiam vi komparas du ruladojn. Konservu la eligon antaŭ ol ŝanĝi ion, ĉar ĝi estas la sola pruvo, kiun vi havos poste.

DNS solvas laŭ nomo, ne laŭ interfaco

Limigitaj kaj domajnaj solviloj signifas, ke la respondo povas malsami laŭ nomo anstataŭ laŭ interfaco. scutil --dns presas la solvilan agordon, kiun la sistemo efektive uzas, inkluzive de limigitaj eroj. Servo-ordo influas, kiu servo provizas la defaŭltan solvilon, sed nom-specifa limigo povas venki malgraŭe.

Tial ping al adreso povas funkcii dum la gastiga nomo malsukcesas, aŭ inverse. Legu ambaŭ eligojn antaŭ ol vi elektos kulpulon.

Ŝanĝu la profilon, poste relegu ambaŭ eligojn

Kiam cela politiko devas ŝanĝiĝi, la posedanto estas la VPN-profilo: inkluzivitaj itineroj, ekskluzivitaj itineroj kaj ĉiuj disig-tunelaj reguloj, kiujn la vendanto subtenas. Ŝanĝi interfacojn anstataŭe nur movas la argumenton. Sur malproksime administrata Mac, unue konservu la nunan retan staton, ĉar perdi la tunelon sur maŝino, kiun vi ne povas atingi, estas vojaĝo, ne restarigo.

Reproduktu la malsukceson, legu la itineron, legu la solvilon, ŝanĝu unu aferon, poste relegu la samajn du eligojn. Miksi plurajn servojn kaj profilojn samtempe lasas maŝinon, kiun neniu povas klarigi, inkluzive de la persono, kiu ĝin riparis. La testo finiĝas, kiam ambaŭ eligoj kongruas kun la ŝanĝo, kiun vi intencis. Se ili ankoraŭ malkongruas, la profilo kaj la maŝino priskribas du malsamajn politikojn, kaj la profilo estas tiu, kiun oni devas ŝanĝi.