OpenVPN client-connect-haak: waar jou adres werklik beland

Om ’n adres uit ’n client-connect-skrip terug te gee, lyk of dit die kliënt se IP moet stel. Dit doen dit nie: die haak se enigste kanaal na die bediener is ’n tydelike lêer waarvan die pad as die skrip se laaste argument aankom, en die adres moet daar in ifconfig-push-sintaksis geskryf word. ’n Skrip wat die adres weergee of met nul afsluit sonder om iets te skryf, lewer ’n gekoppelde kliënt met ’n poeladres, en die bedienerlog lyk heeltemal gesond.

Die verwarring is redelik, want verskeie ander hake praat wel terug deur uittreekoeë of omgewingsveranderlikes. Hierdie een het sy eie kontrak, en die kontrak begin met ’n lêernaam.

Die haak skryf ’n lêer, nie ’n terugkeerwaarde nie

Die verklaring bestaan uit twee reëls: script-security 2 om die oproep toe te laat, dan client-connect /etc/openvpn/server/assign-address.sh. Wanneer ’n kliënt verifieer, voer die bediener daardie skrip uit met die gegenereerde lêerpad as laaste argument bygevoeg, wat slegs $1 is as die verklaring geen ekstra argumente van sy eie deurgee nie. Alles wat op daardie kliënt toegepas word, gaan in daardie lêer as gewone richtlyne, een per reël, presies soos dit in ’n konfigurasie sou verskyn. ’n Wrapper wat sy eie parameters byvoeg, verskuif die posisie, en die klassieke simptoom is ’n skrip wat na ’n pad skryf wat soos --verbose lyk.

Uittree-status is die ander helfte van die kontrak. Nul beteken aanvaar en lees die lêer; enigiets anders verwerp die verbinding, en dit is hoe ’n ongekarteerde identiteit geweier word in plaas daarvan om stilweg na die poel terug te val. Skryf die volledige richtlyn voordat jy sukses teruggee, sodat ’n halfgeskrewe lêer nooit ’n kliënt se konfigurasie word nie.

Twee richtlyne verdien aandag omdat hulle met alles anders in wisselwerking tree. ifconfig-push bepaal die adres, terwyl ’n gestuurde route die kliënt vertel wat deur die tonnel bereikbaar is; gee die eerste terug en vergeet die tweede, en jy kry ’n kliënt met ’n adres en nêrens om heen te gaan. Orde binne die lêer maak nie saak nie, maar volledigheid wel. ’n Haak wat ’n roete vir ’n voorvoegsel stuur wat geen eweknie kan bereik nie, is dieselfde fout van die ander kant gesien.

Insette kom deur omgewingsveranderlikes: common_name, trusted_ip, ifconfig_pool_remote_ip en die res. Behandel hulle almal as stringe van buite die bediener, nooit as skulfragmente nie.

Adrestoewysing is ’n beleid, nie rekenkunde nie

’n Aantreklike kortpad is om die sertifikaatnaam te ontleed en sy syfers as die laaste oktet te gebruik. Dit is nie ’n toewyser nie, en dit misluk op gewone maniere: twee name met dieselfde agtervoegsel bots, ’n naam wat op 300 eindig is nie ’n adres nie, en ’n sertifikaat wat deur ’n administrateur hernoem word, verskuif ’n toestel stilweg. Valideer subnetlidmaatskap, die bruikbare gasheerreik, gereserveerde adresse en uniekheid by elke oproep, en hou die toewysing in ’n tabel wat ’n mens kan lees.

Wie die naam beheer, beheer die adres, so besluit wat common_name eintlik in hierdie ontplooiing verteenwoordig. Met username-as-common-name geaktiveer, is die identiteit die aanmelding eerder as die sertifikaatonderwerp. Moet nooit daardie waarde in skul-evaluering deurgee nie, en moet nooit toelaat dat die kliënt ’n lêerpad beïnvloed nie.

’n Registergesteunde toewyser moet gelyktydigheid oorleef. Reserveer die adres atomies, hanteer ’n mislukte skryf sonder om ’n halfgekonfigureerde kliënt toe te laat, en merk elke toewysing met die verbinding wat dit besit, sodat ’n laat ontkoppeling van ’n ouer sessie nie ’n adres kan vrymaak wat ’n nuwer een reeds hou nie. Verskeie bedienerinstansies wat een poel deel, maak daardie vereiste skerper eerder as opsioneel.

Topologie bepaal wat ifconfig-push beteken

Met topology subnet op 10.77.0.0/24 is ifconfig-push 10.77.0.20 255.255.255.0 ’n adres plus sy netmasker. Onder topology net30 is die tweede argument glad nie ’n netmasker nie, maar die eweknie-adres, so om die subnetvorm op ’n net30-bediener te kopieer, gee jou ’n kliënt wat assosieer en nie verkeer kan deurlaat nie. Verander die topologie doelbewus, nooit om ’n voorbeeld konsekwent te laat lyk nie. ’n Bediener wat reeds net30 gebruik, het lewendige kliënte op die ou adressering, so die oorskakeling is ’n migrasie met ’n onderhoudsvenster, nie ’n eenreël-wysiging nie.

Statiese adresse moet buite die dinamiese poel sit en buite elke ander statiese toewysing, insluitend die wat deur gewone client-config-dir-lêers uitgedeel word. As twee meganismes dieselfde adres vir verskillende kliënte kan produseer, sal een van hulle dit uiteindelik doen.

Toets vier gevalle voordat jy dit vertrou

Voer dieselfde kontroles uit teen ’n gekarteerde identiteit, ’n ongekarteerde een, ’n herverbinding en ’n gesimuleerde registerfout. openvpn --config client.ovpn --verb 4 wys die toegewysde adres in die stuurantwoord, en op die bediener bevestig grep -A2 PUSH_REPLY /var/log/openvpn/openvpn.log wat werklik gestuur is. Vir die ongekarteerde identiteit is die verwagte resultaat ’n verwerpte verbinding, nie ’n poeladres nie.

Kyk dan na die gids waarin die daemon daardie tydelike lêers skryf. Die skrip loop in die afgegradeerde dienskontteks, so ’n pad wat deur root beskryfbaar is maar nie deur die daemon nie, maak elke verbinding ’n verwerping met ’n toestemmingsfout wat verskeie reëls diep in die log begrawe lê.

Toewysing is nie magtiging nie: ’n vasgepen adres verleen steeds nie toegang tot elke bestemming agter die bediener nie. Hou die roetering- en brandmuurbeleid in sy eie laag, en verifieer dit teen die adres wat jy pas vasgestel het.