Kva macOS-verktøy kan tvinge éin app gjennom VPN-et og ingenting anna?

Éi linje i eit kravdokument — «denne appa kan bruke VPN-et, og ingenting anna» — ber stille om to mekanismar som ingen einbrytar leverer. Trafikken treng ein veg gjennom den tiltenkte tunnelen, og trafikk som elles ville gå direkte ut, må avvisast. Verktøy som gjer det eine godt og det andre ikkje i det heile, er vanlege, og difor svarar ein samanlikning som berre spør om noko kan blokkere, sjølvsikkert på halvparten av spørsmålet. Skriv fyrst grensa ned, og vel deretter komponentane som dekkjer båe halvdelane av henne.

To krav som gøymer seg i éi setning

Styring er delen som set ei tilknyting inn i tunnelen eller proxyen. Avvising er delen som hindrar den same tilknytinga i å gå ut via nokon annan rute. Ulike komponentar implementerer dei, dei sviktar på ulike måtar, og eit produkt kan vere framifrå i det eine utan å seie noko om det andre:

Les tabellen som ei sjekkliste og ikkje som ei rangering. Ingen rad fyller båe dei midtre kolonnane, og radene som dekkjer dei, er to komponentar som samarbeider: den eine eig vegen, den andre eig avvisinga. Identitetskolonnen har noko å seie av ein annan grunn, fordi ei regel som ikkje kan namngje appa, ikkje kan handheve ei regel om den appa. Uansett kva du rullar ut, må det svare på alle tre, elles er grensa i kravdokumentet ikkje grensa på maskina.

Styring åleine etterlèt ein utveg

Innstillinga for applikasjonsproxy er det tydlegaste dømet på styring utan avvising. Ho kan styre førespurnader frå ei app som respekterer systemproxyen, og dekkjer ingenting anna: ein hjelpeprosess, ein oppdaterar, ein bakgrunnsteneste eller ein annan protokoll kan reise sin eigen veg utan å nokosinne lese den innstillinga. Å velje eit SOCKS-endepunkt i eitt panel skaper difor ikkje ein politikk om ingen direkte utgang for applikasjonen. Viss kravet handlar om appa som heilskap, spør kva komponentar regelen faktisk identifiserer.

Ein VPN-profil per app styrer betre enn ein proxy, fordi plattforma avgjer kva apper som kjem inn i tunnelen i staden for at kvar app avgjer det sjølv. Likevel avviser han ingenting: profilen gjev ein veg, og trafikk som ikkje passar til han, tek den vanlege ruta. Det holet er nettopp staden der ein andre komponent fortener plassen sin, og difor er produkt som ser ut som éin brytar, som regel to.

Avvising åleine øydelegg appa

Apples dokumentasjon om innhaldsfilter skildrar ein tillat-eller-blokker-dom over trafikk medan han passerer nettverksstakken. Den domen er korkje ein tunnel eller ei proxyforbinding, fordi han avgjer om noko kan halde fram, og ikkje kvar det går. Eit filter åleine handhevar avvisinga perfekt og lèt applikasjonen liggje ubrukeleg, med reine loggar og inga forklaring. Ein filterdom kan stoppe ei tilknyting, men leverer aldri tunnelen, så å pare han med styring er designavgjerda og ikkje eit ekstra val.

Eit lokalt administrert PF-regelsett ligg i den andre enden av spekteret. Det er ei legitim støtteavgjerd på ei maskin ein administrator eig, og det er ikkje automatisk grunnlaget for eit produkt som kan distribuerast, fordi den som eig regelsettet, òg eig samspelet med andre brannmur-brukarar, oppgraderingsvegen og attopprettinga når ei regel er feil. Å leggje PF til eit produkt fjernar ikkje det eigedomsspørsmålet; det definerer det.

Utrullinga avgjer om regelen finst i morgon òg

Korleis ein Network Extension blir rulla ut på Apples plattformer, avheng av tilbydartypen, pakkinga og OS-versjonen framfor deg. Ei apputviding på macOS køyrer i ein brukarkontekst og sluttar når den brukaren loggar ut, medan ei systemutviding har ein global kontekst som ikkje avheng av økta. Viss vernet skal overleve ein utlogging, er den skilnaden heile designet og ikkje ei fotnote. Stadfest utrullingsvegen før du lovar åtferda, fordi den same koden landar ulikt avhengig av kva utvidingstype som blir send ut.

Tilgang på kjeldekode er ei anna sak enn handheving. Å lese eit depot fortel deg korleis noko er implementert, ikkje kva den installerte binærfilen har lov til å gjere på denne maskina. Signering, installasjon og autorisasjon gjeld framleis, og instruksjonar bygde rundt ei utdatert kjerneutviding eller eit bibliotekinjeksjonstriks skildrar ei anna plattform og ei anna risikohaldning, uansett kor godt dei ein gong verka.

Eit aksepttilfelle som namngjev appa

Vel éi enkelt handling som applikasjonen utfører av seg sjølv, noter adressa han skal nå, og om den adressa er IPv4 eller IPv6, og gjer deretter den same handlinga om i den godkjende tilstanden utan tunnel. Den andre køyringa må framstille den kunngjorde avvisinga og ikkje eit stille direkte nytt forsøk. Det er den halvdelen folk lèt stå uspesifisert, og den einaste halvdelen som provar at avvising i det heile finst. Køyr han fyrst med tunnelen tilgjengeleg, slik at ein skilnad mellom dei to resultata berre kan kome frå den manglande tunnelen.

Gå deretter gjennom overgangane kravet nemner: omstart av appa, ein hjelpeprosess som blir utløyst, tunnelen som koplar til att, maskina som byter nettverk, og ei utlogging eller omstart der det gjeld. Ei nettside med offentleg IP i ein nettlesar er ikkje ein test av sockets i ein annan applikasjon, så ho kan ikkje erstatte denne. Der inga støtta utrulling dekkjer den faktiske åtferda til appa, er eit autorisert isolert miljø med ein eksplisitt gateway og ingen alternativ utgang ei inndemmingsavgjerd med eigne administrasjonskostnader, ikkje ei erstatning for ein avkryssingsboks.

Avslutt med å skrive ned fire punkt: kva komponentar appa består av, kven som eig styringa, kven som eig avvisinga, og tilstandane der regelen framleis må gjelde. Eit offentleg depot kan vere eitt utvalskriterium, men det er ikkje eitt av dei fire, og dei punkta er det som avgjer om eit gitt verktøy oppfyller nettverkskravet.