Ce instrument macOS poate forța o singură aplicație să treacă doar prin VPN?

O singură linie într-un document de cerințe — „această aplicație poate folosi VPN-ul și nimic altceva” — cere în liniște două mecanisme pe care niciun singur comutator nu le oferă. Traficul are nevoie de o cale prin tunelul dorit, iar traficul care ar ieși direct trebuie refuzat. Instrumentele care fac bine una dintre ele și pe cealaltă deloc sunt obișnuite, de aceea o comparație care întreabă doar dacă ceva poate bloca răspunde cu încredere la jumătate din întrebare. Scrieți mai întâi granița, apoi alegeți componentele care acoperă ambele ei jumătăți.

Două cerințe ascunse într-o singură propoziție

Direcționarea este partea care pune o conexiune în tunel sau în proxy. Refuzarea este partea care împiedică aceeași conexiune să iasă pe orice altă rută. Le implementează componente diferite, ele eșuează în moduri diferite, iar un produs poate fi excelent la una fără să spună nimic despre cealaltă:

Citiți tabelul ca pe o listă de verificare, nu ca pe un clasament. Niciun rând nu umple ambele coloane din mijloc, iar rândurile care le acoperă sunt două componente care cooperează: una deține calea, cealaltă deține refuzarea. Coloana identității contează dintr-un alt motiv, fiindcă o regulă care nu poate numi aplicația nu poate impune o regulă despre acea aplicație. Orice ați implementa, trebuie să răspundă tuturor trei, altfel granița din documentul de cerințe nu este granița de pe mașină.

Doar direcționarea lasă o ieșire

Setarea de proxy a aplicației este cel mai clar exemplu de direcționare fără refuzare. Poate direcționa cererile unei aplicații care respectă proxy-ul sistemului și nu acoperă nimic altceva: un proces auxiliar, un actualizator, un serviciu din fundal sau un alt protocol pot merge pe propria cale fără să citească vreodată acea setare. Așadar alegerea unui punct final SOCKS într-un panou nu creează o politică de interdicție a ieșirii directe pentru aplicație. Dacă cerința este despre aplicația în ansamblu, întrebați ce componente identifică regula cu adevărat.

Un profil VPN per aplicație direcționează mai bine decât un proxy, fiindcă platforma decide care aplicații intră în tunel în loc ca fiecare aplicație să decidă singură. Totuși nu refuză nimic: profilul oferă o cale, iar traficul care nu se potrivește cu ea ia ruta obișnuită. Exact acel gol este locul unde o a doua componentă își câștigă locul, și de aceea produsele care arată ca un singur comutator sunt de obicei două.

Doar refuzarea strică aplicația

Documentația Apple despre filtrele de conținut descrie un verdict permite-sau-blochează asupra traficului în timp ce trece prin stiva de rețea. Acel verdict nu este un tunel și nici o conexiune proxy, fiindcă decide dacă ceva poate continua, nu încotro merge. Un filtru singur aplică refuzarea perfect și lasă aplicația inutilizabilă, cu jurnale curate și fără nicio explicație. Verdictul unui filtru poate opri o conexiune dar nu oferă niciodată tunelul, așa că asocierea lui cu direcționarea este decizia de proiectare și nu un supliment opțional.

Un set de reguli PF administrat local stă la celălalt capăt al acelui spectru. Este o decizie de suport legitimă pe o mașină deținută de un administrator, și nu este automat fundația unui produs distribuibil, fiindcă cine deține setul de reguli deține și interacțiunile lui cu alți utilizatori de firewall, calea de actualizare și recuperarea lui când o regulă este greșită. Adăugarea PF la un produs nu elimină acea întrebare a proprietății; o definește.

Implementarea decide dacă regula mai există și mâine

Modul în care o Network Extension este implementată pe platformele Apple depinde de tipul de furnizor, de împachetare și de versiunea de sistem de operare din fața dumneavoastră. O extensie de aplicație pe macOS rulează într-un context de utilizator și se termină când acel utilizator se deconectează, în timp ce o extensie de sistem are un context global care nu depinde de sesiune. Dacă protecția trebuie să supraviețuiască unei deconectări, acea diferență este întregul proiect și nu o notă de subsol. Confirmați calea de implementare înainte de a promite comportamentul, fiindcă același cod aterizează diferit în funcție de tipul de extensie livrat.

Disponibilitatea codului sursă este o chestiune separată de aplicare. Citirea unui depozit vă spune cum este implementat ceva, nu ce are voie să facă binarul instalat pe această mașină. Semnarea, instalarea și autorizarea se aplică în continuare, iar instrucțiunile construite în jurul unei extensii de kernel învechite sau al unui truc de injectare de bibliotecă descriu o altă platformă și o altă poziție față de risc, oricât de bine ar fi funcționat cândva.

Un caz de acceptare care numește aplicația

Alegeți o singură acțiune pe care aplicația o face de la sine, notați adresa pe care ar trebui să o atingă și dacă acea adresă este IPv4 sau IPv6, apoi repetați aceeași acțiune în starea aprobată fără tunel. A doua rulare trebuie să producă refuzarea declarată și nu o reîncercare directă tăcută. Aceasta este jumătatea pe care oamenii o lasă nespecificată, și singura jumătate care dovedește că refuzarea există. Rulați-o mai întâi cu tunelul disponibil, astfel încât o diferență între cele două rezultate să poată veni doar din tunelul lipsă.

Apoi parcurgeți tranzițiile pe care le numește cerința: repornirea aplicației, declanșarea unui proces auxiliar, reconectarea tunelului, schimbarea rețelelor de către mașină și o deconectare sau repornire acolo unde se aplică. O pagină de IP public din browser nu este un test al socketurilor altei aplicații, așa că nu poate înlocui acest test. Unde nicio implementare acceptată nu acoperă comportamentul real al aplicației, un mediu izolat autorizat cu un gateway explicit și fără ieșire alternativă este o decizie de izolare cu propriul cost de administrare, nu un substitut pentru o casetă de bifare.

Încheiați notând patru puncte: din ce componente este formată aplicația, cine deține direcționarea, cine deține refuzarea și stările în care regula trebuie să fie încă valabilă. Un depozit public poate fi un criteriu de selecție, dar nu este unul dintre cele patru, iar acele puncte sunt cele care decid dacă un instrument dat îndeplinește cerința de rețea.