OpenVPN client-connect-haak: kuhu sinu aadress tegelikult läheb

Aadressi tagastamine client-connect skriptist näib olevat see, mis peaks määrama kliendi IP. Ei ole: haagi ainus kanal serverini on ajutine fail, mille tee saabub skripti viimase argumendina, ja aadress tuleb sinna kirjutada ifconfig-push süntaksis. Skript, mis prindib aadressi või väljub nulliga midagi kirjutamata, loob ühendatud kliendi, kellel on aadress basseinist, ja serveri logi näeb täiesti terve välja.

Segadus on mõistetav, sest mitmed teised haagid vastavad tõesti väljumiskoodide või keskkonnamuutujate kaudu. Sellel on oma leping ja leping algab failinimega.

Haak kirjutab faili, mitte tagastusväärtust

Deklaratsioon on kaks rida: script-security 2, et kutsung lubada, seejärel client-connect /etc/openvpn/server/assign-address.sh. Kui klient autendib, käivitab server selle skripti, lisades genereeritud failitee viimase argumendina, mis on $1 ainult siis, kui deklaratsioon ise lisaga argumente ei anna. Kõik, mida sellele kliendile rakendatakse, läheb sellesse faili tavaliste direktiividena, üks rea kohta, täpselt nii, nagu need konfiguratsioonis esineksid. Ümbris, mis lisab oma parameetrid, nihutab positsiooni, ja klassikaline sümptom on skript, mis kirjutab teele, mis näeb välja nagu --verbose.

Väljumisstaatus on lepingu teine pool. Null tähendab aktsepteeri ja loe fail; mis tahes muu lükkab ühenduse tagasi, ja nii keeldutakse kaardistamata identiteedist, selle asemel et vaikselt basseini tagasi langeda. Kirjuta täielik direktiiv enne edu tagastamist, et pooleldi kirjutatud fail ei saaks kunagi kliendi konfiguratsiooniks.

Kaks direktiivi väärib tähelepanu, sest need mõjutavad kõike muud. ifconfig-push fikseerib aadressi, samal ajal kui saadetud route ütleb kliendile, mis on tunneli kaudu kättesaadav; tagasta esimene ja unusta teine ning saad kliendi, kellel on aadress ja kuhugi minna pole. Järjekord faili sees ei loe, aga täielikkus loeb. Haak, mis saadab marsruudi prefiksile, kuhu ükski partner ei ulatu, on sama viga teisest otsast vaadatuna.

Sisendid saabuvad keskkonnamuutujate kaudu: common_name, trusted_ip, ifconfig_pool_remote_ip ja ülejäänud. Käsitle neid kõiki serveriväliste stringidena, mitte kunagi kestafragmentidena.

Aadresside kaardistamine on poliitika, mitte aritmeetika

Ahvatlev otsetee on sõeluda sertifikaadi nime ja kasutada selle numbreid viimase oktetina. See ei ole jaotur ja see ebaõnnestub tavalistel viisidel: kaks sama sufiksiga nime põrkuvad, 300-ga lõppev nimi ei ole aadress ja administraatori ümbernimetatud sertifikaat liigutab seadet vaikselt. Valideeri alamvõrgu kuuluvust, kasutatavat hostivahemikku, reserveeritud aadresse ja unikaalsust igal kõnel, ja hoia kaardistust tabelis, mida inimene saab lugeda.

Kes kontrollib nime, kontrollib aadressi, seega otsusta, mida common_name selles juurutuses tegelikult esindab. Kui username-as-common-name on lubatud, on identiteet sisselogimine, mitte sertifikaadi subjekt. Ära kunagi anna seda väärtust kesta hindamisse ja ära kunagi lase kliendil failiteed mõjutada.

Registril põhinev jaotur peab vastu pidama samaaegsusele. Reserveeri aadress aatomiliselt, käsitle ebaõnnestunud kirjutamist ilma pooleldi konfigureeritud klienti lubamata ja märgi iga eraldus ühendusega, mis seda omab, et vanema sessiooni hiline katkestus ei saaks vabastada aadressi, mida uuem juba hoiab. Mitmed serveriinstantsid, mis jagavad üht basseini, teevad selle nõude teravamaks, mitte valikuliseks.

Topoloogia määrab, mida ifconfig-push tähendab

Kui topology subnet on 10.77.0.0/24 peal, on ifconfig-push 10.77.0.20 255.255.255.0 aadress pluss selle võrgumask. topology net30 all ei ole teine argument üldse mask, vaid partneri aadress, nii et alamvõrgu kuju kopeerimine net30 serverisse annab kliendi, mis ühendub ja ei suuda liiklust läbi lasta. Muuda topoloogiat teadlikult, mitte kunagi selleks, et näide näeks ühtlane välja. Server, mis juba töötab net30-ga, omab vanal adresseerimisel elusaid kliente, seega on lülitus hooldusaknaga migratsioon, mitte üherealeline muudatus.

Staatilised aadressid peavad asuma väljaspool dünaamilist basseini ja väljaspool iga teist staatilist eraldust, sealhulgas neid, mida jagavad tavalised client-config-dir failid. Kui kaks mehhanismi suudavad erinevatele klientidele sama aadressi toota, teeb üks neist seda lõpuks.

Testi nelja juhtumit, enne kui seda usaldad

Käivita samad kontrollid kaardistatud identiteedi, kaardistamata identiteedi, taasühenduse ja simuleeritud registritõrke vastu. openvpn --config client.ovpn --verb 4 näitab eraldatud aadressi push-vastuses ja serveris kinnitab grep -A2 PUSH_REPLY /var/log/openvpn/openvpn.log, mida tegelikult saadeti. Kaardistamata identiteedi puhul on oodatav tulemus tagasilükatud ühendus, mitte basseini aadress.

Seejärel uurige kataloogi, kuhu deemon need ajutised failid kirjutab. Skript töötab alandatud teenusekontekstis, seega tee, kuhu root saab kirjutada, aga deemon mitte, muudab iga ühenduse tagasilükkamiseks, mille lubatuse viga on logis mitme rea sügavusel maetud.

Eraldamine ei ole autoriseerimine: kinnitatud aadress ei anna ikka juurdepääsu igale sihtkohale serveri taga. Hoia marsruutimis- ja tulemüüripoliitika oma kihis ning kontrolli seda äsja fikseeritud aadressi vastu.