OpenVPN client-connect-hoko: kien via adreso efektive iras

Redoni adreson el client-connect-skripto aspektas kvazaŭ ĝi devus agordi la IP de la kliento. Ĝi ne faras tion: la sola kanalo de la hoko al la servilo estas provizora dosiero, kies vojo alvenas kiel la lasta argumento de la skripto, kaj la adreso devas esti skribita tie en la sintakso de ifconfig-push. Skripto, kiu presas la adreson aŭ eliras kun nulo sen skribi ion ajn, produktas konektitan klienton kun adreso el la naĝejo, kaj la servila protokolo aspektas tute sana.

La konfuzo estas komprenebla, ĉar pluraj aliaj hokoj ja respondas per elirkodoj aŭ medivariabloj. Ĉi tiu havas sian propran kontrakton, kaj la kontrakto komenciĝas per dosiernomo.

La hoko skribas dosieron, ne redonan valoron

La deklaro estas du linioj: script-security 2 por permesi la vokon, poste client-connect /etc/openvpn/server/assign-address.sh. Kiam kliento aŭtentiĝas, la servilo lanĉas tiun skripton kun la generita dosierovojo aldonita kiel la lasta argumento, kiu estas $1 nur se la deklaro mem ne pasas proprajn pliajn argumentojn. Ĉio aplikata al tiu kliento iras en tiun dosieron kiel ordinaraj direktivoj, unu por linio, precize kiel ili aperus en agordo. Ĉirkaŭvolvaĵo, kiu aldonas proprajn parametrojn, ŝovas la pozicion, kaj la klasika simptomo estas skripto skribanta al vojo, kiu aspektas kiel --verbose.

Elirstatuso estas la alia duono de la kontrakto. Nulo signifas akcepti kaj legi la dosieron; io ajn alia rifuzas la konekton, kaj tiel identeco sen mapado estos rifuzata anstataŭ silente fali reen en la naĝejon. Skribu la kompletan direktivon antaŭ ol redoni sukceson, por ke duone skribita dosiero neniam fariĝu la agordo de kliento.

Du direktivoj meritaj atenton, ĉar ili interagas kun ĉio alia. ifconfig-push fiksas la adreson, dum puŝita route diras al la kliento, kio estas atingebla tra la tunelo; redonu la unuan kaj forgesu la duan kaj vi ricevas klienton kun adreso kaj nenien irenda. La ordo ene de la dosiero ne gravas, sed la kompleteco gravas. Hoko, kiu puŝas itineron por prefikso, kiun neniu samtavolano povas atingi, estas la sama eraro vidata de la alia fino.

Enigoj alvenas per medivariabloj: common_name, trusted_ip, ifconfig_pool_remote_ip kaj la ceteraj. Traktu ilin ĉiujn kiel ĉenojn de ekster la servilo, neniam kiel ŝelajn fragmentojn.

Adresmapado estas politiko, ne aritmetiko

Tentiga fuŝsolvo estas analizi la atestilan nomon kaj uzi ĝiajn ciferojn kiel la lastan oktetojn. Tio ne estas alokilo, kaj ĝi malsukcesas laŭ ordinaraj manieroj: du nomoj kun la sama sufikso kolizias, nomo finiĝanta per 300 ne estas adreso, kaj atestilo renomita de administranto silente movas aparaton. Validigu subretan membrecon, la uzeblan gastigantan intervalon, rezervitajn adresojn kaj unikecon ĉe ĉiu voko, kaj konservu la mapadon en tabelo, kiun homo povas legi.

Kiu regas la nomon, regas la adreson, do decidu, kion common_name efektive reprezentas en ĉi tiu deplojo. Kun username-as-common-name ŝaltita, la identeco estas la ensaluto anstataŭ la atestila subjekto. Neniam pasigu tiun valoron en ŝelan pritakson, kaj neniam lasu la klienton influi dosierovojon.

Registre subtenata alokilo devas postvivi samtempecon. Rezervu la adreson atome, traktu malsukcesan skribon sen akcepti duone agorditan klienton, kaj marku ĉiun alokon per la konekto, kiu posedas ĝin, por ke malfrua malkonekto de pli malnova seanco ne povu liberigi adreson, kiun pli nova jam tenas. Pluraj servilaj instancoj dividantaj unu naĝejon akrigas tiun postulon anstataŭ igi ĝin laŭvola.

Topologio decidas, kion signifas ifconfig-push

Kun topology subnet sur 10.77.0.0/24, ifconfig-push 10.77.0.20 255.255.255.0 estas adreso plus ĝia retmasko. Sub topology net30 la dua argumento tute ne estas retmasko sed la samtavolana adreso, do kopii la subretan formon al net30-servilo donas al vi klienton, kiu konektiĝas kaj ne povas trapasi trafikon. Ŝanĝu la topologion intence, neniam por igi ekzemplon aspekti kohera. Servilo jam funkcianta kun net30 havas vivajn klientojn sur la malnova adresado, do la ŝanĝo estas migrado kun bontenada fenestro, ne unulinia redakto.

Staticaj adresoj devas situi ekster la dinamika naĝejo kaj ekster ĉiu alia statika asigno, inkluzive tiujn donitajn de ordinaraj client-config-dir-dosieroj. Se du mekanismoj povas produkti la saman adreson por malsamaj klientoj, unu el ili eventuale faros tion.

Testu kvar kazojn antaŭ ol fidi ĝin

Rulu la samajn kontrolojn kontraŭ mapita identeco, nemapita, rekonekto kaj simulita registra fiasko. openvpn --config client.ovpn --verb 4 montras la asignitan adreson en la puŝa respondo, kaj sur la servilo grep -A2 PUSH_REPLY /var/log/openvpn/openvpn.log konfirmas, kio efektive estis sendita. Por la nemapita identeco la atendata rezulto estas rifuzita konekto, ne adreso el la naĝejo.

Poste inspektu la dosierujon, en kiun la demono skribas tiujn provizorajn dosierojn. La skripto ruliĝas en la malaltigita serva kunteksto, do vojo skribebla de root sed ne de la demono transformas ĉiun konekton en rifuzon kun permesa eraro kaŝita kelkajn liniojn malsupre en la protokolo.

Aloko ne estas rajtigo: fiksita adreso ankoraŭ ne donas aliron al ĉiu celloko malantaŭ la servilo. Tenu la enrutan kaj fajroŝirman politikon en sia propra tavolo, kaj kontrolu ĝin kontraŭ la adreso, kiun vi ĵus fiksis.