Stabilné adresy OpenVPN by mali sledovať identitu, nie zdrojovú IP

Plány adries, ktoré hovoria „tento notebook dostane 10.90.0.10“, sú v skutočnosti tvrdenia o identite: ktoré overené zariadenie smie držať túto adresu. Aktuálna verejná IP toho zariadenia s tým takmer nič nemá spoločné, pretože NAT a roaming ju menia bez toho, aby menili to, kto je používateľ. Stavba plánu na zdrojovej adrese vytvára pravidlá, ktoré sa rozbijú na prvej hotelovej sieti. Stavba na overenej identite vytvára plán, ktorý prežije cestovanie.

Začnite tým, čo server dokáže overiť, potom rozhodnite, na čo adresa je.

Vyberte kľúč identity pred adresou

Samostatný klientsky certifikát pre každé zariadenie dáva serveru stabilný, overiteľný kľúč pre každého člena, čo je najčistejší základ pre statické priradenie. Nasadenie s overovaním podľa používateľa sa môže namiesto toho oprieť o používateľské meno, ak výber konfigurácie sleduje rovnaké pole. Miešanie oboch modelov vytvára priradenia, ktoré zodpovedajú certifikátu u jedného klienta a používateľskému menu u iného, a nikto nedokáže predpovedať, ktoré vyhrá. Rozhodnite, ktorý kľúč plán používa, skôr než napíšete čo i len jednu rezerváciu.

S duplicate-cn môže niekoľko súčasných relácií predložiť rovnaké spoločné meno, takže jedna pripnutá adresa ich nedokáže identifikovať jednotlivo. To je vlastnosť modelu identity, nie niečo, čo lepší plán adries napraví.

Rezervujte adresy mimo dynamického rozsahu

V sieti s topológiou podsiete, ako je 10.90.0.0/24, ponechajte nízke adresy pre pomenovaných členov a dynamický fond umiestnite do oddeleného rozsahu. Priradenie pre pripnutého člena vyzerá takto ifconfig-push 10.90.0.10 255.255.255.0 v súbore, ktorý server pre danú identitu vyberie. Druhý argument znamená pod net30 niečo iné, takže príklad nie je neutrálny voči topológii. Prečítajte si topológiu, skôr než ho skopírujete.

Trvalosť fondu zaznamenáva nedávne prenájmy a má tendenciu vracať rovnakú adresu, čo je pohodlie, nie rezervácia. Nedovoľte, aby sa súbor trvalosti stal záznamom vlastníctva, pretože sa mení s históriou pripojení, nie s politikou.

Priorita priradenia rozhoduje, kto vyhrá

Príručka dokumentuje poradie: explicitné priradenie vytvorené počas client-connect môže nadobudnúť účinnosť pred položkou client-config-dir, ktorá sama predchádza bežnému prideľovaniu z fondu. Toto poradie vysvetľuje väčšinu hlásení „pripnutá adresa sa neuplatnila“. Znamená tiež, že dynamický alokátor, ktorý zapisuje konfiguráciu pre každú reláciu, môže ticho prepísať statický súbor, ktorý ste považovali za záväzný.

Vyberte jednu vrstvu, ktorá vlastní priradenia, a ostatné urobte iba na čítanie. Dve vrstvy, ktoré obe tvrdia, že rozhodujú, vytvárajú priradenia závislé od času.

Dynamický alokátor potrebuje rovnaký model

Integrácia client-connect, ktorá rozdeľuje adresy pre každú reláciu, je malý alokátor s obvyklými problémami alokátora. Musí overiť identitu žiadateľa, atómovo rezervovať adresu, vydávať iba podporovaný výstup pre pripojenie a uvoľniť rezerváciu pri odpojení alebo zlyhaní. Súbežné požiadavky potrebujú zámok alebo obmedzenie databázy, nie postup čítania a potom zápisu. Bez čistenia fond uniká adresy až do reštartu.

Držte stav alokátora tam, kde si ho ďalší operátor môže prečítať, a logujte rozhodnutie identita-na-adresu, nielen adresu.

Rozhodnite, či je adresa politika alebo pohodlie

Ak pravidlo firewallu alebo trasa povoľuje prevádzku z jednej adresy tunela, adresa sa zúčastňuje prístupovej politiky a opätovné priradenie dedí toto oprávnenie. Koordinujte životný cyklus identity, adresy a firewallu, alebo pravidlo zviažte s niečím, čo nemožno znova priradiť. Stabilné adresovanie robí konfiguráciu čitateľnou; nenahrádza overovanie.

Napíšte plán ako inventár s vlastníkom pri každej položke a potom ho skontrolujte, keď sa zariadenie vyradí. Nepoužitá rezervácia je tá, ktorá sa omylom znova použije.