Valmiiksi luotu tun OpenVPN:ssä: kahden omistusmallin vertailu

Joku loi tun1 valmiiksi, profiili sanoo dev tun1, eikä yhteys silti kiinnity. Nimen olemassaolo isännässä ei kerro juuri mitään, koska kiinnittyminen riippuu nimiavaruudesta, laitteen tyypistä, siitä kuka omistaa linkin ja mitä taustapalvelulle on sallittu. Laitteen uudelleenkäyttö pakottaa myös päätöksen, jonka oletusasetus kätkee: mikä komponentti kirjoittaa osoitteet ja reitit. Kahden järjestelyn vikatilat eroavat paljon enemmän kuin asetusrivit, joten päätä ennen profiilin muokkaamista.

Nimi ei ole kiinnittyminen

dev tun1 on pyyntö OpenVPN:lle juuri siitä nimetystä rajapinnasta, ja perinteiset käyttäjäavaruuden koosteet yrittävät avata sen. Jos nimi ei noudata tavallista tun- tai tap-kaavaa, profiili tarvitsee myös vastaavan dev-type:n, koska tyyppiä ei koskaan päätellä merkkijonosta. TAP-laite ei ole erimerkkinen TUN-laite: väärän laitteen kiinnittäminen joko epäonnistuu suoraan tai tuottaa linkin, joka kuljettaa kehyksiä, joita kukaan ei odota. Tarkista tyyppi ennen kaikkea muuta, koska jokainen myöhempi tarkistus olettaa molempien osapuolten olevan siitä yhtä mieltä. Siitä eteenpäin varmista, että prosessi todella pystyy avaamaan laitteen, ei vain näkemään sitä.

dev tun1
dev-type tun

Verkkorajapinta ja /dev/net/tun ovat eri objekteja: toinen on linkki nimiavaruuden sisällä, toinen on merkkilaite, jota käyttäjäavaruuden ohjelma käyttää kiinnittämiseen. Linuxin TUN/TAP-dokumentaatio kuvaa tämän kiinnityspolun ja pysyvien laitteiden omistussäännöt. Root-kuori, joka pystyy ajamaan ip link:n, todistaa vain, että kuorella on oikeudet, ei että taustapalvelulla on. Laitesolmun omistus, palvelun kyvykkyydet ja käyttäjä, jonka nimissä se toimii kaikkien on sovittava ennen kuin avaaminen onnistuu.

Laite, joka on olemassa eikä aukea, on omistusongelma, ei reititysongelma. Kohtele sitä sellaisena vianetsinnän aikana, muuten iltapäivä menee sellaisten reititystaulujen lukemiseen, jotka eivät koskaan olleet ongelma.

Kuka määrittää linkin: kaksi omistusmallia

Ensimmäisessä mallissa OpenVPN määrittää osoitteet ja reitit osana yhteyden nostamista. Se on oletuskäyttäytyminen ja helpoin ymmärtää, koska yksi komponentti luo tilan ja poistaa sen jälleen. Toisessa mallissa ulkoinen hallinta omistaa rajapinnan, ja ifconfig-noexec estää OpenVPN:ää ajamasta osoiteasetuksen komentojaan ja luovuttaa parametrit skripteille. Silloin hallinnan on itse sovellettava oikea paikallinen ja vastapuolen asetus, mikä on enemmän työtä kuin valinnan nimi antaa ymmärtää. Kahden välillä valinta on kysymys siitä, kuka saa muuttaa linkkiä sen ollessa ylhäällä.

ifconfig-noexec kattaa vain osoitteet: reititystaulu jää koskemattomaksi ja reittien asetus kuuluu route-noexec:lle. Kohtele kahta direktiiviä erillisinä ohjauksina erillisine omistajineen, koska toisen asettaminen ja toisen olettaminen on tavallinen puoliksi asetettujen linkkien lähde. Valitse täsmälleen yksi omistaja kerrosta kohti, osoitteet yhteen paikkaan ja reitit yhteen paikkaan. Verkkohallinta ja VPN-apuri, jotka molemmat kirjoittavat osoitteita, on juuri se tapa, jolla katkaisu poistaa tilan, josta toinen osapuoli yhä riippuu.

Tarkastele laitetta siitä nimiavaruudesta, jolla on merkitystä

