Statika OpenVPN-IP por ĉiu kliento: ifconfig-push, ne ipp.txt

Redakti linion en ipp.txt sentiĝas kiel rezervi adreson, sed ĝi ne estas tio. Tiu dosiero, nomita de ifconfig-pool-persist, registras kiun adreson komuna nomo havis lastfoje, por ke la baseno povu redoni la saman kiam tio oportunas. Nenio en ĝi ligas la sekvan konekton al tiu numero.

Plenumu la subajn kontrolojn laŭ ordo. Ĉiu el ili aŭ konfirmas la mekanismon aŭ diras al vi halti kaj ripari enigon.

Por kio utilas la persisteco-dosiero

La dosiero ekzistas por teni adresojn stabilaj inter restartoj, kio faras rekonektojn pli afablaj kaj protokolojn pli facile legeblaj. Ĝi estas legata kiel historio kaj skribata kiel historio, kaj la atribua vojo restas libera elekti alian adreson kiam la sugesto ne taŭgas: alia baseno, konflikta atribuo aŭ kliento alveninta post kiam la baseno pleniĝis. Tial permana redakto povas aspekti perfekta en la dosiero kaj ŝanĝi nenion pri la konekto. Traktu ĝin kiel kaŝmemoron de pasintaj decidoj, ne kiel fonton de politiko.

Se vi bezonas specifan adreson por specifa kliento, la dokumentita mekanismo estas ifconfig-push, kaj ĝi apartenas al la agordo, kiu posedas tiun klienton.

Kontrolu, ke la ĝusta kliento estas elektita

Eksplicita atribuo estas serĉata laŭ la komuna nomo de la kliento, do dosiero nomita laŭ la malĝusta identeco simple neniam estas legata. Konfirmu, kion la servilo konsideras la nomon de tiu kliento, precipe kie username-as-common-name ŝanĝas ĝin post aŭtentigo. Poste konfirmu, ke la dosiernomo ekzakte kongruas kun tiu valoro, inkluzive de uskleco.

Pripensu samtempecon dum vi estas ĉi tie. Se duplicate-cn estas permesita, pluraj aparatoj povas prezenti la saman identecon, kaj unu fiksa adreso ne povas esti unika por ĉiuj. Decidu, ĉu la fiksa adreso indas malakcepti samtempajn seancojn por tiu identeco, ĉar tiuj du postuloj ne povas esti plenumitaj kune.

Kontrolu, ke la numeroj kongruas kun la topologio

La signifo de la argumentoj dependas de la tunela topologio, kaj ĝuste ĉi tie kopiita ekzemplo faras la plej grandan damaĝon. En la pli malnova aranĝo net30 ĉiu kliento okupas blokon de kvar adresoj, do la push liveras paron da adresoj. En la subreta topologio la kliento ricevas unu adreson plus la maskon de la baseno, kaj la para formo estas malĝusta. Legu la topologion el la funkcianta agordo antaŭ ol skribi la linion.

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

Kontrolu la adreson kontraŭ ĉio alia, kio povus posedi ĝin: alia eksplicita atribuo, la gamo de la dinamika baseno kaj ajna statika vojo, kiu supozas fiksan gastiganton. Adreso, kiu interkovras la basenon, funkcios ĝis la baseno donos ĝin al iu alia, kaj tiu fiasko aspektos hazarda.

Kontrolu la rezulton per nova konekto

Ekzistanta seanco konservas la adreson, kiun ĝi ricevis, do la sola signifa testo estas nova konekto. Malkonektu la klienton, rekonektu kaj legu la adreson, kiun ĝi efektive ricevis, kune kun la vojoj, kiuj alvenis kun ĝi. Se la adreso ankoraŭ estas dinamika, la atribuo ne estis aplikita, kaj la sekva paŝo estas la serĉado en la agordo, ne plia redakto de la historio-dosiero.

Tenu la pruvojn kune: la klienta nomo, la dosiero, kiu kongruis, la atribuita adreso kaj la baseno, el kiu ĝi venis.

Fine, fiksa tunela adreso ne estas aparata legitimilo. Ĝi indikas lokon en la adresa plano, dum aŭtentigo ankoraŭ apogas sin sur la atestilo kaj la konto. Konfuzi la du igas adresan konflikton sekureca supozo, kiun neniu skribis.