De tsjinstfolchoarder fan macOS regelet jo VPN-rûtes net

Der giet wat mis op in website, in kollega betinkt dat tsjinstfolchoarder bestiet, en Wi-Fi wurdt boppe Ethernet sleept. Der feroaret neat, want dy list hat nea besletten wêr't in VPN-bestimming hinne giet. Apple jout VPN-ferbiningen foarrang boppe gewoane en hâldt se bûten dy weroardering, sadat de skeakel in smeller fraach beantwurdet as dy't steld wurdt. De flater hat de keazen rûte en de resolver nedich, net in nije ranglist.

Wat tsjinstfolchoarder feroaret, en wat it nea oanrekket

Set tsjinstfolchoarder stiet ûnder Systeemynstellingen, Netwurk, yn it menu Aksje, en it rangskikt gewoane ferbiningen as twa of mear aktyf binne. Dy rangskikking kiest de primêre tsjinst, dy't de standertrûte en in part fan it resolver-gedrach leveret. It is in beslissing tusken gelikensen, gjin skeakel foar privee bestimmingen efter in tunnel. In laptop mei Wi-Fi en in USB-Ethernet-adapter brûkt it om in ferstannige fraach te beantwurdzjen, en dy fraach giet net oer de tunnel.

In VPN-profyl draacht ynbegrepen rûtes, útsletten bestimmingen en soms regels per applikaasje, en dy beslisse wat de tunnel yn giet; it oardermenu bewurket se net. Dêrom kin in split-tunnelprofyl iepenbier ferkear bûten litte wylst de VPN noch boppe elke fysike interface stiet. Wi-Fi nei boppen slepe kin in privee berik net berikber meitsje en kin in bestimming dy't it profyl al befettet net tsjinhâlde. De list ferpleatst interfaces; it profyl ferpleatst prefiksen. Apple dokumintearret de foarrang op syn side oer netwurktsjinstfolchoarder, dy't ien kear lêzen wurde moat foardat jo eat weroarderje.

Lês de rûte dy't de masine echt keazen hat

Freegje de masine wêr't in bepaald adres hinne giet mei route get 10.20.4.10, en werhelje dat foar IPv6 mei route -n get -inet6 2001:db8::10. De twa famyljes binne aparte beslissingen, dus in wurkjende IPv4-rûte seit neat oer de v6, en in direkt ferbûn subnet of in spesifiker prefiks ferslacht hoe dan ek it algemiene ferbiningsetiket, wat krekt de reden is dat it etiket minsken misliedt.

As de útfier de tunnelinterface neamt, hat it profyl de bestimming pakt en is de oardering net fan belang. As it de fysike interface neamt, die it profyl dat net, en gjin slepe sil de prefikstabel feroarje. Beide útfieren neame ek it boarneadres dat de masine brûke soe, en dat is it fjild dat jo sitearje moatte as jo twa rinnen ferlykje. Bewarje de útfier foardat jo eat feroarje, want it is it iennige bewiis dat jo dêrnei hawwe.

DNS lost op nei namme, net nei interface

Beheinde en domeinspezifike resolvers betsjutte dat it antwurd per namme ferskille kin ynstee fan per interface. scutil --dns prints de resolverkonfiguraasje dy't it systeem echt brûkt, beheinde ynfieringen ynbegrepen. Tsjinstfolchoarder beynfloedet hokker tsjinst de standertresolver leveret, mar in namme-spesifike beheining kin dochs winne.

Dêrom kin in ping nei in adres wurkje wylst de hostnamme faalt, of oarsom. Lês beide útfieren foardat jo in skuldige kieze.

Feroarje it profyl en lês dan beide útfieren opnij

As in bestimmingsbelied feroare wurde moat, is de eigner it VPN-profyl: ynbegrepen rûtes, útsletten rûtes en alle split-tunnelregels dy't de leveransier stipet. Ynterfaces feroarje ferpleatst allinne it debat. Op in op ôfstân beheard Mac bewarje jo earst de hjoeddeistige netwurksteat, want de tunnel ferlieze op in masine dy't jo net berikke kinne is in reis, net in weromsetten.

Reprodusearje de flater, lês de rûte, lês de resolver, feroarje ien ding, en lês dan deselde twa útfieren wer. Ferskate tsjinsten en profylen tagelyk trochinoar helje lit in masine efter dy't nimmen ferklearje kin, ek dejinge dy't it reparearre. De test is dien as beide útfieren oerienkomme mei de feroaring dy't jo bedoelden. As se it noch net iens binne, beskriuwe it profyl en de masine twa ferskillende belieden, en it profyl is dy't feroare wurde moat.