Tarkastele laitetta siitä nimiavaruudesta, jossa VPN-prosessi toimii, älä siitä, jossa kuoresi sattuu olemaan. Kaksi alla olevaa komentoa vastaavat eri kysymyksiin, ja ero näkyy, kun isäntä näkee rajapinnan, jota kontti ei näe. Aja ne annetussa järjestyksessä, koska toinen on mielekäs vasta kun tiedät, onko linkkiä ollenkaan.

ip -details link show dev tun1
ip tuntap show

Ensimmäinen komento tulostaa linkin sellaisena kuin ydin sen näkee, liput ja rajapinnan tyyppi mukaan lukien, ja näin vahvistat, että tämä on tarkoittamasi laite. Toinen luettelee pysyvät tun/tap-merkinnät, jotka ovat olemassa ilman, että mikään prosessi pitää niitä. Rajapinta, joka odottaa määrättyä omistajaansa, on eri tilanne kuin toiseen VPN:ään kiinnitetty elävä tunneli, ja vain jälkimmäinen selittää, miksi oma kiinnityksesi epäonnistuu. Etsi laitetta pitävä prosessi ennen kuin muutat mitään, koska pysyvällä merkinnällä ja varatulla rajapinnalla on eri korjaukset.

Monijonotuki on tietty ajurijärjestely omine vaatimuksineen, ei lupa asiaankuulumattomille prosesseille jakaa yhtä rajapintaa. Toisen omistajan elävä istunto on koordinointiongelma, eikä mikään profiilin muokkaus ratkaise sitä.

Kaksi erilaista pysyvyyttä

Ytimen pysyvyys ja persist-tun kuvaavat elinikiä, jotka on helppo sekoittaa ja kallista erehtyä. Pysyvä laite on olemassa riippumatta mistään prosessista, joten se selviää pysäytyksestä ja seuraava käynnistys voi käyttää sitä uudelleen. persist-tun pitää resurssit yhden OpenVPN-prosessin sisäisten tuettujen pehmeiden nollausten yli, paljon lyhyempi aikajänne. Kumpikaan ei lupaa, että palvelun pysäyttäminen jättää reitit ja osoitteet paikoilleen, eikä näkyvissä pysyvä rajapinta ole todiste toimivasta salatusta istunnosta.

Vahvista myös taustaosa, koska valmiiksi luotu rajapinta ei kerro mitään siitä, mikä toteutus sen avaa. Suoran datapolun sisältävät yhteisökoosteet yrittävät käyttää sitä, ellei suunnittelu sano muuta. Missä versio tukee kytkintä, disable-dco valitsee sen sijaan käyttäjäavaruuden polun; vanhemmilla moottoreilla ja muilla asiakkaille ei ole sellaista direktiiviä, joten pidä versioehto valinnan vieressä äläkä oleta sen pätevän.

Mikä hajoaa, kun testataan vain käynnistys

Omistussopimus voi läpäistä ensimmäisen testin ja epäonnistua viimeisessä, mikä tekee käynnistyksestä yksinään huonon tarkistuksen. Tarkkaile sen sijaan kahta siirtymää: pehmeä nollaus ja täysi pysäytys, jota seuraa käynnistys.

systemctl status openvpn-client@lab
ip -details link show dev tun1

Käynnistys on helppo tapaus: yksikkö nousee, linkki ilmestyy ja tilatuloste nimeää ladatun profiilin. Kiinnittyminen on hetki, jolloin taustapalvelu avaa laitteen, joten aja linkin tarkistus sen jälkeen kun yksikkö ilmoittaa olevansa aktiivinen, ei ennen sitä. Jos linkki on olemassa, kun tila vasta aktivoituu, katselet pysyvää laitetta, johon kukaan ei ole vielä kiinnittynyt, et toimivaa tunnelia. Päästä todellista liikennettä linkin läpi ennen jatkamista, koska kiinnitetty rajapinta ilman käyttökelpoista reittiä on yhä epäonnistuminen.

kill -SIGHUP $(pidof openvpn)
journalctl -u openvpn-client@lab -n 40
systemctl stop openvpn-client@lab
ip -details link show dev tun1

Pehmeän nollauksen pitäisi jättää istunto käyttökelpoiseksi ja resurssit ehjiksi, ja juuri sen työn persist-tun tekee. Täysi pysäytys on paikka, jossa ulkoinen hallinta paljastaa itsensä: jos linkki tai sen osoitteet selviävät pysäytyksestä, joku muu omistaa ne, ja se on joko dokumentoimasi tila tai juuri löytämäsi vika. Kirjaa molemmat havainnot profiilin viereen, jotta seuraava muutos alkaa todisteista eikä kaaviosta.