Statiska tunneladresser i pfSense: preferens eller reservation?

Två konstruktioner ser lika ut på papperet och beter sig mycket olika när en regel beror på dem. Den ena skriver in en adress i en klientöverstyrning och litar på adressen som identitet. Den andra stänger dynamisk insläpp helt, så en ändpunkt antingen har en unik tilldelning eller inte ansluter. Bara den andra gör en adress till ett policyunderlag som du kan försvara, och skillnaden är värd att förstå innan du skriver en enda brandväggsregel.

Vad en överstyrningsadress egentligen lovar

En klientspecifik överstyrning bär alternativ per klient, inklusive en föredragen tunneladress. Netgate beskriver adressen som en preferens och inte som en reservation, vilket innebär att den dynamiska poolen inte ger upp adressen för någon annan.

Det är oftast okej. En kollision är sällsynt, och klienten får normalt det den bad om, vilket räcker för bekvämlighet och inte för auktorisering. Bekvämlighet och auktorisering är olika krav, och bara ett av dem överlever en kollision.

Med subnätstopologi tar fältet klientadressen tillsammans med servernätets mask, så en adress inuti en 10.90.0.0/24-tunnel skrivs som 10.90.0.10/24.

Inget av det reserverar numret. En klient vars överstyrning inte matchar, eller en dubbel session, kan hamna någon annanstans i poolen, och en regel som bygger på adressen beskriver då någon som inte är där.

Stäng den dynamiska vägen med en avgränsad standard

Alternativet är en enbart statisk server: varje insläppt ändpunkt har sin egen identitet och sin egen unika adress, och inget annat kommer in.

Att genomföra det innebär en DEFAULT-överstyrning begränsad till den enda servern med blockerering av anslutningar aktiverad. En klient utan matchande överstyrning kan då inte falla tillbaka på vanligt dynamiskt insläpp. Den enda raden är det som förvandlar en preferens till en sluten mängd.

Omfånget spelar roll. En standardöverstyrning som tillämpas på varje VPN-instans på maskinen låser ute orelaterade tunnlar, och det felet ser ut som en trasig tjänst snarare än ett policybeslut. Bind den till den enda server vars insläppsmodell du ändrar. Anteckna sedan omfånget i ändringsloggen, eftersom nästa person inte kommer att minnas vilken tunnel den hör till.

Granska hela den tillåtna mängden efteråt. Standardblockeringen rättar inte en namngiven överstyrning som lämnats utan adress, och den ändpunkten kommer helt enkelt inte att ansluta utan en tydlig ledtråd om varför.

Matcha den identitet som servern faktiskt använder

En överstyrning matchar något. På en server som matchar certifikats common names måste överstyrningens namn vara det common name, inte personens visningsnamn. Kopiera det från certifikatet i stället för från kontolistan.

En server som är konfigurerad att använda användarnamnet som common name matchar på en helt annan nyckel, och en överstyrning som är döpt efter certifikatet utlöses aldrig. Läs inställningen i stället för att sluta dig till den från vad kontolistan visar.

Behåll de extra autentiseringsfaktorer som driftsättningen kräver. En sluten adressmodell ändrar vem som får ansluta och vilken adress de får; den ersätter inte certifikatkontrollen eller den andra faktorn.

Skriv åtkomstreglerna när kartan är hållbar

När kartan från identitet till adress är sluten kan regler referera till adresser utan att låtsas att de är personer. Ett alias som grupperar en persons ändpunkter kan nå en specifik tjänst medan ett annat alias når något annat. Aliaset blir det granskningsbara objektet, och adressen blir en implementeringsdetalj inuti det.

Håll destinationer och portar explicita. Att tillåta hela det lokala nätverket från hela tunnelpoolen är precis den konstruktion som övningen skulle ersätta.

Läs floating-, grupp- och gränssnittsregler i deras verkliga utvärderingsordning, eftersom en tidigare bred passage slår ut en senare snäv. Att stänga av intern vidarebefordran mellan klienter håller peer-trafik vid den gräns där dessa regler granskas. En regel som bara finns på papperet är inte efterlevnad.

Testa de negativa fallen

Prova fyra nya anslutningar: en namngiven ändpunkt, en helt utan överstyrning, en tjänst som borde vara nåbar och en som inte borde vara det. Den olistade ändpunkten är det viktiga fallet, eftersom det är den som konstruktionen finns för att stoppa. Om den ansluter gör standardblockeringen inte sitt jobb.

Kontrollera IPv6 separat, eftersom en IPv4-adresspolicy inte säger något om en andra stack. Bekräfta sedan att applikationen fortfarande auktoriserar användaren, eftersom en tunneladress är ett nätverksfaktum och inte bevis på vem som sitter vid tangentbordet. Båda kontrollerna hör i acceptansanteckningen.

Planera till sist migreringen. Nya överstyrningar och snäva regler ändrar inte redan upprättade sessioner i efterhand, så befintliga tillstånd måste löpa ut eller rensas medvetet.