macOS-i teenuste järjekord ei juhi teie VPN-marsruute

Midagi veebisaidil ebaõnnestub, kolleeg mäletab, et teenuste järjekord on olemas, ja Wi-Fi lohistatakse Etherneti kohale. Midagi ei muutu, sest see loend ei ole kunagi otsustanud, kuhu VPN-i sihtkoht läheb. Apple annab VPN-ühendustele tavalistest prioriteedi ja hoiab neid sellest ümberjärjestamisest väljas, nii et lüliti vastab kitsamale küsimusele kui see, mis esitati. Rike vajab valitud marsruuti ja resolverit, mitte uut pingerea.

Mida teenuste järjekord muudab ja mida see kunagi ei puuduta

Valik „Määra teenuste järjekord” asub jaotises Süsteemiseaded > Võrk, menüüs Toiming, ja see järjestab tavalisi ühendusi, kui kaks või enam on aktiivsed. See järjestus valib esmase teenuse, mis annab vaikemarsruudi ja osa resolveri käitumisest. See on võrdsete vaheline otsus, mitte lüliti tunnelitaguste privaatsete sihtkohtade jaoks. Sülearvuti, millel on Wi-Fi ja USB-Etherneti adapter, kasutab seda mõistliku küsimuse vastamiseks, ja see küsimus ei puuduta tunnelit.

VPN-profiil kannab kaasatud marsruute, välistatud sihtkohti ja mõnikord rakendusepõhiseid reegleid, ja need otsustavad, mis tunnelisse läheb; järjestusmenüü neid ei muuda. Seetõttu võib split-tunnel-profiil jätta avaliku liikluse välja, samal ajal kui VPN on endiselt igast füüsilisest liidesest eespool. Wi-Fi üleslohistamine ei muuda privaatset vahemikku kättesaadavaks ega peata sihtkohta, mille profiil juba sisaldab. Loend liigutab liideseid; profiil liigutab prefikseid. Apple dokumenteerib prioriteedi oma võrguteenuste järjekorra lehel, mida tasub üks kord lugeda enne, kui midagi ümber korraldate.

Lugege marsruuti, mille masin tegelikult valis

Küsige masinalt, kuhu konkreetne aadress läheb, käsuga route get 10.20.4.10, seejärel korrake seda IPv6 jaoks käsuga route -n get -inet6 2001:db8::10. Need kaks perekonda on eraldi otsused, nii et toimiv IPv4-marsruut ei ütle v6 kohta midagi, ja otse ühendatud alamvõrk või täpsem prefiks võidab üldise ühendussildi igal juhul, mis ongi põhjus, miks silt inimesi edasi eksitab.

Kui väljund nimetab tunneliliidest, haaras profiil sihtkoha ja järjestus on tähtsusetu. Kui see nimetab füüsilist liidest, ei teinud profiil seda, ja ükski lohistamine ei muuda prefiksite tabelit. Mõlemad väljundid nimetavad ka lähteaadressi, mida masin kasutaks, ja see on väli, mida kahe käivituse võrdlemisel tsiteerida. Salvestage väljund enne, kui midagi muudate, sest see on ainus tõend, mis teil hiljem on.

DNS lahendab nime, mitte liidese järgi

Ulatuslikud ja domeenipõhised resolverid tähendavad, et vastus võib erineda pigem nime kui liidese kaupa. scutil --dns prindib resolveri konfiguratsiooni, mida süsteem tegelikult kasutab, sealhulgas ulatuslikud kirjed. Teenuste järjekord mõjutab seda, milline teenus annab vaikeresolveri, kuid nimepõhine ulatus võib ikkagi võita.

Seetõttu võib ping aadressile töötada, samal ajal kui hostinimi ebaõnnestub, või vastupidi. Lugege mõlemat väljundit enne, kui süüdlast valite.

Muutke profiili ja lugege seejärel mõlemad väljundid uuesti

Kui sihtkohapoliitikat tuleb muuta, on omanik VPN-profiil: kaasatud marsruudid, välistatud marsruudid ja kõik split-tunneli reeglid, mida tarnija toetab. Liideste muutmine ainult liigutab vaidlust. Kaugjuhitaval Macil salvestage esmalt praegune võrguseisund, sest tunnelist ilmajäämine masinas, kuhu te ei pääse, on reis, mitte tagasipööramine.

Reprodutseerige rike, lugege marsruuti, lugege resolverit, muutke ühte asja ja lugege seejärel uuesti samu kahte väljundit. Mitme teenuse ja profiili korraga segamine jätab masina, mida keegi seletada ei oska, sealhulgas see, kes selle parandas. Test on lõppenud, kui mõlemad väljundid on kooskõlas muudatusega, mida kavatsesite. Kui need ikka lahknevad, kirjeldavad profiil ja masin kahte erinevat poliitikat ja profiil on see, mida tuleb muuta.