PF VPN-lås på Mac: en platsprincip, inte en levererbar funktion

Det fungerar på din Mac, så det ser ut som något du kan ge användarna. Det antagandet är det första du måste släppa. Apples TN3165 säger tydligt att Packet Filter inte är ett API med stöd för allmänt distribuerade produkter, och det ramar in privilegierad, kontrollerad platsadministration som det rimliga fallet. Ett VPN-lås byggt på PF är därför en lokal driftspolicy med en ägare, inte en funktion du kan leverera inuti en app.

PF är inte en paketeringsyta

Skillnaden är inte akademisk. En distribuerad produkt som är beroende av PF ärver varje ändring Apple gör i det, varje konflikt med ett annat verktyg som också skriver regler, och inget supportlöfte om att arrangemanget fortsätter att fungera. En plats som administrerar sina egna maskiner har en annan relation: den kan dokumentera beroendet, testa det mot varje OS-version och acceptera underhållet.

Vissa installationsråd korsar en gräns som är värd att namnge. Att skriva över hela systemets regeluppsättning för att ladda en enda anchor, redigera Apples systemstartskonfiguration eller inaktivera System Integrity Protection är inte acceptabla krav för ett återanvändbart recept. Om en publicerad guide behöver något av det beskriver den ett labb, inte en policy som går att driftsätta.

Skriv utgångsavsikten före syntaxen

Bestäm vad som är tillåtet innan du väljer ett enda nyckelord. Vanligtvis måste tre vägar finnas: VPN-klientens egen transport till sin server, den skyddade applikationstrafiken inuti tunneln och allt som installation eller lokala tjänster verkligen behöver en direkt väg.

Ge varje föreslaget undantag en destination, en transport och en ägare. Att tillåta alla portar till en ändpunkt tillåter långt mer än den enda transport som tunneln använder, och den extra exponeringen uppstår utan att någon har beslutat att den ska göra det. Att tillåta en offentlig resolver är samma fälla i en vänligare skrud: den skapar en direkt DNS-väg även när tunneln är nere, så namnsökningar läcker fortfarande.

Det användbara testet för ett undantag är om du kan namnge personen som bad om det och felet det förhindrar. Om inget av svaren finns är regeln förmodligen en kringgång för en felkonfiguration som annars skulle förbli osynlig.

utun-nummer är inte en identitet

MacOS skapar tunnelgränssnitt som utun-enheter, och numret som tilldelas din VPN är inte stabilt mellan omstarter, återanslutningar eller närvaron av en annan klient. En regel som listar flera gissade nummer är inte en policy; det är en ögonblicksbild av en eftermiddag.

Förankra regeln i något som identifierar den avsedda leverantören: adressplanen som tunneln tilldelar, processen som äger gränssnittet eller en konfiguration som VPN-klienten själv underhåller. Registrera sedan hur den identifieringen fungerar, eftersom personen som granskar regeln om ett år inte kommer att ha din skallhistorik.

Gör den laddade policyn tillskrivbar

Ett anchor-namn organiserar regler; det bevisar inte att den effektiva policyn är den du avsåg. Prioritet mellan anchors, regler som annan programvara har laddat och befintligt tillstånd kan alla ändra resultatet. Granska den effektiva uppsättningen tillsammans med alla andra som äger PF på den maskinen, och dokumentera ägandet på samma ställe som konfigurationen. Två ägare som redigerar olika anchors med olika antaganden är det vanliga sättet ett lås får ett hål.

Håll regeluppsättningen i platsens stödda konfigurationsväg, versionshantera den och notera vilka macOS-versioner som testades. En ändring som tillämpas för hand och kommer ihåg av en person är inte underhållen infrastruktur, vad filhuvudet än säger.

Testa övergångarna, inte det anslutna tillståndet

En skärmbild tagen medan tunneln är uppe bevisar nästan ingenting. Gå igenom tillstånden i stället: start före någon anslutning, en fungerande tunnel, en tunnel som faller utan varning, en avsiktlig frånkoppling och en flytt från Wi-Fi till en hotspot. Varje tillstånd har sitt eget svar, och de intressanta är felen, inte den lyckliga vägen.

I varje tillstånd, registrera vad som avsiktligt är nåbart. Kontrollera IPv4 och IPv6 separat, testa namnutslagning och inkludera ett flöde som redan var etablerat före övergången, eftersom befintliga anslutningar inte alltid följer den nya policyn. En webbläsare som misslyckas medan tunneln är nere är en datapunkt, inte bevis för att alla andra vägar är blockerade.

Håll slutligen en återställningsmetod som inte beror på nätverksvägen du ändrar. En känd bra konfiguration på lokal lagring och ett dokumenterat sätt att ladda den förvandlar ett lås till en policy; utan dem låser en dålig revision ute administratören från maskinen som skulle skyddas.