OpenVPN push-peer-info: merkitse asiakkaat antamatta pääsyä

Käyttöönottotunnisteet ovat tavallinen syy siihen, miksi ihmiset tarttuvat tähän ominaisuuteen: jokaisen yhteyden pitäisi kantaa jotain sivuston tai roolin kaltaista, ja palvelimen pitäisi lukea se keksimättä toista tunnistetietomuotoa. Yhteisön OpenVPN:ssä mekanismi on jo olemassa, ja se on pieni. Kipeä osa on odotukset. Tavallisen muuttujan asettaminen asiakasprofiiliin ei tee palvelimella mitään, ja perille tuleva arvo todistaa vain, että asiakas lähetti sen.

Tämä on ohje toimivaan polkuun, varmistusvaiheeseen, joka näyttää mitä todella saapui, ja peruutukseen, joka ei jätä puoliksi määritettyä koukkua. Mikään tässä ei vaadi uutta varmennetta, uutta liitännäistä tai protokollalaajennusta.

Aseta muuttuja ja ota polku käyttöön

Kaksi riviä tekevät työn asiakasprofiilissa, ja molemmat tarvitaan. Ilman ensimmäistä ei ole mitään lähetettävää; ilman toista asiakas ei tarjoa vertaistietoja lainkaan. Järjestyksellä ei ole väliä, ja se kannattaa tietää, koska kaksi riviä päätyvät usein luodun profiilin eri osiin. Tärkeää on, että molemmat selviävät kaikesta, mikä kirjoittaa profiilin uudelleen ennen kuin asiakas lukee sen.

setenv UV_DEPLOY field-support
push-peer-info

Etuliite UV_ ei ole koriste. Tavallinen DEPLOY-muuttuja pysyy asiakasprosessin paikallisena eikä sitä koskaan välitetä, kun taas etuliitteinen muoto on nimiavaruus, jonka protokolla varaa käyttäjän määrittämille kentille. Jätä muu hyväksytty profiili koskemattomaksi ja varmista ennen käyttöönottoa, että käyttöönottamasi asiakasbuild tukee molempia direktiivejä.

Yksi käytännön tarkistus kuuluu tähän eikä loppuun: varmista, että direktiivi saavuttaa asiakkaan binäärin eikä jonkin kääreen nielemänä. Graafinen asiakas, joka luo oman komentorivinsä, tai hallintaliittymä, joka lataa tallennetun profiilin uudelleen, voi pudottaa rivejä, joita se ei tunnista. Jos palvelin ei näe mitään, tämä on ensimmäinen paikka katsoa.

Lue kenttä palvelimen koukusta

Palvelimen puolella vastaanotetut vertaistiedot validoidaan ja lisätään yhteyden työnkulun ympäristöön, ja juuri se tekee niistä luettavia koukusta ilman omaa protokollatyötä. Palvelimen ei tarvitse jäsentää ohjauskanavaa tai tallentaa mitään puolestasi; arvo on yksinkertaisesti läsnä, kun yhteyttä muodostetaan. Minimaalinen client-connect-skripti, joka kirjaa tunnisteen todennetun nimen viereen, näyttää tältä.

#!/bin/sh
# /etc/openvpn/server/hooks/label.sh
printf '%s %s\n' "$common_name" "${UV_DEPLOY:-unset}" \
  >> /var/log/openvpn/deploy-labels.log

Lue muuttuja ympäristön kautta sen sijaan että jäsentäisit lokia, ja anna sille aina oletusarvo. ${UV_DEPLOY:-unset} pitää skriptin toimivana asiakkaille, jotka eivät koskaan lähetä kenttää, mikä on vaiheittaisen käyttöönoton aikana normaali tila. Älä kaada koko ympäristöä lokiin nimen löytääksesi; se sisältää paljon muutakin kuin tunnisteen, mukaan lukien arvoja, joita et aikonut säilyttää.

