Adresa statike klientësh OpenVPN pas OPNsense
Një skedar pool e bën një adresë ngjitëse, jo të përhershme. Fiksoni adresat e klientëve me tejkalime, zgjeroni gamën e tunelit për aritmetikën /30 dhe më pas publikojini.
Emrat kanë nevojë për adresa që nuk lëvizin, dhe skedari i pool-it të OpenVPN vetëm e bën një adresë ngjitëse. Humbni atë skedar, ose ri-lëshoni një certifikatë nën një emër të përbashkët tjetër, dhe klienti që kthehet përfundon diku tjetër në pool, ndërsa regjistri i tij DNS vazhdon të tregojë adresën e vjetër. Përgjigja e qëndrueshme është një tejkalim specifik i klientit që e fikson adresën, plus një rrjet tuneli më i gjerë, që adresat e fiksuara të qëndrojnë jashtë gamës dinamike. Aritmetika pas atij zgjerimi është vendi ku jeton pjesa më e madhe e konfuzionit.
OPNsense i mban këto tejkalime te cilësimet specifike të klientit në server, të kyçura me emrin e përbashkët të certifikatës, gjë që e bën emrin e përbashkët pjesë të planit të adresave.
Një qira ngjitëse nuk është adresë statike
Skedari i pool-it shkruan hartëzime adrese-kllient dhe i kthen ato kur një klient i njohur rilidhet. Ky është komoditet, jo kontratë: skedari mund të rigjenerohet, hartëzimi zhduket kur identiteti i klientit ndryshon, dhe dy serverë që ndajnë një pool nuk do të bien dakord për të. Një tejkalim specifik i klientit funksionon ndryshe, sepse adresa vjen nga konfigurimi dhe jo nga historia. Ai i mbijeton gjithashtu një rindezjeje dhe një riinstalimi të pajisjes, me kusht që tejkalimi të ruhet së bashku me pjesën tjetër të konfigurimit.
Alternativa dinamike, lidhja e VPN-së me DNS me një skript lidhjeje klienti dhe përditësime dinamike, funksionon dhe kërkon një zgjidhës që pranon përditësime plus një skript në çdo lidhje. Në një pajisje je i kufizuar te paketat që dërgon shitësi, dhe zakonisht aty ndalon ky plan.
Aritmetika /30 që askujt nuk i pëlqen
Sipas topologjisë standarde net30, çdo klient merr /30-n e vet: adresa e parë e përdorshme shkon te ana e serverit, e dyta te klienti. Prandaj tejkalimet duhet të qëndrojnë jashtë rrjetit dinamik të tunelit të serverit, që do të thotë se ai rrjet duhet zgjeruar së pari. Një server në 10.8.0.0/24 mund të kalojë në 10.8.0.0/23, duke lënë gjysmën e gamës së vjetër për klientët dinamikë dhe gjysmën tjetër për tejkalimet. Shtoni /24 origjinal si rrjet lokal IPv4 shtesë, që trafiku drejt të dy gjysmave të hyjë në tunel.
Çdo adresë tejkalimi duhet të bjerë në një kufi /30, pra okteti i fundit është shumëfish i katërs. Një /30 në 10.8.1.0 i jep klientit 10.8.1.2, dhe kjo është adresa që mban regjistri DNS. Zgjedhja e 10.8.1.3 në vend të kësaj prodhon një klient që lidhet dhe nuk mund të kalojë trafik, sepse adresa i përket një nënrrjeti që topologjia nuk ia caktoi kurrë.
Plani mbahet më lehtë nëse tejkalimet ndahen nga maja e gamës së zgjeruar poshtë, që pool-i dinamik të zgjerohet në hapësirë të lirë në vend të rreth ishujve fiks.
Rrjetet lokale dhe zona që pyesin klientët
Trafiku klient-për-klient ka nevojë për lejen e vet. Lista e rrjeteve lokale IPv4 të serverit duhet të përfshijë të dyja gjysmat e gamës, dinamike dhe statike; pa të, serveri pranon një paketë nga një klient dhe nuk ka politikë që ta lejojë të kalojë te një tjetër. Simptoma lexohet si dështim DNS, sepse emri zgjidhet dhe lidhja prapë dështon. Kontrolloni në të njëjtën kohë cilësimin klient-për-klient, pasi një zë i rrjetit lokal i vetëm nuk mundëson përcjelljen mes palëve.
Publikoni regjistrat në zonën që klientët e largët vërtet e pyesin. Një regjistër në një zonë që shërbehet vetëm nga zgjidhësi i LAN-it është i padukshëm për një klient, zgjidhësi i shtyrë i të cilit tregon diku tjetër, dhe shtimi i më shumë regjistrave në zonën e gabuar nuk e rregullon kurrë atë. Konfirmoni opsionin DNS të shtyrë dhe domenin e kërkimit përpara se të shtoni çdo gjë.
Çfarë të kontrollohet në një lidhje të re
Rilidhni klientin dhe konfirmoni se adresa e caktuar përputhet me tejkalimin e tij përpara se të testoni çdo gjë tjetër. Pastaj zgjidhni emrin nga një klient i dytë dhe lidhuni me shërbimin me emër, që ushtron së bashku regjistrin DNS, rrugën dhe firewall-in. Konfirmoni rrugën e përgjigjes në anën e serverit, sepse një emër që zgjidhet ndërsa shërbimi mbetet i paarritshëm është problem rrugëtimi ose politike, jo emërtimi. Mbani tabelën e tejkalimeve pranë listës së certifikatave, që të dyja të rishikohen bashkë.
Një certifikatë e ri-lëshuar nën një emër të përbashkët tjetër nuk përputhet më me tejkalimin e saj dhe e kthen klientin te pool-i dinamik. Priteni këtë pas çdo ndryshimi identiteti.