Cum regulile de domeniu Apple VPN On Demand declanșează un tunel

Tunelul se deschide când ceri un nume intern și rămâne închis când următoarea aplicație are nevoie de el la fel de mult. Nu este un bug al aplicației; este forma unei reguli de domeniu. Configurația on-demand a Apple descrie condițiile pentru stabilirea unei conexiuni, iar forma de domeniu a acestor condiții întreabă resolverul sistemului înainte să se miște un singur pachet. Două întrebări sunt confundate constant: când trebuie să urce tunelul și ce transportă tunelul odată ce există. Prima este un declanșator, a doua este o politică de rute și resolver, iar un profil le setează de obicei pe amândouă în același payload, de aceea o regulă de domeniu corectă te poate lăsa totuși în rețeaua greșită.

Declanșatorul și selecția traficului stau în straturi diferite

O regulă on-demand trăiește în dicționarul on-demand al unui payload VPN: o listă ordonată de reguli, fiecare cu o acțiune și un set de condiții de potrivire. Sistemul le evaluează când se schimbă conectivitatea sau când ceva încearcă să ajungă la rețea, iar acțiunea decide dacă tunelul este ridicat, evaluat, deconectat sau ignorat. Toate acestea se întâmplă în stratul de rețea al platformei, înainte ca aplicația ta să aibă un socket.

Ce urmează este un grup separat de chei: setările IPv4 și IPv6 ale tunelului, rutele incluse și excluse, adresele serverelor DNS și, pe iOS și iPadOS, maparea pe aplicație care decide ce aplicații pot folosi tunelul. Un profil poate îmbina un declanșator larg cu o rută îngustă, sau un declanșator îngust cu o rută implicită. Citește doar o jumătate și cealaltă va părea o defecțiune.

Am un profil de laborator care se conectează ori de câte ori se cere ceva sub un domeniu intern, dar direcționează doar o /16 în tunel. Face exact ce spune payloadul lui, și este și tipul de profil care generează tichete: oamenii presupun că un tunel conectat înseamnă că traficul lor este în el.

Ce întreabă de fapt o regulă de domeniu resolverul

Forma de domeniu a regulii, adesea numită connect-if-needed, nu inspectează payloadurile pachetelor și nu urmărește URL-uri. Când un nume este rezolvat, sistemul îl compară cu domeniile din regulă și, la o potrivire, întreabă dacă numele poate fi rezolvat prin serverele DNS pe care tunelul le oferă. Dacă răspunde resolverul tunelului, numele contează ca intern și conexiunea începe. Dacă răspunde resolverul local, numele este tratat ca extern și nu apare niciun tunel. Prezentarea generală a implementării Apple descrie asta ca detectare a rețelei urmată de evaluarea conexiunii.

Rezultă două consecințe. Profilul trebuie să numească servere DNS în interiorul tunelului; o regulă de domeniu fără resolver de tunel nu are ce compara, așa că evaluarea nu poate produce potrivirea așteptată. Și căutarea trebuie să ajungă la resolverul sistemului. O aplicație sau un browser care rulează propriul DNS criptat, o extensie care răspunde local sau o conexiune la o adresă literală nu produc niciodată rezolvarea de nume pe care o aștepta regula. Una dintre cele mai lungi după-amieze pe care le-am petrecut s-a încheiat când am descoperit că clientul din fața tunelului folosea DNS over HTTPS.

Cache-ul elimină și el declanșatorul. Un nume deja din cache poate fi rezolvat fără sondarea care ar fi pornit tunelul, așa că o regulă care funcționa ieri eșuează după o repornire sau după ce tunelul a stat sus ceva timp. Pe macOS, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder resetează starea; pe iOS, comutarea modului avion sau repornirea dispozitivului îți dă o tablă curată comparabilă.

Domeniul de potrivire: nume, aplicații și rețele

Potrivirea de domeniu este un tip dintre mai multe. O regulă poate potrivi și tipul de interfață (Wi-Fi, mobil, Ethernet) și un SSID anume, iar intrările pe aplicație sau domeniu Safari leagă un tunel de un singur flux de lucru. Această legătură explică experiența ciudată în care doar o aplicație se comportă altfel decât toate celelalte: celelalte aplicații sunt în afara domeniului tunelului, așa că folosesc în continuare calea locală chiar și când pictograma tunelului spune conectat.

