Server OpenVPN me nopool: shpallni një interval eksplicit pishine

Ndihmësit e serverit konfigurojnë një nënrrjet dhe më pas e mbushin atë me një pishinë dinamike sipas zgjedhjes së tyre. Ai parazgjedhje është i përshtatshëm derisa disa adresa duhet të mbeten jashtë shpërndarjes — qoftë të rezervuara për caktime fikse, qoftë të mbajtura për një segment të ardhshëm. Shtypja e pishinës automatike dhe shpallja e intervalit vetë kërkon dy rreshta dhe një vendim të vetëdijshëm për adresat që nuk janë për shpërndarje. Pjesa tjetër është disiplinë operacionale: inventar, zbatim, verifikim, kthim pas.

Ky është një ndryshim në një shërbim që punon, prandaj trajtojeni si detyrë operacionale: së pari inventar, më pas zbatim përmes ciklit normal të jetës, verifikim me një klient të ri dhe një kthim pas i përgatitur.

Filloni nga nënrrjeti që keni tashmë

Lexoni konfigurimin aktual të serverit dhe adresat që klientët mbajnë realisht. Ndryshimi i pishinës ka kuptim vetëm kundrejt asaj baze, dhe baza nuk është gjithmonë ajo që sugjeron skedari, sepse një produkt i menaxhuar ose një gjenerues konfigurimi mund të zotërojë skedarin që po lexoni.

grep -nE '^(topology|server|ifconfig-pool|max-clients|client-config-dir)' /etc/openvpn/server/lab.conf
ip -4 addr show tun0

Konfirmoni topologjinë në fuqi. Në topologjinë e nënrrjetit çdo klient merr një adresë nga pishina; planimetritë më të vjetra net30 caktojnë një bllok të vogël për klient dhe aritmetika është krejt e ndryshme. Nëse serveri është ende në net30, kjo faqe është udhëzuesi i gabuar i migrimit dhe numrat e pishinës nuk do të nënkuptojnë atë që prisni. Kontrolloni atë rresht përpara se të kopjoni aritmetikë adresash nga diku tjetër.

Shkruani adresën e vetë serverit, çdo caktim fiks në drejtorinë e konfigurimeve të klientëve dhe çdo adresë nga e cila varet një rrugë ose një rregull aksesi. Këto janë adresat që duhet të mbeten jashtë intervalit dinamik. Shkrimi i tyre së pari është ajo që e bën intervalin vendim dhe jo hamendje. I jep kthimit pas edhe diçka konkrete për të rivendosur.

Shtoni nopool dhe shpallni intervalin

Fjala kyçe ndihmëse pranon nopool, e cila ruan konfigurimin e nënrrjetit dhe shtyp pishinën dinamike automatike, siç përshkruan manual i OpenVPN 2.6. Më pas rreshti eksplicit ifconfig-pool siguron intervalin përfshirës që synoni, dhe maska e tij e rrjetit përputhet me nënrrjetin. Të dy rreshtat i përkasin të njëjtit bllok serveri, sepse një pishinë pa nënrrjetin e saj nuk ka kuptim. Rendi midis tyre ka rëndësi vetëm për lexueshmërinë, pasi ndihmësi e shpalos çiftin kur shërbimi nis.

topology subnet
server 10.70.0.0 255.255.255.0 nopool
ifconfig-pool 10.70.0.50 10.70.0.120 255.255.255.0

Të dy kufijtë janë përfshirës, prandaj shembulli ofron shtatëdhjetë e një adresa. Mbani adresën e serverit dhe çdo caktim fiks jashtë atij intervali; një caktim fiks që bie brenda intervalit dinamik prodhon një përplasje që varet nga radha e lidhjeve, dhe ky është lloji më i keq për korrigjim. Lini një diferencë midis grupit të rezervuar dhe intervalit nëse caktimet fikse ka gjasa të rriten.

Madhësia e intervalit dhe njëkohshmëria janë kufij të ndarë. Njëqind adresa nuk nënkuptojnë njëqind klientë njëkohësisht nëse max-clients thotë ndryshe, dhe një pishinë më e madhe se kufiri i njëkohshmërisë është normale dhe jo shpërdorim. E rëndësishme është që të dy kufijtë të zgjidhen me vetëdije dhe jo të trashëgohen nga një parazgjedhje.

