Mac PF VPN-slot: 'n werfbeleid, nie 'n lewerbare funksie nie
Packet Filter is nie 'n ondersteunde API vir verspreide produkte nie. Gee die reëlversameling 'n eienaar, benoem elke uitsondering en toets die oorgange.
Dit werk op jou Mac, so dit lyk na iets wat jy aan gebruikers kan gee. Daardie aanname is die eerste ding om te laat vaar. Apple se TN3165 sê duidelik dat Packet Filter nie 'n ondersteunde API vir algemeen verspreide produkte is nie, en dit beskryf bevoorregte, beheerde werfadministrasie as die redelike geval. 'n VPN-slot wat op PF gebou is, is dus 'n plaaslike operasionele beleid met 'n eienaar, nie 'n funksie wat jy binne 'n app kan verskeep nie.
PF is nie 'n verpakkingsvlak nie
Die onderskeid is nie akademies nie. 'n Verspreide produk wat van PF afhanklik is, erf elke verandering wat Apple daaraan maak, elke konflik met 'n ander instrument wat ook reëls skryf, en geen ondersteuningsbelofte dat die reëling sal bly werk nie. 'n Werf wat sy eie masjiene administreer, het 'n ander verhouding: dit kan die afhanklikheid dokumenteer, dit teen elke OS-vrystelling toets en die instandhouding aanvaar.
Sommige installasieraad oorskry 'n grens wat die moeite werd is om te noem. Om die hele stelselreëlversameling te oorskryf sodat een anker laai, om Apple se stelselopstartkonfigurasie te wysig, of om System Integrity Protection te deaktiveer, is nie aanvaarbare vereistes vir 'n herbruikbare resep nie. As 'n gepubliseerde gids enige van dié nodig het, beskryf dit 'n laboratorium, nie 'n ontplooibare beleid nie.
Skryf die uitgangsbedoeling voor die sintaksis
Besluit wat toegelaat word voordat jy 'n enkele sleutelwoord kies. Drie paaie moet gewoonlik bestaan: die VPN-kliënt se eie vervoer na sy bediener, die beskermde toepassingverkeer binne die tonnel, en alles wat opstelling of plaaslike dienste werklik 'n direkte pad benodig.
Gee elke voorgestelde uitsondering 'n bestemming, 'n vervoer en 'n eienaar. Om elke poort na 'n eindpunt toe te laat, permitteer veel meer as die een vervoer wat die tonnel gebruik, en die ekstra blootstelling kom sonder dat iemand besluit het dit moet. Om 'n openbare oplosser toe te laat, is dieselfde lokval in 'n vriendeliker kostuum: dit skep 'n direkte DNS-pad selfs terwyl die tonnel af is, so naamopsoeke lek steeds.
| Path | Destination | Owner |
|---|---|---|
| VPN transport | Gateway address, one UDP port | Network team |
| Tunnel traffic | Internal prefixes | Application owner |
| Resolver exception | Named internal resolver | Security team |
Die nuttige toets vir 'n uitsondering is of jy die persoon kan noem wat dit gevra het en die fout wat dit voorkom. As nie een van die antwoorde bestaan nie, is die reël waarskynlik 'n towenaar om 'n verkeerde konfigurasie wat andersins onsigbaar sal bly.
utun-nommers is nie 'n identiteit nie
MacOS skep tonnelkoppelvlakke as utun toestelle, en die nommer wat aan jou VPN toegewys word, is nie stabiel oor herlaaie, herverbindings of die teenwoordigheid van 'n ander kliënt nie. 'n Reël wat verskeie gerate nommers lys, is nie 'n beleid nie; dit is 'n momentopname van een middag.
Veranker die reël aan iets wat die beoogde verskaffer identifiseer: die adresplan wat die tonnel toeken, die proses wat die koppelvlak besit, of 'n konfigurasie wat die VPN-kliënt self onderhou. Teken dan aan hoe daardie identifikasie werk, want die persoon wat die reël oor 'n jaar hersien, sal nie jou dopgeskiedenis hê nie.
Maak die gelaaide beleid toeskryfbaar
'n Ankernaam organiseer reëls; dit bewys nie dat die effektiewe beleid is wat jy bedoel het nie. Voorrang tussen ankers, reëls wat ander sagteware gelaai het, en bestaande toestand kan almal die uitkoms verander. Hersien die effektiewe versameling saam met wie anders ook PF op daardie masjien besit, en dokumenteer die eienaarskap op dieselfde plek as die konfigurasie. Twee eienaars wat verskillende ankers met verskillende aannames wysig, is die gewone manier waarop 'n slot 'n gat ontwikkel.
Hou die reëlversameling in die werf se ondersteunde konfigurasiepad, weergee dit, en noteer watter macOS-vrystellings getoets is. 'n Verandering wat met die hand toegepas en deur een persoon onthou word, is nie instandgehoude infrastruktuur nie, wat die lêerkop ook al sê.
Toets die oorgange, nie die verbinde toestand nie
'n Skermfoto wat geneem is terwyl die tonnel op is, bewys byna niks. Stap eerder deur die toestande: opstart voor enige verbinding, 'n werkende tonnel, 'n tonnel wat sonder waarskuwing val, 'n doelbewuste ontkoppeling, en 'n skuif van Wi-Fi na 'n hotspot. Elke toestand het sy eie antwoord, en die interessante een is die mislukkings eerder as die gelukkige pad.
Teken in elke toestand aan wat doelbewus bereikbaar is. Kontroleer IPv4 en IPv6 afsonderlik, toets naamresolusie, en sluit 'n vloei in wat reeds voor die oorgang gevestig is, aangesien bestaande verbindings nie altyd die nuwe beleid volg nie. 'n Blaaier wat misluk terwyl die tonnel af is, is een datapunt, nie bewys dat elke ander pad geblokkeer is nie.
Laastens, hou 'n herstelmetode wat nie van die netwerkpad wat jy verander, afhanklik is nie. 'n Bekende-goeie konfigurasie op plaaslike berging en 'n gedokumenteerde manier om dit te laai, maak 'n slot in 'n beleid; sonder hulle sluit een slegte hersiening die administrateur uit die masjien wat veronderstel was om beskerm te word.