Aja skripti käsin ja se raportoi unset kaikesta, koska käsin ajettu kuori ei kanna yhteyden ympäristöä. Se ei ole skriptin virhe eikä todiste kentän puuttumisesta. Testaa sitä todellisen yhteyden kautta, joka on ainoa konteksti, jossa muuttuja on olemassa.

Varmista mikä todella saapui

Yhdistä yksi asiakas tunnisteella ja yksi ilman, lue sitten tiedosto. Pari on testi: yhden rivin pitäisi kantaa arvo ja toisen oletusarvo, ja molempien pitäisi nimetä sama todennettu identiteetti, jota odotat.

tail -n 5 /var/log/openvpn/deploy-labels.log
# field-support deployed-client-07
# unset         legacy-laptop-02

Ne kommenttirivit ovat tulosteen muoto, eivät kopio palvelimeltasi; lue oma tiedostosi. Jos myös toinen asiakas näyttää arvon, muuttuja on asetettu jossain muualla ympäristössä, ja luet vanhentunutta asetusta etkä vertaiskenttää.

Tarkista myös palvelimen loki yhteyden osalta. Vertaistiedot voivat näkyä siellä, mikä on kätevää vianetsinnässä ja syy pitää arvot tylsinä: ei ihmisten nimiä, ei tiketinumeroita, ei mitään, mitä et haluaisi lokin lukijan näkevän.

Kohtele tunnistetta väitteenä, älä identiteettinä

Kuka tahansa, joka voi muokata asiakasprofiilia, voi muuttaa tunnistetta, eikä tunnelin todentaminen tee tunnisteesta valtuutettua. Siirto suojaa arvon matkalla; se ei vahvista väitettä. Valtuutus kuuluu edelleen todennetulle identiteetille ja palvelimen omistamalle rekisteröintitietueelle, ja tunnistetta verrataan siihen tietueeseen silloin, kun sillä on merkitystä.

Tämä ero ratkaisee, missä tunnistetta saa käyttää. Hyviä käyttöjä ovat istunnon ohjaaminen oikeaan lokitiedostoon, näyttöryhmän valinta kojelaudassa tai tukistunnon merkitseminen, jotta ihminen löytää sen myöhemmin. Huonoja käyttöjä ovat laitteen päästäminen aliverkkoon, palomuurikäytännön valinta tai päättäminen, kenen asiakkaan tietoja istunto saa lukea.

Validoi arvo ennen kuin se saavuttaa polun, kyselyn tai komentotulkin komennon. Odotettujen merkkijonojen sallittujen luettelo riittää käyttöönottotunnisteelle, eikä se maksa mitään. Älä koskaan sijoita vertaisen toimittamaa merkkijonoa komentotulkin komentoriviin, ja rajaa kaikki tallennettu havainto istuntoon eikä tunneliosoitteeseen, jota seuraava asiakas käyttää uudelleen.

case "${UV_DEPLOY:-}" in
  field-support|field-qa|lab) : ;;
  *) UV_DEPLOY=unknown ;;
esac

Peru se siististi

Ominaisuuden poistaminen on kaksi poistoa ja yksi varmistus. Poista rivit setenv ja push-peer-info asiakasprofiilista ja poista tai poista käytöstä koukku ja sen lokikohde palvelimelta.

grep -rn 'UV_DEPLOY\|push-peer-info' /etc/openvpn/
tail -n 3 /var/log/openvpn/deploy-labels.log

Yhdistä sen jälkeen yksi asiakas uudelleen ja varmista, että lokirivi lakkaa ilmestymästä. Koukku, joka laukeaa edelleen profiilimuutoksen jälkeen, on yleensä toinen profiili, joka on yhä käytössä testilaitteessa, ja sen löytäminen nyt on halvempaa kuin löytäminen auditoinnin aikana.

Lopuksi jäljelle jää pieni, rajattu istunnon metatieto, jonka alkuperä on dokumentoitu: asiakas väittää sitä, palvelin tallentaa sen, eikä mikään pääsyssä riipu siitä. Se on ominaisuuden hyödyllinen versio, eikä sinne pääseminen vaadi uutta tunnistetietoa.