Ordinea serviciilor din macOS nu controlează rutele VPN

Ceva pe un site eșuează, un coleg își amintește că există ordinea serviciilor, iar Wi-Fi este tras deasupra Ethernet. Nimic nu se schimbă, pentru că acea listă nu a decis niciodată unde merge o destinație VPN. Apple acordă prioritate conexiunilor VPN față de cele obișnuite și le ține în afara acestei reordonări, așa că comutatorul răspunde la o întrebare mai îngustă decât cea pusă. Defecțiunea are nevoie de ruta selectată și de resolver, nu de o nouă ierarhie.

Ce schimbă ordinea serviciilor și ce nu atinge niciodată

„Setarea ordinii serviciilor” se află în Setări sistem, Rețea, în meniul Acțiune, și ordonează conexiunile obișnuite când două sau mai multe sunt active. Acea ordonare alege serviciul principal, care furnizează ruta implicită și o parte din comportamentul resolverului. Este o departajare între egali, nu un comutator pentru destinații private din spatele unui tunel. Un laptop cu Wi-Fi și un adaptor Ethernet USB o folosește pentru a răspunde la o întrebare rezonabilă, iar acea întrebare nu este despre tunel.

Un profil VPN poartă rute incluse, destinații excluse și uneori reguli pe aplicație, iar acestea decid ce intră în tunel; meniul de ordonare nu le editează. De aceea un profil cu tunel divizat poate lăsa traficul public afară în timp ce VPN-ul rămâne deasupra fiecărei interfețe fizice. Trasarea Wi-Fi în partea de sus nu face o plajă privată accesibilă și nu poate opri o destinație pe care profilul o include deja. Lista mută interfețe; profilul mută prefixe. Apple documentează prioritatea pe pagina despre ordinea serviciilor de rețea, care merită citită o dată înainte să reordonezi ceva.

Citește ruta pe care mașina a ales-o de fapt

Întreabă mașina unde merge o adresă anume cu route get 10.20.4.10, apoi repetă pentru IPv6 cu route -n get -inet6 2001:db8::10. Cele două familii sunt decizii separate, așa că o rută IPv4 funcțională nu spune nimic despre v6, iar o subrețea conectată direct sau un prefix mai specific învinge oricum eticheta generală a conexiunii, ceea ce este exact motivul pentru care eticheta continuă să inducă oamenii în eroare.

Dacă ieșirea numește interfața tunelului, profilul a captat destinația, iar ordinea este irelevantă. Dacă numește interfața fizică, profilul nu a făcut-o, iar nicio trasare nu va schimba tabelul de prefixe. Ambele ieșiri numesc și adresa sursă pe care mașina ar folosi-o, și acesta este câmpul de citat când compari două rulări. Salvează ieșirea înainte de a schimba ceva, pentru că este singura dovadă pe care o vei avea după.

DNS rezolvă după nume, nu după interfață

Resolverii cu domeniu de aplicare și cei specifici domeniului înseamnă că răspunsul poate varia după nume, nu după interfață. scutil --dns afișează configurația resolverului pe care sistemul o folosește efectiv, inclusiv intrările cu domeniu de aplicare. Ordinea serviciilor influențează care serviciu furnizează resolverul implicit, dar un domeniu de aplicare specific numelui poate câștiga totuși.

De aceea un ping către o adresă poate funcționa în timp ce numele de gazdă eșuează, sau invers. Citește ambele ieșiri înainte de a alege un vinovat.

Schimbă profilul, apoi citește din nou ambele ieșiri

Când o politică de destinație trebuie schimbată, proprietarul este profilul VPN: rute incluse, rute excluse și toate regulile de tunel divizat pe care le acceptă furnizorul. Schimbarea interfețelor doar mută discuția. Pe un Mac administrat de la distanță, salvează mai întâi starea rețelei actuale, pentru că pierderea tunelului pe o mașină la care nu poți ajunge este o călătorie, nu o revenire.

Reproduce defecțiunea, citește ruta, citește resolverul, schimbă un singur lucru, apoi citește din nou aceleași două ieșiri. Amestecarea mai multor servicii și profiluri deodată lasă o mașină pe care nimeni nu o poate explica, inclusiv persoana care a reparat-o. Testul se încheie când ambele ieșiri sunt de acord cu schimbarea intenționată. Dacă încă nu sunt de acord, profilul și mașina descriu două politici diferite, iar profilul este cel care trebuie schimbat.