Mbani caktimet fikse jashtë intervalit dinamik

Një ifconfig-push specifik për klient është mekanizëm tjetër nga caktimi i pishinës dhe duhet të përdorë parametra të përshtatshëm për topologjinë aktive. Në modalitetin e nënrrjetit është një adresë e vetme dhe maskë rrjeti; transferimi i një çifti net30 vetëm sepse u shfaq në një shembull të vjetër është gabim i shpeshtë.

Historiku i caktimit është një të dhënë, jo një autoritet. Një skedar persist mban mend cili klient kishte cilën adresë, kështu që klientët që rilidhen priren të marrin të njëjtën, dhe ai nuk rezervon adresa, nuk i liron dhe nuk zëvendëson një caktim fiks. Nëse një pajisje e caktuar duhet të mbajë gjithmonë një adresë të caktuar, përdorni një caktim fiks në vend që të mbështeteni te skedari persist.

Më pas kontrolloni shtigjet që varen nga adresat. Një rrugë e shtyrë te klientët, një rregull muri zjarri që lejon një nënrrjet, ose një kontroll monitorimi që pret një host të caktuar mund të presupozojnë intervalin e vjetër. Ndryshimi i pishinës pa i lexuar i zhvendos dështimin në një vend që duket i palidhur.

Zbatoni përmes ciklit të jetës, pastaj verifikoni

Zbatoni ndryshimin ashtu si shërbimi zakonisht merr konfigurimin — qoftë skedar i drejtpërdrejtë plus rinisje, qoftë shtresë menaxhimi që rigjeneron skedarin. Një redaktim manual në një skedar të gjeneruar mbijeton deri në gjenerimin tjetër, dhe jo më shumë. Regjistroni cili mekanizëm zotëron skedarin, sepse operatori i ardhshëm do të duhet të dijë ku të bëjë të njëjtin ndryshim. Më pas rinisni një herë dhe lexoni regjistrin përpara se të ftoni një klient.

systemctl restart openvpn-server@lab
journalctl -u openvpn-server@lab -n 30 --no-pager
# on a fresh client
ip -4 addr show tun0

Lidhni një klient që nuk ishte lidhur më parë dhe konfirmoni që adresa bie brenda intervalit të shpallur dhe jashtë grupit të rezervuar. Më pas konfirmoni rrugën e kthimit: klienti duhet të arrijë atë që lejon politika dhe asgjë më shumë. Një adresë që përputhet me planin por nuk ka rrugë funksionale nuk është ndryshim i suksesshëm.

Rilidhni një klient që mbante një adresë nga intervali i vjetër. Ai duhet të marrë një adresë nga intervali i ri, dhe çdo gjendje në nivel sesioni e lidhur me adresën e vjetër duhet të ketë zhdukur. Nëse e mban adresën e vjetër, diçka tjetër po ia cakton dhe pishina nuk është pronari që mendoni.

Kthimi pas i një ndryshimi intervali

Mbajini tre rreshtat e mëparshëm në regjistrin e ndryshimeve, jo vetëm skedarin e mëparshëm. Rivendosja e tyre dhe rinisja e kthen caktimin në sjelljen e vjetër, dhe klientët që rilidhen më pas do të marrin adresa prej tij.

Dy paralajmërime i përkasin regjistrit. Klientët tashmë të lidhur kur bëni kthimin pas mbajnë adresat aktuale derisa të rilidhen, kështu që kthimi pas nuk është i menjëhershëm në të gjithë flotën. Dhe nëse intervali i vjetër mbivendosej me një caktim fiks, rivendosja e tij rivendos edhe përplasjen; pikërisht ajo mbivendosje ishte arsyeja e ndryshimit, dhe kërkon një zgjidhje tjetër nga kthimi pas.

Një ndryshim pishine përfundon kur një klient i ri merr një adresë brenda intervalit, një adresë e rezervuar nuk jepet kurrë, dhe rrugët e rregullat që konsumojnë ato adresa vazhdojnë të sillen siç synohet. Çdo gjë më pak ia lë personit të ardhshëm të zbulojë se cila nga të treja nuk është e vërtetë.