Diensvolgorde op macOS beheer nie jou VPN-roetes nie

Iets op ’n webwerf faal, ’n kollega onthou dat diensvolgorde bestaan, en Wi-Fi word bo Ethernet gesleep. Niks verander nie, want daardie lys het nooit besluit waar ’n VPN-bestemming heen gaan nie. Apple gee VPN-verbindings voorkeur bo gewone verbindings en hou hulle buite daardie herrangskikking, so die skakelaar antwoord op ’n smaller vraag as die een wat gevra word. Die fout het die gekose roete en die oplosser nodig, nie ’n nuwe rangorde nie.

Wat diensvolgorde verander, en wat dit nooit raak nie

Stel Diensvolgorde leef onder Stelselinstellings, Netwerk, in die Aksie-kieslys, en dit rangskik gewone verbindings wanneer twee of meer aktief is. Daardie rangorde kies die primêre diens, wat die verstekroete en deel van die oplosser se gedrag lewer. Dit is ’n gelykstelling tussen eweknieë, nie ’n skakelaar vir private bestemmings agter ’n tonnel nie. ’n Skootrekenaar met Wi-Fi en ’n USB-Ethernet-adapter gebruik dit om ’n sinvolle vraag te antwoord, en daardie vraag gaan nie oor die tonnel nie.

’n VPN-profiel dra ingeslote roetes, uitgeslote bestemmings en soms reëls per toepassing, en dit bepaal wat die tonnel binnegaan; die rangskikkingskieslys wysig dit nie. Daarom kan ’n split-tonnel-profiel publieke verkeer buite laat terwyl die VPN steeds elke fisiese koppelvlak oortref. Om Wi-Fi boontoe te sleep kan nie ’n private reeks bereikbaar maak nie, en dit kan nie ’n bestemming keer wat die profiel reeds insluit nie. Die lys skuif koppelvlakke; die profiel skuif prefikse. Apple dokumenteer die prioriteit op sy bladsy oor netwerkdiensvolgorde, wat die moeite werd is om een keer te lees voordat jy enigiets herrangskik.

Lees die roete wat die masjien werklik gekies het

Vra die masjien waar ’n spesifieke adres heen gaan met route get 10.20.4.10, en herhaal dit vir IPv6 met route -n get -inet6 2001:db8::10. Die twee families is aparte besluite, so ’n werkende IPv4-pad sê niks oor die v6-een nie, en ’n direk gekoppelde subnet of ’n meer spesifieke prefiks klop in elk geval die algemene verbinding-etiket, wat juis is waarom die etiket mense aanhou mislei.

As die uitset die tonnelkoppelvlak noem, het die profiel die bestemming vasgevang en is die rangorde irrelevant. As dit die fisiese koppelvlak noem, het die profiel dit nie gedoen nie, en geen hoeveelheid sleep sal die prefikstabel verander nie. Albei uitsette noem ook die bronadres wat die masjien sou gebruik, en dit is die veld om aan te haal wanneer jy twee lopies vergelyk. Stoor die uitset voordat jy iets verander, want dit is die enigste bewys wat jy daarna sal hê.

DNS los op volgens naam, nie volgens koppelvlak nie

Omvang- en domeinspesifieke oplossers beteken die antwoord kan per naam verskil eerder as per koppelvlak. scutil --dns druk die oplosserkonfigurasie wat die stelsel werklik gebruik, insluitend omvang-inskrywings. Diensvolgorde beïnvloed watter diens die verstekoplosser lewer, maar ’n naamspesifieke omvang kan in elk geval wen.

Daarom kan ’n ping na ’n adres werk terwyl die gasheernaam faal, of omgekeerd. Lees albei uitsette voordat jy ’n skuldige kies.

Verander die profiel, en lees dan albei uitsette weer

Wanneer ’n bestemmingsbeleid moet verander, is die eienaar die VPN-profiel: ingeslote roetes, uitgeslote roetes en watter split-tonnel-reëls die verskaffer ook al ondersteun. Om eerder koppelvlakke te verander skuif net die argument. Op ’n Mac wat op afstand bestuur word, stoor eers die huidige netwerktoestand, want om die tonnel op ’n masjien te verloor wat jy nie kan bereik nie, is ’n reis eerder as ’n terugrol.

Reproduseer die fout, lees die roete, lees die oplosser, verander een ding, en lees dan weer dieselfde twee uitsette. Om verskeie dienste en profiele gelyk te skommel, laat ’n masjien agter wat niemand kan verduidelik nie, insluitend die persoon wat dit reggemaak het. Die toets is klaar wanneer albei uitsette saamstem met die verandering wat jy bedoel het. As hulle steeds verskil, beskryf die profiel en die masjien twee verskillende beleide, en die profiel is die een wat verander moet word.