OpenVPN client-connect-koukku: minne osoitteesi todella menee

Osoitteen palauttaminen client-connect-skriptistä näyttää siltä, että sen pitäisi asettaa asiakkaan IP. Ei aseta: koukun ainoa kanava palvelimeen on väliaikaistiedosto, jonka polku saapuu skriptin viimeisenä argumenttina, ja osoite on kirjoitettava sinne ifconfig-push-syntaksilla. Skripti, joka tulostaa osoitteen tai päättyy nollaan kirjoittamatta mitään, tuottaa yhdistetyn asiakkaan, jolla on allasosoite, ja palvelimen loki näyttää täysin terveeltä.

Sekoannus on ymmärrettävää, koska useat muut koukut todella vastaavat poistumiskoodien tai ympäristömuuttujien kautta. Tällä on oma sopimuksensa, ja sopimus alkaa tiedostonimellä.

Koukku kirjoittaa tiedoston, ei paluuarvoa

Määrittely on kaksi riviä: script-security 2 sallimaan kutsu, sitten client-connect /etc/openvpn/server/assign-address.sh. Kun asiakas todennetaan, palvelin suorittaa tuon skriptin lisäämällä luodun tiedostopolun viimeiseksi argumentiksi, joka on $1 vain jos määrittely ei välitä omia lisäargumenttejaan. Kaikki kyseiseen asiakkaaseen sovellettava menee tuohon tiedostoon tavallisina direktiiveinä, yksi per rivi, täsmälleen kuten ne näkyisivät määrityksessä. Kääre, joka lisää omat parametrinsa, siirtää sijaintia, ja klassinen oire on skripti, joka kirjoittaa polkuun, joka näyttää --verbose-polulta.

Poistumistila on sopimuksen toinen puoli. Nolla tarkoittaa hyväksy ja lue tiedosto; mikä tahansa muu hylkää yhteyden, ja näin kartoittamaton identiteetti hylätään sen sijaan, että se vaipuisi hiljaa takaisin altaaseen. Kirjoita täydellinen direktiivi ennen onnistumisen palauttamista, jotta puoliksi kirjoitettu tiedosto ei koskaan tule asiakkaan määritykseksi.

Kaksi direktiiviä ansaitsee huomiota, koska ne vaikuttavat kaikkeen muuhun. ifconfig-push kiinnittää osoitteen, kun taas lähetetty route kertoo asiakkaalle, mikä on tunnelin kautta saavutettavissa; palauta ensimmäinen ja unohda toinen, niin saat asiakkaan, jolla on osoite ja jolla ei ole minne mennä. Järjestys tiedoston sisällä ei ole tärkeä, mutta täydellisyys on. Koukku, joka lähettää reitin etuliitteelle, johon mikään vertaisvastaanottaja ei pääse, on sama virhe toisesta päästä nähtynä.

Syötteet tulevat ympäristömuuttujien kautta: common_name, trusted_ip, ifconfig_pool_remote_ip ja loput. Käsittele niitä kaikkia palvelimen ulkopuolisina merkkijonoina, älä koskaan komponentteina kuoressa.

Osoitteiden kartoitus on käytäntö, ei aritmetiikkaa

Houkutteleva oikotie on jäsentää varmenteen nimi ja käyttää sen numeroita viimeisenä oktettina. Se ei ole allokoija, ja se epäonnistuu tavallisilla tavoilla: kaksi samalla loppuliitteellä olevaa nimeä törmäävät, 300:een päättyvä nimi ei ole osoite, ja järjestelmänvalvojan uudelleen nimeämä varmenne siirtää laitetta hiljaa. Validoi aliverkon jäsenyys, käytettävä isäntäväli, varatut osoitteet ja yksilöllisyys joka kutsulla, ja pidä kartoitus taulukossa, jonka ihminen voi lukea.

Joka hallitsee nimeä, hallitsee osoitetta, joten päätä, mitä common_name tässä käyttöönotossa todella edustaa. Kun username-as-common-name on käytössä, identiteetti on kirjautuminen eikä varmenteen subjekti. Älä koskaan välitä tuota arvoa kuoren arviointiin äläkä koskaan anna asiakkaan vaikuttaa tiedostopolkuun.

Rekisteripohjaisen allokoijan on kestettävä samanaikaisuus. Varaa osoite atomaarisesti, käsittele epäonnistunut kirjoitus hyväksymättä puoliksi määritettyä asiakasta ja merkitse jokainen varaus yhteydellä, joka sen omistaa, jotta vanhemman istunnon myöhäinen katkaisu ei voi vapauttaa osoitetta, jonka uudempi jo pitää. Useat palvelininstanssit, jotka jakavat yhden altaan, tekevät vaatimuksesta terävämmän eivätkä valinnaisen.

Topologia päättää, mitä ifconfig-push tarkoittaa

Kun topology subnet on 10.77.0.0/24:ssä, ifconfig-push 10.77.0.20 255.255.255.0 on osoite plus sen verkkopeite. topology net30 -tilassa toinen argumentti ei ole lainkaan peite vaan vastapuolen osoite, joten aliverkkomuodon kopioiminen net30-palvelimeen antaa asiakkaan, joka liittyy eikä pysty välittämään liikennettä. Vaihda topologia tarkoituksella, ei koskaan siksi, että esimerkki näyttäisi johdonmukaiselta. Palvelimella, joka jo pyörittää net30:tä, on eläviä asiakkaita vanhassa osoitteistuksessa, joten vaihto on huoltokatkon vaativa migraatio, ei yhden rivin muokkaus.

Staattisten osoitteiden on sijaittava dynaamisen altaan ulkopuolella ja jokaisen muun staattisen varauksen ulkopuolella, mukaan lukien ne, joita tavalliset client-config-dir-tiedostot jakavat. Jos kaksi mekanismia voi tuottaa saman osoitteen eri asiakkaille, toinen niistä lopulta tekee niin.

Testaa neljä tapausta ennen kuin luotat siihen

Aja samat tarkistukset kartoitettua identiteettiä, kartoittamatonta, uudelleenyhdistämistä ja simuloitua rekisterivirhettä vastaan. openvpn --config client.ovpn --verb 4 näyttää annetun osoitteen push-vastauksessa, ja palvelimella grep -A2 PUSH_REPLY /var/log/openvpn/openvpn.log vahvistaa, mitä todella lähetettiin. Kartoittamattoman identiteetin odotettu tulos on hylätty yhteys, ei allasosoite.

Tarkastele sitten hakemistoa, johon taustaprosessi kirjoittaa ne väliaikaistiedostot. Skripti ajetaan alennetussa palvelukontekstissa, joten polku, johon root voi kirjoittaa mutta taustaprosessi ei, muuttaa jokaisen yhteyden hylkäykseksi, jonka käyttöoikeusvirhe on haudattu useita rivejä alemmas lokiin.

Varaus ei ole valtuutus: kiinnitetty osoite ei silti anna pääsyä jokaiseen palvelimen takana olevaan kohteeseen. Pidä reititys- ja palomuurikäytäntö omassa kerroksessaan ja tarkista se juuri kiinnittämääsi osoitetta vastaan.