Ena vrstica v dokumentu z zahtevami — „ta aplikacija sme uporabljati VPN in nič drugega“ — tiho zahteva dva mehanizma, ki ju nobeno posamezno stikalo ne zagotavlja. Promet potrebuje pot skozi predvideni tunel, promet, ki bi šel neposredno ven, pa mora biti zavrnjen. Orodja, ki eno od tega delajo dobro, drugega pa sploh ne, so pogosta, zato primerjava, ki vpraša le, ali lahko kaj blokira, samozavestno odgovori na polovico vprašanja. Najprej zapišite mejo, nato izberite komponente, ki pokrivajo obe njeni polovici.

Dve zahtevi, skriti v enem stavku

Usmerjanje je del, ki poveže povezavo v tunel ali proxy. Zavrnitev je del, ki isti povezavi prepreči izhod po kateri koli drugi poti. Izvajajo jih različne komponente, spodletijo na različne načine, in izdelek je lahko odličen v enem, o drugem pa ne pove ničesar:

ApproachSteers trafficRefuses direct egressKnows the app identity
Per-app VPN profileYes, for the apps it namesOnly if a filter or firewall also blocksYes, within its own rules
Application proxy settingPartly, for requests that honour itNoNo
Content filterNoYesYes, if the filter is written that way
Local PF rulesetNoYes, by address and portNot reliably

Tabelo berite kot kontrolni seznam, ne kot lestvico. Nobena vrstica ne zapolni obeh srednjih stolpcev, vrstice, ki ju pokrivajo, pa so dve sodelujoči komponenti: ena ima pot, druga zavrnitev. Stolpec identitete je pomemben iz drugega razloga, ker pravilo, ki ne more poimenovati aplikacije, ne more uveljaviti pravila o tej aplikaciji. Karkoli uvedete, mora odgovoriti na vse tri, sicer meja v dokumentu z zahtevami ni meja na stroju.

Samo usmerjanje pusti izhod

Nastavitev proxyja za aplikacijo je najjasnejši primer usmerjanja brez zavrnitve. Lahko usmeri zahteve aplikacije, ki spoštuje sistemski proxy, in ne pokriva ničesar drugega: pomožni proces, posodabljalnik, storitev v ozadju ali drug protokol lahko gre svojo pot, ne da bi to nastavitev kdaj prebral. Zato izbira končne točke SOCKS v enem podoknu ne ustvari politike prepovedi neposrednega izhoda za aplikacijo. Če se zahteva nanaša na aplikacijo kot celoto, vprašajte, katere komponente pravilo resnično prepozna.

Profil VPN za posamezno aplikacijo usmerja bolje kot proxy, ker platforma odloči, katere aplikacije vstopijo v tunel namesto da bi se vsaka aplikacija odločala sama. Kljub temu ničesar ne zavrne: profil zagotovi pot, promet, ki se z njo ne ujema, pa gre po običajni poti. Prav ta vrzel je kraj, kjer si druga komponenta zasluži svoje mesto, in zato so izdelki, ki so videti kot eno stikalo, običajno dva.

Sama zavrnitev pokvari aplikacijo

Dokumentacija Apple o filtrih vsebine opisuje razsodbo dovoli-ali-blokiraj o prometu, ko prehaja skozi omrežni sklad. Ta razsodba ni tunel in ni proxy povezava, ker odloča, ali sme kaj nadaljevati, ne pa kam gre. Filter sam po sebi brezhibno uveljavi zavrnitev in pusti aplikacijo neuporabno, s čistimi dnevniki in brez razlage. Razsodba filtra lahko ustavi povezavo, a nikoli ne zagotovi tunela, zato je njena povezava z usmerjanjem oblikovalska odločitev in ne izbirni dodatek.

Lokalno upravljana množica pravil PF stoji na drugem koncu tega spektra. Je legitimna odločitev o podpori na stroju, ki ga ima v lasti skrbnik, in ni samodejno podlaga za izdelek, ki ga je mogoče distribuirati, ker kdor ima v lasti množico pravil, ima tudi njene interakcije z drugimi uporabniki požarnega zidu, pot posodabljanja in obnovitev, ko je pravilo napačno. Dodajanje PF izdelku te lastninske dileme ne odpravi; opredeli jo.

Uvedba odloči, ali bo pravilo obstajalo tudi jutri

Kako se Network Extension uvaja na platformah Apple, je odvisno od vrste ponudnika, pakiranja in različice operacijskega sistema pred vami. Razširitev aplikacije v macOS teče v uporabniškem kontekstu in se konča, ko se ta uporabnik odjavi, medtem ko ima sistemska razširitev globalni kontekst, ki ni odvisen od seje. Če mora zaščita preživeti odjavo, je ta razlika celoten dizajn in ne opomba pod črto. Potrdite pot uvedbe, preden obljubite vedenje, ker isti kod pristane drugače glede na vrsto razširitve, ki se pošilja.

Razpoložljivost izvorne kode je ločena zadeva od uveljavljanja. Branje shrambe vam pove, kako je kaj izvedeno, ne pa, kaj sme nameščena binarna datoteka početi na tem stroju. Podpisovanje, namestitev in avtorizacija še vedno veljajo, navodila, zgrajena okoli zastarele razširitve jedra ali trika z vbrizgavanjem knjižnice, pa opisujejo drugo platformo in drugo držo do tveganja, ne glede na to, kako dobro so nekoč delovala.

Sprejemni primer, ki poimenuje aplikacijo

Izberite eno dejanje, ki ga aplikacija izvede sama, zabeležite naslov, ki bi ga morala doseči, in ali je ta naslov IPv4 ali IPv6, nato isto dejanje ponovite v odobrenem stanju brez tunela. Druga izvedba mora dati napovedano zavrnitev in ne tihega neposrednega poskusa. To je tista polovica, ki jo ljudje pustijo neopredeljeno, in edina polovica, ki dokazuje, da zavrnitev sploh obstaja. Zaženite jo najprej z razpoložljivim tunelom, da bo razlika med obema rezultatoma lahko izvirala le iz manjkajočega tunela.

Nato pojdite skozi prehode, ki jih navaja zahteva: ponovni zagon aplikacije, sprožitev pomožnega procesa, ponovna povezava tunela, menjava omrežij na stroju ter odjava ali ponovni zagon, kjer veljajo. Stran z javnim IP v brskalniku ni preizkus vtičnic druge aplikacije, zato ne more nadomestiti tega. Kjer nobena podprta uvedba ne pokriva dejanskega vedenja aplikacije, je pooblaščeno izolirano okolje z izrecnimi vrati in brez alternativnega izhoda odločitev o zadržanju z lastnimi stroški upravljanja, ne nadomestilo za potrditveno polje.

Končajte s štirimi vnosi: iz katerih komponent je sestavljena aplikacija, kdo ima usmerjanje, kdo ima zavrnitev in stanja, v katerih mora pravilo še veljati. Javna shramba je lahko eno merilo izbire, ni pa ena od štirih, in prav ti vnosi odločajo, ali dano orodje izpolnjuje omrežno zahtevo.

Sorodni članki