macOS pakalpojumu secība nevada jūsu VPN maršrutus
Pakalpojumu secība izvēlas starp parastajām saskarnēm. VPN jau ir augstāk par tām, un tā iekļautie maršruti nāk no profila, nevis no šī saraksta.
Kaut kas vietnē neizdodas, kolēģis atceras, ka pastāv pakalpojumu secība, un Wi-Fi tiek pārvilkts virs Ethernet. Nekas nemainās, jo šis saraksts nekad nav noteicis, kur dodas VPN galamērķis. Apple piešķir VPN savienojumiem prioritāti pār parastajiem un tur tos ārpus šīs pārkārtošanas, tāpēc slēdzis atbild uz šaurāku jautājumu nekā uzdotais. Kļūmei vajag izvēlēto maršrutu un resolver, nevis jaunu ranžējumu.
Ko pakalpojumu secība maina un ko tā nekad neaiztiek
„Iestatīt pakalpojumu secību” atrodas Sistēmas iestatījumos, Tīklā, darbību izvēlnē, un tā sarindo parastos savienojumus, kad aktīvi ir divi vai vairāk. Šī sarindošana izvēlas primāro pakalpojumu, kas nodrošina noklusējuma maršrutu un daļu no resolver uzvedības. Tas ir izšķirošs lēmums starp vienlīdzīgiem, nevis slēdzis privātiem galamērķiem aiz tuneļa. Portatīvais dators ar Wi-Fi un USB Ethernet adapteri to izmanto, lai atbildētu uz saprātīgu jautājumu, un šis jautājums nav par tuneli.
VPN profils nes iekļautos maršrutus, izslēgtos galamērķus un dažkārt noteikumus pa lietotnēm, un tie nosaka, kas nonāk tunelī; kārtošanas izvēlne tos nerediģē. Tāpēc split-tunnel profils var atstāt publisko satiksmi ārpusē, kamēr VPN joprojām pārspēj katru fizisko saskarni. Wi-Fi pārvilkšana augšup nepadara privātu diapazonu sasniedzamu un nevar apturēt galamērķi, ko profils jau ietver. Saraksts pārvieto saskarnes; profils pārvieto prefiksus. Apple dokumentē prioritāti savā tīkla pakalpojumu secības lapā, ko ir vērts vienreiz izlasīt pirms kaut kā pārkārtošanas.
Izlasiet maršrutu, ko mašīna patiešām izvēlējās
Pajautājiet mašīnai, kur dodas konkrēta adrese, ar route get 10.20.4.10, tad atkārtojiet to IPv6 ar route -n get -inet6 2001:db8::10. Abas saimes ir atsevišķi lēmumi, tāpēc strādājošs IPv4 maršruts neko neizsaka par v6, un tieši pieslēgts apakštīkls vai konkrētāks prefikss jebkurā gadījumā pārspēj vispārīgo savienojuma birku, un tas ir tieši iemesls, kāpēc birka turpina maldināt cilvēkus.
Ja izvade nosauc tuneļa saskarni, profils ir notvēris galamērķi un kārtošanai nav nozīmes. Ja tā nosauc fizisko saskarni, profils to nav izdarījis, un nekāda vilkšana nemainīs prefiksu tabulu. Abas izvades nosauc arī avota adresi, ko mašīna izmantotu, un tas ir lauks, kas jācitē, salīdzinot divas palaišanas. Saglabājiet izvadi pirms kaut kā maiņas, jo tā ir vienīgā liecība, kas jums būs pēc tam.
DNS atrisina pēc nosaukuma, nevis pēc saskarnes
Ierobežoti un domēnam raksturīgi resolver nozīmē, ka atbilde var atšķirties pēc nosaukuma, nevis pēc saskarnes. scutil --dns izdrukā resolver konfigurāciju, ko sistēma faktiski izmanto, tostarp ierobežotos ierakstus. Pakalpojumu secība ietekmē to, kurš pakalpojums nodrošina noklusējuma resolver, bet nosaukumam raksturīga joma tomēr var uzvarēt.
Tāpēc ping uz adresi var strādāt, kamēr resursdatora nosaukums neizdodas, vai otrādi. Izlasiet abas izvades pirms vainīgā izvēles.
Mainiet profilu, pēc tam vēlreiz izlasiet abas izvades
Kad galamērķa politika ir jāmaina, īpašnieks ir VPN profils: iekļautie maršruti, izslēgtie maršruti un visi split-tunnel noteikumi, ko atbalsta piegādātājs. Saskarņu maiņa tikai pārvieto strīdu. Uz attālināti pārvaldīta Mac vispirms saglabājiet pašreizējo tīkla stāvokli, jo tuneļa zaudēšana mašīnā, kurai nevarat piekļūt, ir brauciens, nevis atritināšana.
Reproducējiet kļūmi, izlasiet maršrutu, izlasiet resolver, nomainiet vienu lietu, pēc tam vēlreiz izlasiet tās pašas divas izvades. Vairāku pakalpojumu un profilu sajaukšana uzreiz atstāj mašīnu, ko neviens nevar izskaidrot, arī tas, kurš to salaboja. Tests ir pabeigts, kad abas izvades saskan ar iecerēto izmaiņu. Ja tās joprojām atšķiras, profils un mašīna apraksta divas dažādas politikas, un mainīt ir jāmaina profilu.