Ordinea contează mai mult decât se așteaptă oamenii. Regulile sunt evaluate în succesiune și prima care potrivește oferă acțiunea, așa că o regulă largă de conectare-la-orice-Wi-Fi plasată deasupra unei reguli de domeniu înguste câștigă în tăcere și face regula de domeniu netestabilă. Înainte de a rescrie lista de domenii, confirmă că nicio regulă anterioară nu a potrivit deja.

De aceea always-on nu este doar o regulă on-demand mai strictă. Aplicarea always-on este un mod de implementare separat cu propriile cerințe de supraveghere și administrare; ține un tunel deschis în loc să reacționeze la un nume. Dacă ai nevoie de un tunel care nu cade niciodată, o regulă de domeniu este instrumentul greșit.

Moduri de eșec care imită o regulă stricată

Majoritatea rapoartelor că o regulă de domeniu nu funcționează ajung într-unul din cinci locuri, și doar ultimul dintre ele este textul regulii.

Portalele captive merită propria linie, pentru că Wi-Fi-ul din hoteluri și aeroporturi interceptează exact căutarea de care depinde regula. Până când portalul admite dispozitivul, serverul DNS al tunelului este inaccesibil, sondarea eșuează, iar eșecul arată ca un domeniu scris greșit. Autentificarea este celălalt caz silențios: regula poate declanșa, tunelul poate începe conectarea, iar conexiunea moare pe un certificat expirat sau pe un prompt care apare pe alt ecran.

IPv6 creează o variantă ușor de diagnosticat greșit. Un nume cu ambele familii de adrese poate fi rezolvat mai întâi dintr-o înregistrare AAAA, în timp ce lista de rute a tunelului poartă doar IPv4. Un browser reușește, altul eșuează, iar lista de domenii este complet nevinovată.

Testează cu o cerere reală, în această ordine

Citește politica înainte de a ghici. Pe macOS, sudo profiles show -type configuration tipărește profilele instalate, inclusiv payloadul VPN, scutil --nc list arată starea serviciului, iar scutil --nc show <service> tipărește dicționarul on-demand pe care îl folosește sistemul. Pe un iPhone sau iPad administrat, același payload vine din consola de administrare sau dintr-un raport MDM. Jurnalele de rețea sunt disponibile cu log stream --predicate 'subsystem == "com.apple.networkextension"' pe macOS și prin consola dispozitivului când telefonul este conectat.

Apoi testează cu un nume de gazdă care nu a fost interogat mai devreme în sesiune. Alege un nume din zona DNS a tunelului despre care știi că se rezolvă intern, cere-l o dată și urmărește dacă apare tunelul. Rulează aceeași căutare de două ori: a doua încercare exersează calea cache-ului, iar diferența dintre ele îți spune dacă declanșatorul este rezolvarea sau rutarea.

După ce tunelul este sus, verifică cele două straturi separat. netstat -rn -f inet și netstat -rn -f inet6 arată unde duce fiecare prefix, scutil --dns arată ordinea resolverelor și ce interfață deține fiecare resolver, iar nettop -m route arată ce interfață a transportat octeții. Dacă tunelul este sus și resolverul este corect, dar resursa tot eșuează, oprește editarea regulii; verifică autorizarea pe server și ruta de întoarcere.

Când regula aparține altcuiva

Dacă tunelul reapare după ce îl deconectezi, regula aparține de obicei unui profil, nu unei aplicații: o configurație trimisă prin MDM, un profil personal rămas sau un profil instalat de alt client. sudo profiles show -type configuration plus o căutare după cheile on-demand o vor restrânge, iar calea de eliminare este profilul, nu comutatorul din bara de meniu. Ștergerea intrării de serviciu sau a aplicației lasă regula în urmă, iar următoarea instalare o moștenește din nou.

Un singur test rezolvă proprietatea: deconectează, așteaptă, cere din nou numele intern. Dacă tunelul revine, declanșatorul funcționează conform proiectării, iar întrebarea deschisă este cine îl administrează și dacă acel domeniu este cel dorit.

Înainte de a raporta asta ca bug, parcurge aceleași cinci verificări: adrese de resolver ale tunelului prezente în payload, un nume care nu era în cache, nicio regulă anterioară care să fi potrivit deja, o cale AAAA acoperită de lista de rute și aplicația în domeniul tunelului. Când toate cinci sunt valabile, regula își face treaba, iar defectul este mai departe pe cale.