Grepa client-connect e OpenVPN: ku shkon në të vërtetë adresa juaj

Kthimi i një adrese nga një skript client-connect duket sikur duhet të vendosë IP-në e klientit. Nuk e bën: kanali i vetëm i grepës drejt serverit është një skedar i përkohshëm, rruga e të cilit vjen si argumenti i fundit i skriptit, dhe adresa duhet të shkruhet atje në sintaksën ifconfig-push. Një skript që printon adresën ose del me zero pa shkruar asgjë prodhon një klient të lidhur me një adresë nga pishina, dhe regjistri i serverit duket krejt i shëndoshë.

Konfuzioni është i arsyeshëm, sepse disa grepa të tjera vërtet përgjigjen përmes kodeve të daljes ose variablave të mjedisit. Kjo ka kontratën e vet, dhe kontrata fillon me një emër skedari.

Grepa shkruan një skedar, jo një vlerë kthimi

Deklarata është dy rreshta: script-security 2 për të lejuar thirrjen, pastaj client-connect /etc/openvpn/server/assign-address.sh. Kur një klient autentikohet, serveri ekzekuton atë skript me rrugën e skedarit të gjeneruar të shtuar si argumenti i fundit, i cili është $1 vetëm nëse deklarata nuk kalon argumente shtesë të vetat. Çdo gjë që zbatohet për atë klient shkon në atë skedar si direktiva të zakonshme, një për rresht, saktësisht si do të shfaqeshin në një konfigurim. Një mbështjellës që shton parametrat e vet e zhvendos pozicionin, dhe simptoma klasike është një skript që shkruan në një rrugë që duket si --verbose.

Statusi i daljes është gjysma tjetër e kontratës. Zero do të thotë prano dhe lexo skedarin; çdo gjë tjetër e refuzon lidhjen, dhe kështu një identitet i pa hartuar refuzohet në vend që të bjerë në heshtje përsëri në pishinë. Shkruani direktivën e plotë përpara se të ktheni sukses, që një skedar i shkruar gjysmë të mos bëhet kurrë konfigurimi i një klienti.

Dy direktiva meritojnë vëmendje sepse ndërveprojnë me gjithçka tjetër. ifconfig-push fikson adresën, ndërsa një route e dërguar i tregon klientit çfarë është e arritshme përmes tunelit; kthejeni të parën dhe harroni të dytën dhe merrni një klient me adresë dhe pa ku të shkojë. Rendi brenda skedarit nuk ka rëndësi, por plotësia ka. Një grep që dërgon një rrugë për një prefiks ku asnjë palë nuk mund të arrijë është i njëjti gabim i parë nga ana tjetër.

Hyrjet vijnë përmes variablave të mjedisit: common_name, trusted_ip, ifconfig_pool_remote_ip dhe pjesa tjetër. Trajtojini të gjitha si vargje nga jashtë serverit, kurrë si fragmente shell.

Hartimi i adresave është politikë, jo aritmetikë

Një shkurtore joshëse është të analizoni emrin e certifikatës dhe të përdorni shifrat e saj si okteti i fundit. Ky nuk është një alokues dhe dështon në mënyra të zakonshme: dy emra me të njëjtin prapashtesë përplasen, një emër që mbaron me 300 nuk është adresë, dhe një certifikatë e riemërtuar nga një administrator zhvendos në heshtje një pajisje. Validoni anëtarësimin në nënrrjet, gamën e hosteve të përdorshme, adresat e rezervuara dhe unicitetin në çdo thirrje, dhe mbani hartimin në një tabelë që një njeri mund ta lexojë.

Kush kontrollon emrin kontrollon adresën, prandaj vendosni çfarë përfaqëson në të vërtetë common_name në këtë vendosje. Me username-as-common-name të aktivizuar, identiteti është hyrja dhe jo subjekti i certifikatës. Asnjëherë mos e kaloni atë vlerë në vlerësimin e shell, dhe asnjëherë mos lejoni që klienti të ndikojë në një rrugë skedari.

Një alokues i mbështetur në regjistër duhet t'i mbijetojë konkurrencës. Rezervoni adresën në mënyrë atomike, trajtoni një shkrim të dështuar pa pranuar një klient gjysmë të konfiguruar, dhe etiketoni çdo alokim me lidhjen që e zotëron, që një shkëputje e vonë nga një sesion më i vjetër të mos mund të lirojë një adresë që një më i ri tashmë mban. Disa instanca serveri që ndajnë një pishinë e bëjnë atë kërkesë më të mprehtë, jo opsionale.

Topologjia vendos çfarë do të thotë ifconfig-push

Me topology subnet në 10.77.0.0/24, ifconfig-push 10.77.0.20 255.255.255.0 është një adresë plus maskën e saj të rrjetit. Nën topology net30 argumenti i dytë nuk është aspak maskë, por adresa e palës, kështu që kopjimi i formës së nënrrjetit në një server net30 ju jep një klient që lidhet dhe nuk mund të kalojë trafik. Ndryshoni topologjinë me qëllim, kurrë që një shembull të duket i qëndrueshëm. Një server që tashmë ekzekuton net30 ka klientë të gjallë në adresimin e vjetër, prandaj ndërrimi është një migrim me dritare mirëmbajtjeje, jo një ndryshim i një rreshti.

Adresat statike duhet të qëndrojnë jashtë pishinës dinamike dhe jashtë çdo caktimi tjetër statik, përfshirë ato që shpërndahen nga skedarët e zakonshëm client-config-dir. Nëse dy mekanizma mund të prodhojnë të njëjtën adresë për klientë të ndryshëm, njëri prej tyre përfundimisht do ta bëjë këtë.

Provoni katër raste përpara se t'i besoni

Ekzekutoni të njëjtat kontrolle mbi një identitet të hartuar, një të pahartuar, një rilidhje dhe një dështim të simuluar të regjistrit. openvpn --config client.ovpn --verb 4 tregon adresën e caktuar në përgjigjen push, dhe në server grep -A2 PUSH_REPLY /var/log/openvpn/openvpn.log konfirmon çfarë u dërgua në të vërtetë. Për identitetin e pahartuar rezultati i pritur është një lidhje e refuzuar, jo një adresë nga pishina.

Pastaj inspektoni drejtorinë ku daemoni shkruan ata skedarë të përkohshëm. Skripti ekzekutohet në kontekstin e shërbimit të ulur, prandaj një rrugë e shkruajtshme nga root por jo nga daemoni e kthen çdo lidhje në një refuzim me një gabim leje të varrosur disa rreshta më poshtë në regjistër.

Caktimi nuk është autorizim: një adresë e fiksuar ende nuk jep akses në çdo destinacion pas serverit. Mbani politikën e rrugëzimit dhe të murit të zjarrit në shtresën e vet, dhe verifikojeni kundrejt adresës që sapo fiksuat.