OpenVPN client-connect kabliukas: kur iš tikrųjų patenka jūsų adresas

Adreso grąžinimas iš client-connect scenarijaus atrodo taip, tarsi jis turėtų nustatyti kliento IP. Bet nenustato: vienintelis kabliuko kanalas į serverį yra laikinas failas, kurio kelias ateina kaip paskutinis scenarijaus argumentas, o adresas turi būti įrašytas ten su ifconfig-push sintakse. Scenarijus, kuris atspausdina adresą arba baigia nuliu nieko neįrašęs, sukuria prisijungusį klientą su adresu iš baseino, o serverio žurnalas atrodo visiškai sveikas.

Sumišimas suprantamas, nes keli kiti kabliukai tikrai atsako per išėjimo kodus arba aplinkos kintamuosius. Šis turi savo sutartį, o sutartis prasideda failo vardu.

Kabliukas rašo failą, o ne grąžinamą reikšmę

Deklaracija yra dvi eilutės: script-security 2, kad būtų leistas kvietimas, tada client-connect /etc/openvpn/server/assign-address.sh. Kai klientas autentifikuojasi, serveris vykdo tą scenarijų, pridėdamas sugeneruotą failo kelią kaip paskutinį argumentą, kuris yra $1 tik tuo atveju, jei deklaracija neperduoda savo papildomų argumentų. Viskas, kas taikoma tam klientui, įrašoma tame faile kaip įprastos direktyvos, po vieną eilutėje, lygiai taip, kaip jos atrodytų konfigūracijoje. Apvalkalas, pridedantis savo parametrus, pastumia poziciją, o klasikinis simptomas yra scenarijus, rašantis į kelią, panašų į --verbose.

Išėjimo būsena yra antroji sutarties pusė. Nulis reiškia priimti ir skaityti failą; bet kas kita atmeta ryšį, ir taip nesukartotas tapatumas atmetamas, o ne tyliai grįžta į baseiną. Parašykite visą direktyvą prieš grąžindami sėkmę, kad pusiau įrašytas failas niekada netaptų kliento konfigūracija.

Dvi direktyvos nusipelno dėmesio, nes jos sąveikauja su viskuo kitu. ifconfig-push fiksuoja adresą, o išsiųsta route pasako klientui, kas pasiekiama per tunelį; grąžinkite pirmąją ir pamirškite antrąją ir gausite klientą su adresu ir be kur eiti. Tvarka faile neturi reikšmės, bet išsamumas turi. Kabliukas, siunčiantis maršrutą priešdėliui, kurio negali pasiekti joks partneris, yra ta pati klaida, matoma iš kitos pusės.

Įvestis ateina per aplinkos kintamuosius: common_name, trusted_ip, ifconfig_pool_remote_ip ir kitus. Su visais jais elkitės kaip su eilutėmis iš serverio išorės, niekada kaip su shell fragmentais.

Adresų susiejimas yra politika, o ne aritmetika

Viliojantis trumpinys yra išnagrinėti sertifikato vardą ir naudoti jo skaitmenis kaip paskutinį oktetą. Tai ne paskirstytojas, ir ji nepavyksta įprastais būdais: du vardai su tuo pačiu galūne susiduria, vardas, pasibaigiantis 300, nėra adresas, o administratoriaus pervadintas sertifikatas tyliai perkelia įrenginį. Kiekvieno kvietimo metu tikrinkite priklausymą potinkliui, naudojamą hostų diapazoną, rezervuotus adresus ir unikalumą, o susiejimą laikykite lentelėje, kurią žmogus gali perskaityti.

Kas valdo vardą, tas valdo adresą, todėl nuspręskite, ką common_name iš tikrųjų reiškia šiame diegime. Kai įjungtas username-as-common-name, tapatumas yra prisijungimas, o ne sertifikato subjektas. Niekada neperduokite šios reikšmės shell vertinimui ir niekada neleiskite klientui daryti įtakos failo keliui.

Registru paremtas paskirstytojas turi atlaikyti konkurenciją. Rezervuokite adresą atomiškai, tvarkykite nepavykusį įrašymą nepriimdami pusiau sukonfigūruoto kliento ir pažymėkite kiekvieną paskirstymą jį valdančiu ryšiu, kad vėlyvas senesnės sesijos atsijungimas negalėtų atlaisvinti adreso, kurį jau turi naujesnė. Keli serverio egzemplioriai, bendrinantys vieną baseiną, šį reikalavimą daro aštresnį, o ne pasirenkamą.

Topologija nusprendžia, ką reiškia ifconfig-push

Kai 10.77.0.0/24 tinkle naudojama topology subnet, ifconfig-push 10.77.0.20 255.255.255.0 yra adresas ir jo tinklo kaukė. Esant topology net30, antrasis argumentas visai ne kaukė, o partnerio adresas, todėl nukopijavus potinklio formą į net30 serverį gaunamas klientas, kuris prisijungia ir negali praleisti srauto. Keiskite topologiją sąmoningai, niekada ne tam, kad pavyzdys atrodytų nuoseklus. Serveris, kuris jau veikia su net30, turi gyvų klientų sename adresavime, todėl perjungimas yra migracija su techninės priežiūros lange, o ne vienos eilutės pataisa.

Statiniai adresai turi būti už dinaminio baseino ribų ir už kiekvieno kito statinio priskyrimo ribų, įskaitant tuos, kuriuos išduoda įprasti client-config-dir failai. Jei du mechanizmai gali sukurti tą patį adresą skirtingiems klientams, vienas iš jų galiausiai tai padarys.

Išbandykite keturis atvejus prieš juo pasitikėdami

Paleiskite tas pačias patikras susietam tapatumui, nesusietam, prisijungimui iš naujo ir imituotam registro gedimui. openvpn --config client.ovpn --verb 4 rodo priskirtą adresą push atsakyme, o serveryje grep -A2 PUSH_REPLY /var/log/openvpn/openvpn.log patvirtina, kas iš tikrųjų buvo išsiųsta. Nesusieto tapatumo atveju laukiamas rezultatas yra atmestas ryšys, o ne baseino adresas.

Tada patikrinkite katalogą, į kurį demonas rašo tuos laikinus failus. Scenarijus vykdomas sumažinto paslaugos kontekste, todėl kelias, į kurį root gali rašyti, o demonas ne, kiekvieną ryšį paverčia atmetimu su leidimų klaida, palaidota keliomis eilutėmis žemiau žurnale.

Priskyrimas nėra autorizacija: užfiksuotas adresas vis tiek nesuteikia prieigos prie kiekvienos paskirties už serverio. Laikykite maršrutizavimo ir ugniasienės politiką savo sluoksnyje ir patikrinkite ją pagal ką tik užfiksuotą adresą.