Stabilām OpenVPN adresēm jāseko identitātei, nevis avota IP

Adrešu plāni, kuros teikts «šis portatīvais dators saņem 10.90.0.10», patiesībā ir apgalvojumi par identitāti: kura autentificētā ierīce drīkst turēt šo adresi. Šīs ierīces pašreizējā publiskā IP ar to gandrīz nav saistīta, jo NAT un viesabonēšana to maina, nemainot to, kas ir lietotājs. Veidojot plānu uz avota adresi, rodas noteikumi, kas sabrūk pirmajā viesnīcas tīklā. Veidojot to uz autentificētās identitātes, rodas plāns, kas pārdzīvo ceļošanu.

Sāciet ar to, ko serveris var pārbaudīt, pēc tam izlemiet, kam adrese ir domāta.

Izvēlieties identitātes atslēgu pirms adreses

Atsevišķs klienta sertifikāts katrai ierīcei serverim dod stabilu, pārbaudāmu atslēgu katram dalībniekam, un tas ir vistīrākais statiskas piešķiršanas pamats. Izvietojums, kurā izmanto autentifikāciju pēc lietotāja, var tā vietā balstīties uz lietotājvārdu, ja konfigurācijas izvēle seko tam pašam laukam. Abu modeļu sajaukšana rada piešķīrumus, kuros vienam klientam atbilst sertifikāts, bet citam — lietotājvārds, un neviens nevar paredzēt, kurš uzvarēs. Izlemiet, kuru atslēgu plāns izmanto, pirms rakstāt pat vienu rezervāciju.

Ar duplicate-cn vairākas vienlaicīgas sesijas var uzrādīt vienu un to pašu kopējo nosaukumu, tāpēc viena piesprausta adrese nevar tās identificēt atsevišķi. Tā ir identitātes modeļa īpašība, nevis kaut kas, ko labāks adrešu plāns varētu izlabot.

Rezervējiet adreses ārpus dinamiskā diapazona

Tīklā ar apakštīkla topoloģiju, piemēram, 10.90.0.0/24, atstājiet zemās adreses nosauktajiem dalībniekiem un ievietojiet dinamiski baseinu atsevišķā diapazonā. Piesprausta dalībnieka piešķīrums izskatās šādi ifconfig-push 10.90.0.10 255.255.255.0 failā, kuru serveris izvēlas šai identitātei. Otrais arguments saskaņā ar net30 nozīmē ko citu, tāpēc piemērs nav neitrāls pret topoloģiju. Izlasiet topoloģiju pirms tā kopēšanas.

Baseina noturība reģistrē nesenās nomās un mēdz atgriezt to pašu adresi, kas ir ērtība, nevis rezervācija. Neļaujiet noturības failam kļūt par īpašumtiesību reģistru, jo tas mainās līdz ar savienojumu vēsturi, nevis politiku.

Piešķīruma prioritāte izšķir, kurš uzvarēs

Rokasgrāmata dokumentē kārtību: skaidra piešķīrums, kas ģenerēts client-connect laikā, var stāties spēkā pirms client-config-dir ieraksta, kas savukārt ir pirms parastās baseina sadales. Šī kārtība izskaidro lielāko daļu ziņojumu «piespraustā adrese netika piemērota». Tas arī nozīmē, ka dinamisks piešķīrējs, kas raksta katrai sesijai konfigurāciju, var klusi pārrakstīt statisku failu, kuru uzskatījāt par autoritatīvu.

Izvēlieties vienu slāni, kas pārvalda piešķīrumus, un pārējos padariet tikai lasāmus. Divi slāņi, kuri abi apgalvo, ka izlemj, rada piešķīrumus, kas ir atkarīgi no laika.

Dinamiskam piešķīrējam vajadzīgs tas pats modelis

Client-connect integrācija, kas izdala adreses katrai sesijai, ir mazs piešķīrējs ar ierastajām piešķīrēja problēmām. Tam jāvalidē pieprasītāja identitāte, atomiski jārezervē adrese, jāizvada tikai atbalstītā savienojuma izvade un jāatbrīvo rezervācija atvienošanas vai kļūmes gadījumā. Vienlaicīgiem pieprasījumiem vajadzīgs bloķējums vai datubāzes ierobežojums, nevis lasīšanas-un-tad-rakstīšanas secība. Bez tīrīšanas baseins noplūdina adreses līdz restartam.

Turiet piešķīrēja stāvokli tur, kur nākamais operators to var izlasīt, un reģistrējiet lēmumu identitāte-uz-adresi, nevis tikai adresi.

Izlemiet, vai adrese ir politika vai ērtība

Ja ugunsmūra noteikums vai maršruts atļauj satiksmi no vienas tuneļa adreses, tad adrese piedalās piekļuves politikā un pārpiešķiršana pārmanto šo atļauju. Saskaņojiet identitātes, adreses un ugunsmūra dzīves ciklu vai piesaistiet noteikumu kaut kam, ko nevar pārpiešķirt. Stabila adresācija padara konfigurāciju lasāmu; tā neaizstāj autentifikāciju.

Rakstiet plānu kā inventāru ar īpašnieku katram ierakstam, pēc tam pārskatiet to, kad ierīce tiek izņemta no ekspluatācijas. Neizmantotā rezervācija ir tā, kas nejauši tiek izmantota atkārtoti.