Statická IP pro každého klienta OpenVPN: ifconfig-push, ne ipp.txt

Úprava řádku v ipp.txt vypadá jako rezervace adresy, ale není to tak. Tento soubor, pojmenovaný ifconfig-pool-persist, zaznamenává, jakou adresu mělo společné jméno naposledy, aby fond mohl vrátit stejnou adresu, když se to hodí. Nic v něm nepoutá další připojení k tomuto číslu.

Proveďte níže uvedené kontroly v pořadí. Každá buď potvrdí mechanismus, nebo vám řekne, abyste se zastavili a opravili vstup.

K čemu soubor perzistence slouží

Soubor existuje proto, aby adresy zůstaly stabilní mezi restarty, což činí opětovná připojení příjemnějšími a protokoly čitelnějšími. Čte se jako historie a zapisuje se jako historie a alokační cesta zůstává volná zvolit jinou adresu, když nápověda nesedí: jiný fond, konfliktní přiřazení nebo klient, který dorazil poté, co se fond zaplnil. Proto může ruční úprava vypadat v souboru dokonale a na připojení nic nezměnit. Berte jej jako mezipaměť minulých rozhodnutí, ne jako zdroj pravidel.

Pokud potřebujete konkrétní adresu pro konkrétního klienta, dokumentovaným mechanismem je ifconfig-push a patří do konfigurace, která tohoto klienta vlastní.

Ověřte, že je vybrán správný klient

Explicitní přiřazení se vyhledává podle společného jména klienta, takže soubor pojmenovaný podle špatné identity se prostě nikdy nepřečte. Ověřte, co server považuje za jméno tohoto klienta, zejména tam, kde je username-as-common-name po autentizaci změní. Poté ověřte, že název souboru přesně odpovídá této hodnotě, včetně velikosti písmen.

Zamyslete se nad souběžností, dokud jste tady. Pokud je povoleno duplicate-cn, může několik zařízení předložit stejnou identitu a jedna pevná adresa nemůže být jedinečná pro všechna. Rozhodněte, zda pevná adresa stojí za odmítnutí souběžných relací pro tuto identitu, protože tyto dva požadavky nelze splnit současně.

Ověřte, že čísla odpovídají topologii

Význam argumentů závisí na topologii tunelu a právě zde kopírovaný příklad napáchá nejvíc škody. Ve starším uspořádání net30 zabírá každý klient blok čtyř adres, takže push dodává dvojici adres. V topologii podsítě klient dostane jednu adresu plus masku fondu a tvar dvojice je špatný. Přečtěte si topologii z běžící konfigurace, než řádek napíšete.

# /etc/openvpn/ccd/partner-a   (subnet topology)
ifconfig-push 10.44.0.61 255.255.255.0

Ověřte adresu proti všemu ostatnímu, co by ji mohlo vlastnit: jinému explicitnímu přiřazení, rozsahu dynamického fondu a jakékoli statické trase, která předpokládá pevného hostitele. Adresa, která se překrývá s fondem, bude fungovat, dokud ji fond nepředá někomu jinému, a to selhání bude vypadat náhodně.

Ověřte výsledek na novém připojení

Existující relace si ponechává adresu, kterou dostala, takže jediným smysluplným testem je nové připojení. Odpojte klienta, připojte se znovu a přečtěte adresu, kterou skutečně obdržel, spolu s trasami, které s ní přišly. Pokud je adresa stále dynamická, přiřazení se neuplatnilo a dalším krokem je hledání v konfiguraci, ne další úprava souboru historie.

Uchovávejte důkazy pohromadě: název klienta, soubor, který odpovídal, přidělenou adresu a fond, ze kterého přišla.

Nakonec, pevná adresa tunelu není přihlašovací údaj zařízení. Označuje místo v plánu adres, zatímco autentizace stále stojí na certifikátu a účtu. Záměna obojího mění konflikt adres na bezpečnostní předpoklad, který nikdo nezapsal.