Mac PF VPN-vergrendeling: een sitebeleid, geen uitleverbare functie

Het werkt op je Mac, dus het lijkt iets dat je aan gebruikers kunt geven. Die aanname is het eerste dat je moet loslaten. Apples TN3165 zegt duidelijk dat Packet Filter geen ondersteunde API is voor algemeen gedistribueerde producten, en het ziet bevoorrechte, gecontroleerde sitebeheer als het redelijke geval. Een VPN-vergrendeling op basis van PF is daarom een lokaal operationeel beleid met een eigenaar, geen functie die je in een app kunt uitleveren.

PF is geen verpakkingsoppervlak

Het onderscheid is niet academisch. Een gedistribueerd product dat van PF afhangt, erft elke wijziging die Apple eraan aanbrengt, elk conflict met een ander hulpmiddel dat ook regels schrijft, en geen enkele toezegging dat de regeling blijft werken. Een site die zijn eigen machines beheert, heeft een andere verhouding: die kan de afhankelijkheid documenteren, deze tegen elke OS-versie testen en het onderhoud accepteren.

Sommige installatieadviezen overschrijden een grens die het benoemen waard is. Het volledige systeemregelbestand overschrijven om één anker te laten laden, Apples systeemstartconfiguratie bewerken of System Integrity Protection uitschakelen zijn geen aanvaardbare vereisten voor een herbruikbaar recept. Als een gepubliceerde gids een van die dingen nodig heeft, beschrijft die een lab, geen beleid dat je kunt uitrollen.

Schrijf de uitgangsintentie vóór de syntaxis

Bepaal wat is toegestaan voordat je één trefwoord kiest. Meestal moeten er drie paden bestaan: het eigen transport van de VPN-client naar zijn server, het beschermde applicatieverkeer in de tunnel, en alles wat installatie of lokale diensten echt een direct pad nodig hebben.

Geef elke voorgestelde uitzondering een bestemming, een transport en een eigenaar. Elke poort naar één eindpunt toestaan staat veel meer toe dan het ene transport dat de tunnel gebruikt, en de extra blootstelling ontstaat zonder dat iemand heeft besloten dat het zo moet. Een openbare resolver toestaan is dezelfde val in een vriendelijker jasje: het maakt een direct DNS-pad zelfs terwijl de tunnel uit staat, dus naamopzoekingen lekken nog steeds.

De nuttige test voor een uitzondering is of je de persoon kunt noemen die erom vroeg en de storing die ze voorkomt. Als geen van beide antwoorden bestaat, is de regel waarschijnlijk een omweg voor een verkeerde configuratie die anders onzichtbaar blijft.

utun-nummers zijn geen identiteit

MacOS maakt tunnelinterfaces aan als utun-apparaten, en het nummer dat aan je VPN wordt toegewezen is niet stabiel over herstarts, opnieuw verbinden of de aanwezigheid van een andere client. Een regel die meerdere geraden nummers opsomt, is geen beleid; het is een momentopname van één middag.

Veranker de regel aan iets dat de bedoelde provider identificeert: het adresplan dat de tunnel toekent, het proces dat de interface bezit, of een configuratie die de VPN-client zelf onderhoudt. Leg daarna vast hoe die identificatie werkt, want de persoon die de regel over een jaar beoordeelt, heeft jouw shellgeschiedenis niet.

Maak het geladen beleid toerekenbaar

Een ankernaam ordent regels; hij bewijst niet dat het effectieve beleid is wat je bedoelde. Voorrang tussen ankers, regels die andere software heeft geladen en bestaande toestand kunnen allemaal de uitkomst veranderen. Beoordeel de effectieve set samen met iedereen die ook PF beheert op die machine, en documenteer het eigenaarschap op dezelfde plek als de configuratie. Twee eigenaren die verschillende ankers met verschillende aannames bewerken, is de gewone manier waarop een vergrendeling een gat krijgt.

Houd de regelset in het ondersteunde configuratiepad van de site, versioneer hem en noteer welke macOS-versies zijn getest. Een wijziging die met de hand wordt toegepast en door één persoon wordt onthouden, is geen onderhouden infrastructuur, wat de bestandskop ook zegt.

Test de overgangen, niet de verbonden toestand

Een schermafbeelding terwijl de tunnel actief is, bewijst bijna niets. Doorloop de toestanden: opstarten vóór enige verbinding, een werkende tunnel, een tunnel die zonder waarschuwing wegvalt, een bewuste verbreking en een overgang van Wi-Fi naar een hotspot. Elke toestand heeft zijn eigen antwoord, en de interessante zijn de fouten, niet het gelukkige pad.

Noteer in elke toestand wat bewust bereikbaar is. Controleer IPv4 en IPv6 afzonderlijk, test naamresolutie en neem een stroom op die al bestond vóór de overgang, omdat bestaande verbindingen niet altijd het nieuwe beleid volgen. Een browser die faalt terwijl de tunnel uit staat, is één datapunt, geen bewijs dat elk ander pad is geblokkeerd.

Houd ten slotte een herstelmethode aan die niet afhangt van het netwerkpad dat je wijzigt. Een bekend goede configuratie op lokale opslag en een gedocumenteerde manier om die te laden maken van een vergrendeling een beleid; zonder die twee sluit één slechte revisie de beheerder buiten van de machine die beschermd had moeten worden.