Statické klientské adresy OpenVPN za OPNsense

Jména potřebují adresy, které se nehýbou, a soubor fondu OpenVPN dělá adresu jen přilnavou. Ztraťte ten soubor, nebo znovu vystavte certifikát pod jiným obecným jménem, a vracející se klient přistane jinde ve fondu, zatímco jeho záznam DNS stále ukazuje na starou adresu. Trvalou odpovědí je přepsání specifické pro klienta, které adresu připne, plus širší tunelová síť, aby připnuté adresy ležely mimo dynamický rozsah. Aritmetika, která za tímto rozšířením stojí, je místem, kde žije většina zmatku.

OPNsense drží tato přepsání v nastavení specifickém pro klienta na serveru, klíčovaném obecným jménem certifikátu, což z obecného jména činí součást plánu adres.

Přilnavý pronájem není statická adresa

Soubor fondu zapisuje mapování adres na klienty a vrací je, když se známý klient znovu připojí. To je pohodlí, nikoli smlouva: soubor lze znovu vygenerovat, mapování zmizí, když se změní identita klienta, a dva servery sdílející fond se na něm neshodnou. Přepsání specifické pro klienta funguje jinak, protože adresa pochází z konfigurace, ne z historie. Přežije také restart i reinstalaci zařízení, pokud je přepsání zálohováno spolu se zbytkem konfigurace.

Dynamická alternativa, tedy zapojení VPN do DNS pomocí skriptu pro připojení klienta a dynamických aktualizací, funguje a vyžaduje resolver, který přijímá aktualizace, plus skript při každém připojení. Na zařízení jste omezeni na balíčky, které dodává výrobce, a tam tento plán obvykle končí.

Aritmetika /30, kterou nikdo nemiluje

Při výchozí topologii net30 dostává každý klient svůj vlastní /30: první použitelná adresa jde na stranu serveru, druhá klientovi. Přepsání proto musí ležet mimo dynamickou tunelovou síť serveru, což znamená nejprve tuto síť rozšířit. Server na 10.8.0.0/24 se může posunout na 10.8.0.0/23 a ponechat polovinu starého rozsahu pro dynamické klienty a druhou polovinu pro přepsání. Přidejte původní /24 jako další místní síť IPv4, aby provoz do obou polovin směřoval do tunelu.

Každá adresa přepsání musí padnout na hranici /30, takže poslední oktet je násobkem čtyř. /30 na 10.8.1.0 dá klientovi 10.8.1.2, a to je adresa, kterou nese záznam DNS. Pokud místo toho zvolíte 10.8.1.3, vznikne klient, který se připojí a nedokáže propustit provoz, protože adresa patří podsíti, kterou mu topologie nikdy nepřidělila.

Plán se snáze udržuje, když se přepsání přidělují od horního okraje rozšířeného rozsahu dolů, takže dynamický fond se rozpíná do volného prostoru, místo aby obcházel pevné ostrovy.

Místní sítě a zóna, na kterou se klienti ptají

Provoz mezi klienty potřebuje vlastní povolení. Seznam místních sítí IPv4 na serveru musí obsahovat obě poloviny rozsahu, dynamickou i statickou; bez něj server přijme paket od jednoho klienta a nemá zásadu, která by ho pustila k jinému. Symptom vypadá jako selhání DNS, protože jméno se přeloží a spojení přesto selže. Zkontrolujte současně nastavení komunikace mezi klienty, protože samotná položka místní sítě nepovoluje předávání mezi peery.

Zveřejněte záznamy v zóně, na kterou se vzdálení klienti skutečně ptají. Záznam v zóně obsluhované jen resolverem LAN je neviditelný pro klienta, jehož vložený resolver ukazuje jinam, a přidávání dalších záznamů do špatné zóny to nikdy nespraví. Potvrďte vloženou volbu DNS a vyhledávací doménu než cokoli přidáte.

Co zkontrolovat při novém připojení

Připojte klienta znovu a před testováním čehokoli dalšího potvrďte, že přiřazená adresa odpovídá jeho přepsání. Potom přeložte jméno z druhého klienta a připojte se ke službě podle jména, což společně prověří záznam DNS, trasu i firewall. Potvrďte zpětnou cestu na straně serveru, protože jméno, které se přeloží, zatímco služba zůstává nedostupná, je problém směrování nebo zásad, nikoli pojmenování. Mějte tabulku přepsání vedle seznamu certifikátů, aby se obojí kontrolovalo společně.

Certifikát znovu vystavený pod jiným obecným jménem přestane odpovídat svému přepsání a vrátí klienta do dynamického fondu. Po každé změně identity to očekávejte.