Redaktimi i një rreshti në ipp.txt duket si rezervim adrese, por nuk është. Ai skedar, i emërtuar nga ifconfig-pool-persist, regjistron se çfarë adrese kishte një emër i përbashkët herën e fundit, në mënyrë që grupi të mund të kthejë të njëjtën kur është e përshtatshme. Asgjë në të nuk e lidh lidhjen tjetër me atë numër.

Kryeni kontrollet më poshtë sipas radhës. Secila ose konfirmon mekanizmin ose ju thotë të ndaleni dhe të rregulloni një hyrje.

Për çfarë shërben skedari i qëndrueshmërisë

Skedari ekziston për t'i mbajtur adresat të qëndrueshme midis rinisjeve, gjë që i bën rilidhjet më miqësore dhe regjistrat më të lehtë për t'u lexuar. Lexohet si histori dhe shkruhet si histori, dhe rruga e alokimit mbetet e lirë të zgjedhë një adresë tjetër kur sugjerimi nuk përshtatet: një grup tjetër, një caktim në konflikt ose një klient që erdhi pasi grupi u mbush. Prandaj një redaktim manual mund të duket i përsosur në skedar dhe të mos ndryshojë asgjë në lidhje. Trajtojeni si një cache të vendimeve të shkuara, jo si burim politike.

Nëse ju nevojitet një adresë e caktuar për një klient të caktuar, mekanizmi i dokumentuar është ifconfig-push, dhe ai i përket konfigurimit që zotëron atë klient.

Verifikoni që është zgjedhur klienti i saktë

Një caktim i qartë kërkohet sipas emrit të përbashkët të klientit, kështu që një skedar i emërtuar për identitetin e gabuar thjesht nuk lexohet kurrë. Konfirmoni çfarë konsideron serveri si emrin e atij klienti, veçanërisht aty ku username-as-common-name e ndryshon atë pas vërtetimit. Pastaj konfirmoni që emri i skedarit përputhet saktësisht me atë vlerë, duke përfshirë shkronjat e mëdha dhe të vogla.

Mendoni për njëkohshmërinë ndërsa jeni këtu. Nëse duplicate-cn lejohet, disa pajisje mund të paraqesin të njëjtin identitet, dhe një adresë fikse nuk mund të jetë unike për të gjitha. Vendosni nëse adresa fikse ia vlen të refuzohen sesionet e njëkohshme për atë identitet, sepse këto dy kërkesa nuk mund të plotësohen njëkohësisht.

Verifikoni që numrat përputhen me topologjinë

Kuptimi i argumenteve varet nga topologjia e tunelit, dhe pikërisht këtu një shembull i kopjuar shkakton dëmin më të madh. Në rregullimin më të vjetër net30 çdo klient zë një bllok prej katër adresash, kështu që push ofron një palë adresa. Në topologjinë e nënrrjetit klienti merr një adresë plus maskën e grupit, dhe forma e palës është e gabuar. Lexoni topologjinë nga konfigurimi që po ekzekutohet përpara se të shkruani rreshtin.

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

Kontrolloni adresën kundrejt çdo gjëje tjetër që mund ta zotërojë: një caktim tjetër i qartë, diapazoni i grupit dinamik dhe çdo rrugë statike që supozon një host fiks. Një adresë që mbivendoset me grupin do të funksionojë derisa grupi t'ia japë dikujt tjetër, dhe ai dështim do të duket i rastësishëm.

Verifikoni rezultatin në një lidhje të re

Një sesion ekzistues mban adresën që iu dha, kështu që testi i vetëm kuptimplotë është një lidhje e re. Shkëputni klientin, rilidhuni dhe lexoni adresën që mori në të vërtetë së bashku me rrugët që erdhën me të. Nëse adresa është ende dinamike, caktimi nuk u zbatua, dhe hapi tjetër është kërkimi në konfigurim, jo një redaktim tjetër i skedarit të historisë.

Mbani provat së bashku: emrin e klientit, skedarin që u përputh, adresën e caktuar dhe grupin nga i cili erdhi.

Së fundi, një adresë fikse tuneli nuk është kredencial i pajisjes. Ajo shënon një vend në planin e adresave, ndërsa vërtetimi ende mbështetet në certifikatë dhe në llogari. Ngatërrimi i të dyjave e kthen një konflikt adresash në një supozim sigurie që askush nuk e shkroi.

Artikuj të ngjashëm