Statische tunneladressen in pfSense: voorkeur of reservering?

Twee ontwerpen lijken op papier op elkaar en gedragen zich heel anders zodra een regel ervan afhangt. Het ene typt een adres in een client-override en vertrouwt het adres als identiteit. Het andere sluit dynamische toelating volledig af, zodat een eindpunt ofwel een unieke toewijzing heeft ofwel geen verbinding maakt. Alleen het tweede maakt van een adres een beleidsgegeven dat je kunt verdedigen, en het verschil is de moeite waard om te begrijpen voordat je ook maar één firewallregel schrijft.

Wat een override-adres werkelijk belooft

Een Client Specific Override bevat opties per client, waaronder een voorkeurstunneladres. Netgate beschrijft dat adres als een voorkeur en niet als een reservering, wat betekent dat de dynamische pool het adres niet voor iemand anders opgeeft.

Dat is meestal prima. Een botsing is zeldzaam, en de client krijgt normaal wat hij heeft aangevraagd, wat genoeg is voor gemak en niet genoeg voor autorisatie. Gemak en autorisatie zijn verschillende eisen, en slechts één ervan overleeft een botsing.

Bij subnettopologie neemt het veld het clientadres samen met het masker van het servernetwerk, zodat een adres binnen een 10.90.0.0/24-tunnel wordt geschreven als 10.90.0.10/24.

Niets daarvan reserveert het nummer. Een client wiens override niet overeenkomt, of een dubbele sessie, kan elders in de pool terechtkomen, en een regel die op het adres is gebaseerd beschrijft dan iemand die er niet is.

Het dynamische pad sluiten met een begrensde standaard

Het alternatief is een uitsluitend statische server: elk toegelaten eindpunt heeft zijn eigen identiteit en zijn eigen unieke adres, en niets anders komt binnen.

De implementatie vereist een DEFAULT-override die tot die ene server is beperkt, met verbindingsblokkering ingeschakeld. Een client zonder passende override kan dan niet terugvallen op gewone dynamische toelating. Die ene regel is wat een voorkeur in een gesloten verzameling verandert.

Reikwijdte is belangrijk. Een standaardoverride die op elke VPN-instantie op de machine wordt toegepast, sluit ongerelateerde tunnels buiten, en die storing ziet eruit als een kapotte dienst in plaats van een beleidsbeslissing. Bind hem aan de ene server waarvan je het toelatingsmodel wijzigt. Noteer de reikwijdte daarna in het wijzigingslog, want de volgende persoon weet niet meer bij welke tunnel hij hoort.

Controleer daarna de hele toegestane verzameling. De standaardblokkering herstelt geen benoemde override die zonder adres is achtergebleven, en dat eindpunt maakt gewoon geen verbinding zonder duidelijke aanwijzing waarom.

Afstemmen op de identiteit die de server werkelijk gebruikt

Een override komt met iets overeen. Op een server die common names van certificaten vergelijkt, moet de overridenaam die common name zijn, niet de weergavenaam van de persoon. Kopieer hem uit het certificaat en niet uit de accountlijst.

Een server die is ingesteld om de gebruikersnaam als common name te gebruiken, vergelijkt op een heel andere sleutel, en een override die naar het certificaat is genoemd, zal nooit afgaan. Lees de instelling in plaats van haar af te leiden uit wat de accountlijst toont.

Behoud de extra authenticatiefactoren die de uitrol vereist. Een gesloten adresmodel verandert wie mag verbinden en welk adres hij krijgt; het vervangt de certificaatcontrole of de tweede factor niet.

De toegangsregels schrijven nadat de kaart klopt

Zodra de kaart van identiteit naar adres gesloten is, kunnen regels naar adressen verwijzen zonder te doen alsof het personen zijn. Een alias dat de eindpunten van één persoon groepeert, kan een bepaalde dienst bereiken terwijl een andere alias iets anders bereikt. De alias wordt het controleerbare object, en het adres wordt een implementatiedetail erbinnen.

Houd bestemmingen en poorten expliciet. Het hele lokale netwerk vanaf de hele tunnelpool toestaan is precies het ontwerp dat deze oefening moest vervangen.

Lees floating-, groeps- en interfaceregels in hun werkelijke evaluatievolgorde, want een eerdere brede doorgang verslaat een latere smalle. Het uitschakelen van interne doorsturing van client naar client houdt verkeer tussen peers op de grens waar die regels worden beoordeeld. Een regel die alleen op papier bestaat, is geen handhaving.

De negatieve gevallen testen

Beproef vier nieuwe verbindingen: een benoemd eindpunt, een zonder enige override, een dienst die bereikbaar zou moeten zijn en een die dat niet zou moeten zijn. Het niet-vermelde eindpunt is het belangrijke geval, want dat is degene die het ontwerp moet stoppen. Als het verbinding maakt, doet de standaardblokkering zijn werk niet.

Controleer IPv6 apart, want een IPv4-adresbeleid zegt niets over een tweede stack. Bevestig daarna dat de applicatie de gebruiker nog steeds autoriseert, want een tunneladres is een netwerkfeit en geen bewijs van wie er achter het toetsenbord zit. Beide controles horen in de acceptatienotitie.

Plan ten slotte de migratie. Nieuwe overrides en smalle regels veranderen bestaande sessies niet met terugwerkende kracht, dus bestaande toestanden moeten verlopen of bewust worden gewist.