Statiska OpenVPN-klientadresser bakom OPNsense
En poolfil gör en adress klibbig, inte permanent. Fäst klientadresser med åsidosättningar, utöka tunnelområdet för /30-aritmetiken och publicera dem sedan.
Namn behöver adresser som inte flyttar sig, och OpenVPN:s poolfil gör bara en adress klibbig. Tappa den filen, eller utfärda ett certifikat på nytt under ett annat vanligt namn, och klienten som återvänder hamnar någon annanstans i poolen medan dess DNS-post fortfarande pekar på den gamla adressen. Det hållbara svaret är en klientspecifik åsidosättning som fäster adressen, plus ett bredare tunnelnätverk så att fästa adresser ligger utanför det dynamiska intervallet. Aritmetiken bakom den utökningen är där det mesta av förvirringen bor.
OPNsense håller dessa åsidosättningar i serverns klientspecifika inställningar, nycklade på certifikatets vanliga namn, vilket gör det vanliga namnet till en del av adressplanen.
En klibbig lease är inte en statisk adress
Poolfilen skriver adress-till-klient-mappningar och lämnar tillbaka dem när en känd klient återansluter. Det är bekvämlighet, inte ett kontrakt: filen kan återskapas, mappningen försvinner när klientens identitet ändras, och två servrar som delar en pool kommer inte att vara överens om den. En klientspecifik åsidosättning fungerar annorlunda, eftersom adressen kommer från konfigurationen i stället för från historiken. Den överlever också en omstart och en ominstallation av enheten, förutsatt att åsidosättningen säkerhetskopieras tillsammans med resten av konfigurationen.
Det dynamiska alternativet, att koppla in VPN:en i DNS med ett klientanslutningsskript och dynamiska uppdateringar, fungerar och kräver en resolver som accepterar uppdateringar plus ett skript vid varje anslutning. På en enhet är du begränsad till de paket som leverantören skickar, och det är vanligtvis där den planen stannar.
/30-aritmetiken ingen gillar
Under standardtopologin net30 får varje klient sin egen /30: den första användbara adressen går till serversidan, den andra till klienten. Åsidosättningar måste därför ligga utanför serverns dynamiska tunnelnätverk, vilket innebär att nätverket först måste utökas. En server på 10.8.0.0/24 kan flyttas till 10.8.0.0/23 och lämna halva det gamla intervallet till dynamiska klienter och andra halvan till åsidosättningar. Lägg till det ursprungliga /24 som ett extra lokalt IPv4-nätverk så att trafik till båda halvorna går in i tunneln.
Varje åsidosättningsadress måste landa på en /30-gräns, så den sista oktetten är en multipel av fyra. En /30 på 10.8.1.0 ger klienten 10.8.1.2, och det är adressen som DNS-posten bär. Att välja 10.8.1.3 i stället ger en klient som ansluter och inte kan släppa igenom trafik, eftersom adressen tillhör ett subnät som topologin aldrig tilldelade den.
Planen är lättare att hålla om åsidosättningar fördelas uppifrån det utökade intervallet och nedåt, så att den dynamiska poolen expanderar i ledigt utrymme i stället för runt fasta öar.
Lokala nätverk och zonen klienterna frågar
Klient-till-klient-trafik behöver sitt eget tillstånd. Serverns lista över lokala IPv4-nätverk måste omfatta båda halvorna av intervallet, dynamisk och statisk; utan den tar servern emot ett paket från en klient och har ingen policy som släpper igenom det till en annan. Symtomet läses som ett DNS-fel, eftersom namnet löses upp och anslutningen ändå misslyckas. Kontrollera klient-till-klient-inställningen samtidigt, eftersom en post för lokalt nätverk ensam inte aktiverar vidarebefordran mellan jämlikar.
Publicera posterna i zonen som fjärrklienter faktiskt frågar. En post i en zon som bara betjänas av LAN-resolvern är osynlig för en klient vars pushade resolver pekar någon annanstans, och fler poster i fel zon reparerar aldrig det. Bekräfta det pushade DNS-alternativet och sökdomänen innan du lägger till något.
Vad du bör kontrollera vid en ny anslutning
Anslut klienten igen och bekräfta att den tilldelade adressen matchar dess åsidosättning innan du testar något annat. Lös sedan upp namnet från en andra klient och anslut till tjänsten via namn, vilket prövar DNS-posten, rutten och brandväggen tillsammans. Bekräfta svarvägen på serversidan, eftersom ett namn som löses upp medan tjänsten förblir oåtkomlig är ett rutt- eller policyproblem och inte ett namngivningsproblem. Håll åsidosättningstabellen bredvid certifikatlistan så att båda granskas tillsammans.
Ett certifikat som utfärdas på nytt under ett annat vanligt namn slutar matcha sin åsidosättning och skickar tillbaka klienten till den dynamiska poolen. Förvänta dig det efter varje identitetsändring.