OpenVPN client-connect-haak: wêr't jo adres eins bedarret

In adres weromjaan út in client-connect-skript liket it IP fan 'e klant yn te stellen. Dat docht it net: it iennichste kanaal fan 'e haak nei de tsjinner is in tydlik bestân waans paad as lêste argumint fan it skript binnenkomt, en it adres moat dêr skreaun wurde yn ifconfig-push-syntaksis. In skript dat it adres printet of mei nul ôfslút sûnder eat te skriuwen, makket in ferbûne klant mei in adres út 'e pool, en it tsjinnerloch sjocht der folslein sûn út.

De betizing is ridlik, om't ferskate oare hakken wol weromprate fia exitkoaden of omjouwingsfariabelen. Dizze hat syn eigen kontrakt, en it kontrakt begjint mei in bestânsnamme.

De haak skriuwt in bestân, net in weromjefwearde

De ferklearring is twa rigels: script-security 2 om de oprop ta te stean, dan client-connect /etc/openvpn/server/assign-address.sh. As in klant autentisearret, rint de tsjinner dat skript mei it generearre bestânspaad as lêste argumint tafoege, dat allinnich $1 is as de ferklearring gjin eigen ekstra arguminten trochjout. Alles wat op dy klant tapast wurdt, giet yn dat bestân as gewoane rjochtlinen, ien per rigel, krekt sa't se yn in konfiguraasje ferskine soene. In wrapper dy't syn eigen parameters tafoeget, ferskoot de posysje, en it klassike symptoom is in skript dat nei in paad skriuwt dat op --verbose liket.

Exitstatus is de oare helte fan it kontrakt. Nul betsjut akseptearje en it bestân lêze; al it oare wiist de ferbining ôf, en sa wurdt in net-mappe identiteit wegere yn plak fan stil werom te fallen op 'e pool. Skriuw de folsleine rjochtline foardat jo sukses weromjaan, sadat in heal skreaun bestân nea de konfiguraasje fan in klant wurdt.

Twa rjochtlinen fertsjinje oandacht, om't se mei al it oare ynteraksje hawwe. ifconfig-push fêstiget it adres, wylst in stjoerde route de klant fertelt wat troch de tunnel berikber is; jaan de earste werom en ferjit de twadde en jo krije in klant mei in adres en nergens om hinne te gean. De oarder yn it bestân makket neat út, mar folsleinens wol. In haak dy't in rûte stjoert foar in foarheaksel dêr't gjin peer komme kin, is deselde flater fan 'e oare kant sjoen.

Ynfier komt fia omjouwingsfariabelen: common_name, trusted_ip, ifconfig_pool_remote_ip en de rest. Behannelje se allegear as strings fan bûten de tsjinner, nea as shell-fragminten.

Adrestapassing is in belied, net rekkenjen

In ferlokjende koarte wei is it sertifikaatnamme te ûntlieden en syn sifers as lêste okteet te brûken. Dat is gjin taskenner, en it mislearret op gewoane manieren: twa nammen mei deselde efterheaksel botsje, in namme dy't op 300 einiget is gjin adres, en in sertifikaat dat in behearder omneamt, ferpleatst stil in apparaat. Falidearje subnetlidmaatskip, it brûkbere hostberik, reservearre adressen en unisiteit by elke oprop, en hâld de tapassing yn in tabel dy't in minske lêze kin.

Wa't de namme kontrolearret, kontrolearret it adres, dus beslute wat common_name yn dizze útrulling eins fertsjintwurdiget. Mei username-as-common-name ynskeakele is de identiteit de oanmelding ynstee fan it sertifikaatûnderwerp. Jou dy wearde nea troch oan shell-evaluaasje, en lit de klant nea in bestânspaad beynfloedzje.

In register-basearre taskenner moat konkurrearjendheid oerlibje. Reservearje it adres atomysk, behannelje in mislearre skriuwwerking sûnder in heal konfigurearre klant ta te litten, en markearje elke tawizing mei de ferbining dy't der eigenier is, sadat in lette ôfbrekking fan in âldere sesje gjin adres frijmeitsje kin dat in nijere al hat. Ferskate tsjinner-eksimplaren dy't ien pool diele meitsje dy eask skerper ynstee fan opsjoneel.

Topology beslút wat ifconfig-push betsjut

Mei topology subnet op 10.77.0.0/24 is ifconfig-push 10.77.0.20 255.255.255.0 in adres plus syn netmasker. Under topology net30 is it twadde argumint hielendal gjin masker mar it peer-adres, dus it subnetfoarm kopiearje nei in net30-tsjinner jout jo in klant dy't ferbynt en gjin ferkear trochlitte kin. Feroarje de topology mei opsetsin, nea om in foarbyld konsekwint lykje te litten. In tsjinner dy't al net30 draait, hat libbene klanten op 'e âlde adressearring, dus de omskeakeling is in migraasje mei in ûnderhâldsfinster, net in ienrigelige bewurking.

Statyske adressen moatte bûten de dynamyske pool stean en bûten elke oare statyske tawizing, ynklusyf dy't troch gewoane client-config-dir-bestannen útjûn wurde. As twa meganismen itselde adres foar ferskate klanten produsearje kinne, sil ien fan har dat úteinlik dwaan.

Test fjouwer gefallen foardat jo it fertrouwe

Rin deselde kontrôles tsjin in mappe identiteit, in net-mappe, in werferbining en in simulearre registerflater. openvpn --config client.ovpn --verb 4 toant it tawiisde adres yn it push-antwurd, en op 'e tsjinner befêstiget grep -A2 PUSH_REPLY /var/log/openvpn/openvpn.log wat eins stjoerd is. Foar de net-mappe identiteit is it ferwachte resultaat in wegere ferbining, net in pooladres.

Undersykje dan de map dêr't de daemon dy tydlike bestannen yn skriuwt. It skript rint yn 'e ferlege tsjinstkontekst, dus in paad dêr't root yn skriuwe kin mar de daemon net, makket elke ferbining ta in ôfwizing mei in tastimmingflater begroeven ferskate rigels leger yn it loch.

Tawizing is gjin autorisaasje: in fêstset adres jout noch altyd gjin tagong ta elke bestimming efter de tsjinner. Hâld it routing- en firewallbelied yn syn eigen laach, en ferifiearje it tsjin it adres dat jo krekt fêstset hawwe.