Mac PF VPN-lås: en lokal politik, ikke en funktion du kan udgive

Det virker på din Mac, så det ligner noget, du kan give videre til brugerne. Den antagelse er det første, du skal slippe. Apples TN3165 siger klart, at Packet Filter ikke er en understøttet API til almindeligt distribuerede produkter, og den fremstiller privilegeret, kontrolleret lokaladministration som det rimelige tilfælde. En VPN-lås bygget på PF er derfor en lokal driftsmæssig politik med en ejer, ikke en funktion, du kan udgive inde i en app.

PF er ikke en pakningsflade

Forskellen er ikke akademisk. Et distribueret produkt, der afhænger af PF, arver enhver ændring, Apple foretager i det, enhver konflikt med et andet værktøj, der også skriver regler, og ingen supportforpligtelse om, at ordningen bliver ved med at virke. Et sted, der administrerer sine egne maskiner, har et andet forhold: det kan dokumentere afhængigheden, teste den mod hver OS-udgivelse og acceptere vedligeholdelsen.

Nogle installationsråd krydser en grænse, der er værd at navngive. At overskrive hele systemets regelsæt for at få én anchor til at indlæse, at redigere Apples systemstartkonfiguration eller at deaktivere System Integrity Protection er ikke acceptable krav til en genanvendelig opskrift. Hvis en offentliggjort vejledning har brug for noget af det, beskriver den et laboratorium, ikke en politik, der kan implementeres.

Skriv udgangshensigten før syntaksen

Beslut, hvad der er tilladt, før du vælger et eneste nøgleord. Normalt skal der findes tre veje: VPN-klientens egen transport til sin server, den beskyttede applikations trafik inde i tunnelen og alt, hvad opsætning eller lokale tjenester reelt kræver som direkte vej.

Giv enhver foreslået undtagelse en destination, en transport og en ejer. At tillade alle porte til et endepunkt tillader langt mere end den ene transport, tunnelen bruger, og den ekstra eksponering opstår, uden at nogen har besluttet, at den skal være der. At tillade en offentlig resolver er den samme fælde i en venligere klædning: den skaber en direkte DNS-vej, selv mens tunnelen er nede, så navneopslag lækker stadig.

Den nyttige test for en undtagelse er, om du kan navngive den person, der bad om den, og den fejl, den forhindrer. Hvis ingen af svarene findes, er reglen sandsynligvis en omvej for en fejlkonfiguration, der ellers ville forblive usynlig.

utun-numre er ikke en identitet

MacOS opretter tunnelinterfaces som utun-enheder, og nummeret, der tildeles din VPN, er ikke stabilt på tværs af genstarter, genopkoblinger eller tilstedeværelsen af en anden klient. En regel, der lister flere gættede numre, er ikke en politik; det er et øjebliksbillede af en eftermiddag.

Forankr reglen i noget, der identificerer den tilsigtede udbyder: adresseplanen, som tunnelen tildeler, processen, der ejer interfacet, eller en konfiguration, som VPN-klienten selv vedligeholder. Skriv derefter ned, hvordan den identifikation fungerer, for den person, der gennemgår reglen om et år, har ikke din shell-historik.

Gør den indlæste politik tilskrivelig

Et anchor-navn organiserer regler; det beviser ikke, at den effektive politik er den, du havde til hensigt. Forrang mellem anchors, regler som andre programmer har indlæst, og eksisterende tilstand kan alle ændre resultatet. Gennemgå det effektive sæt sammen med enhver anden, der ejer PF på den maskine, og dokumenter ejerskabet samme sted som konfigurationen. To ejere, der redigerer forskellige anchors med forskellige antagelser, er den sædvanlige måde, hvorpå en lås får et hul.

Hold regelsættet i stedets understøttede konfigurationssti, versionsstyr det, og noter hvilke macOS-udgivelser der er testet. En ændring, der anvendes manuelt og huskes af én person, er ikke vedligeholdt infrastruktur, uanset hvad filhovedet siger.

Test overgangene, ikke den tilsluttede tilstand

Et skærmbillede taget, mens tunnelen er oppe, beviser næsten intet. Gå i stedet gennem tilstandene: opstart før nogen forbindelse, en fungerende tunnel, en tunnel, der falder uden varsel, en bevidst afbrydelse og et skift fra Wi-Fi til hotspot. Hver tilstand har sit eget svar, og de interessante er fejlene frem for den glade vej.

I hver tilstand skal du registrere, hvad der er bevidst tilgængeligt. Kontroller IPv4 og IPv6 hver for sig, test navneopløsning, og inkluder et flow, der allerede var etableret før overgangen, da eksisterende forbindelser ikke altid følger den nye politik. En browser, der fejler, mens tunnelen er nede, er et datapunkt, ikke bevis for, at alle andre veje er blokeret.

Endelig skal du beholde en gendannelsesmetode, der ikke afhænger af den netværksvej, du ændrer. En kendt god konfiguration på lokal lagring og en dokumenteret måde at indlæse den gør en lås til en politik; uden dem låser en dårlig revision administratoren ude af den maskine, der skulle beskyttes.