Stabiilsed OpenVPN-aadressid peaksid järgima identiteeti, mitte lähte-IP-d

Aadressiplaanid, mis ütlevad „see sülearvuti saab 10.90.0.10“, on tegelikult väited identiteedi kohta: milline autenditud seade tohib seda aadressi hoida. Selle seadme praegusel avalikul IP-l pole sellega peaaegu mingit pistmist, sest NAT ja rändlus muudavad seda, muutmata seda, kes on kasutaja. Plaani lähteaadressile ehitamine tekitab reeglid, mis purunevad esimeses hotellivõrgus. Selle autenditud identiteedile ehitamine tekitab plaani, mis peab reisimisele vastu.

Alusta sellest, mida server saab kontrollida, ja otsusta seejärel, milleks aadress on.

Vali identiteedivõti enne aadressi

Eraldi kliendisertifikaat iga seadme jaoks annab serverile iga liikme jaoks stabiilse, kontrollitava võtme, mis on staatilise määramise puhtaim alus. Kasutajapõhist autentimist kasutav juurutus võib selle asemel toetuda kasutajanimele, kui konfiguratsiooni valik järgib sama välja. Kahe mudeli segamine tekitab määramised, mis sobivad ühe kliendi jaoks sertifikaadiga ja teise jaoks kasutajanimega, ja keegi ei suuda ennustada, milline võidab. Otsusta, millist võtit plaan kasutab, enne kui kirjutad ühegi broneeringu.

duplicate-cn korral võivad mitmed samaaegsed seansid esitada sama ühisnime, nii et üks kinnitatud aadress ei saa neid üksikult tuvastada. See on identiteedimudeli omadus, mitte midagi, mida parem aadressiplaan parandada saaks.

Broneeri aadressid väljaspool dünaamilist vahemikku

Alamvõrgu topoloogiaga võrgus nagu 10.90.0.0/24 hoia madalad aadressid nimetatud liikmetele ja pane dünaamiline bassein eraldi vahemikku. Kinnitatud liikme määramine näeb välja selline ifconfig-push 10.90.0.10 255.255.255.0 failis, mille server selle identiteedi jaoks valib. Teine argument tähendab net30 korral midagi muud, seega näide ei ole topoloogia suhtes neutraalne. Loe topoloogiat enne selle kopeerimist.

Basseini püsivus registreerib hiljutised rendid ja kipub sama aadressi tagasi andma, mis on mugavus, mitte broneering. Ära lase püsivusfailil saada omandi registriks, sest see muutub ühenduste ajaloo, mitte poliitika järgi.

Määramise prioriteet otsustab, kes võidab

Käsiraamat dokumenteerib järjestuse: client-connecti ajal loodud selgesõnaline määramine võib jõustuda enne client-config-dir kirjet, mis omakorda eelneb tavapärasele basseini jaotamisele. See järjestus seletab enamikku teateid „kinnitatud aadress ei rakendunud“. See tähendab ka seda, et dünaamiline jaotaja, mis kirjutab seansi kohta konfiguratsiooni, võib vaikselt üle kirjutada staatilise faili, mida pidasid autoriteetseks.

Vali üks kiht, mis määramisi omab, ja tee teised kirjutuskaitstuks. Kaks kihti, mis mõlemad väidavad end otsustavat, tekitavad ajast sõltuvaid määramisi.

Dünaamiline jaotaja vajab sama mudelit

Client-connecti integratsioon, mis jagab aadresse seansi kohta, on väike jaotaja tavaliste jaotaja probleemidega. See peab valideerima taotleva identiteedi, broneerima aadressi aatomiliselt, väljastama ainult toetatud ühendusepõhise väljundi ja vabastama broneeringu lahtiühendamisel või tõrke korral. Samaaegsed taotlused vajavad lukku või andmebaasi piirangut, mitte lugemis-siis-kirjutamise jada. Ilma koristamiseta lekib bassein aadresse kuni taaskäivituseni.

Hoia jaotaja olekut seal, kus järgmine operaator saab seda lugeda, ja logi identiteedi-aadressi otsust, mitte ainult aadressi.

Otsusta, kas aadress on poliitika või mugavus

Kui tulemüürireegel või marsruut lubab liiklust ühest tunneliaadressist, siis osaleb aadress juurdepääsupoliitikas ja ümbermääramine pärib selle loa. Koordineeri identiteedi, aadressi ja tulemüüri elutsüklit või seo reegel millegagi, mida ei saa ümber määrata. Stabiilne adresseerimine muudab konfiguratsiooni loetavaks; see ei asenda autentimist.

Kirjuta plaan inventuurina, kus igal kirjel on omanik, ja vaata see üle, kui seade kasutusest kõrvaldatakse. Kasutamata broneering on see, mida kogemata uuesti kasutatakse.