Statysk OpenVPN-IP per klant: ifconfig-push, net ipp.txt

In rigel yn ipp.txt bewurkje fielt as it reservearjen fan in adres, en dat is it net. Dat triem, neamd troch ifconfig-pool-persist, registrearret hokker adres in mienskiplike namme de lêste kear hie, sadat de pool itselde weromjaan kin as dat gelegen komt. Neat deryn bynt de folgjende ferbining oan dat nûmer.

Fier de kontrôles hjirûnder yn folchoarder út. Elk befêstiget it meganisme of seit dat jo stopje moatte en in ynfier reparearje.

Wêr't it persistentietriem foar is

It triem bestiet om adressen stabyl te hâlden tusken werstarts, wat werferbinen freonliker en logboeken better lêsber makket. It wurdt as skiednis lêzen en as skiednis skreaun, en it tawizingspaad bliuwt frij om in oar adres te kiezen as de hint net past: in oare pool, in konfliktende tawizing of in klant dy't oankaam nei't de pool fol wie. Dêrom kin in hânmjittige bewurking yn it triem perfekt lykje en neat oan de ferbining feroarje. Behannelje it as in cache fan eardere besluten, net as in boarne fan belied.

As jo in spesifyk adres foar in spesifike klant nedich hawwe, is it dokumintearre meganisme ifconfig-push, en it heart yn 'e konfiguraasje dy't dy klant besit.

Kontrolearje dat de juste klant keazen is

In eksplisite tawizing wurdt opsocht op 'e mienskiplike namme fan 'e klant, dus in triem neamd foar de ferkearde identiteit wurdt gewoan nea lêzen. Befêstigje wat de tsjinner as de namme fan dy klant beskôget, benammen dêr't username-as-common-name it nei autentikaasje feroaret. Befêstigje dan dat de triemnamme krekt mei dy wearde oerienkomt, ynklusyf haadletters.

Tink oan gelijktidigens wylst jo hjir binne. As duplicate-cn tastien is, kinne ferskate apparaten deselde identiteit foarlizze, en ien fêst adres kin net foar allegear unyk wêze. Beslis oft it fêste adres it wurdich is om tagelyk sesjes foar dy identiteit te wegerjen, want dy twa easken kinne net tagelyk foldien wurde.

Kontrolearje dat de nûmers by de topology passe

De betsjutting fan 'e arguminten hinget fan 'e tunnel-topology ôf, en hjir rjochtet in kopiearre foarbyld de measte skea oan. Yn 'e âldere net30-regeling beset elke klant in blok fan fjouwer adressen, dus de push leveret in pear adressen. Yn subnet-topology krijt de klant ien adres plus it masker fan 'e pool, en de pearfoarm is ferkeard. Lês de topology út 'e rinnende konfiguraasje foardat jo de rigel skriuwe.

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

Kontrolearje it adres tsjin al it oare dat it hawwe koe: in oare eksplisite tawizing, it berik fan 'e dynamyske pool en elke statyske rûte dy't in fêste host ferûnderstelt. In adres dat de pool oerlaapet sil wurkje oant de pool it oan immen oars jout, en dy flater sil tafallich lykje.

Kontrolearje it resultaat op in nije ferbining

In besteande sesje hâldt it adres dat it krige, dus de iennichste sinfolle test is in nije ferbining. Ferbreek de klant, ferbyn wer, en lês it adres dat it eins krige tegearre mei de rûtes dy't dermei oankamen. As it adres noch dynamysk is, is de tawizing net tapast, en de folgjende stap is it sykjen yn 'e konfiguraasje, net noch in bewurking fan it skiednistriem.

Hâld it bewiis byinoar: de klantnamme, it triem dat oerienkaam, it tawiisde adres en de pool dêr't it wei kaam.

Ta beslút, in fêst tunneladres is net in apparaatbepiis. It jout in plak yn it adresplan oan, wylst autentikaasje noch op it sertifikaat en it akkount rêstet. De twa trochinoar helje makket fan in adreskonflikt in feiligensoanfame dy't nimmen opskreaun hat.