Mitä OpenVPN:n route-nopull todella estää palvelinta työntämästä

Laitoit route-nopull-asetuksen asiakasprofiiliin estääksesi tunnelia nielemästä oletusreittiäsi, ja nyt toimiston aliverkko on tavoittamaton, vaikka asiakas sanoo edelleen olevansa yhteydessä. Molemmat havainnot pitävät paikkansa, eikä mikään ole epäonnistunut. Lippu käskee asiakasta ohittamaan palvelimen työntämät reitit ja DHCP-merkinnät, mikä on suppeampi ohje kuin useimmat odottavat sitä lisätessään. Jäljelle jää toimiva tunneli, jolla ei ole mielipidettä siitä, minkä kohteiden pitäisi käyttää sitä.

Tuo aukko on koko päätös, jota tämä artikkeli käsittelee. Joko palvelin kuvaa verkon tai asiakas tekee sen, ja lippu antaa tämän tehtävän asiakkaalle tekemättä siitä mitään puolestasi.

Mitä lippu kytkee pois päältä yhdistettäessä

Vetävä OpenVPN-asiakas ottaa yleensä todennuksen jälkeen palvelimelta vastaan nipun: reitit, oletusyhdyskäytävän uudelleenohjauksen, DNS-palvelimet ja muutaman viritysohjeen. Kun route-nopull on voimassa, asiakas hyväksyy edelleen istunnon, tarkistaa edelleen varmenteet, neuvottelee edelleen salaukset ja keepalivet ja nostaa edelleen käyttöliittymän. Sen pudottama asia on työnnettyjen route-rivien ja työnnettyjen dhcp-option-rivien soveltaminen, DNS mukaan lukien.

Hämmennys tulee vihreästä ilmaisimesta kuolleen sovelluksen vieressä. Tunneli on olemassa; kohteiden kuvaus tuohon tunneliin ei ole. Mikään asiakkaan tilapaneelissa ei erota tilaa »yhdistetty ja reitittää« tilasta »yhdistetty ja toimettomana«, koska tunnelin näkökulmasta molemmat ovat sama tila.

Miksi elävä tunneli ei silti välitä mitään

Käyttöliittymä ilmestyy omalla osoitteellaan, ja pisteestä pisteeseen -yhteydessä sillä ei usein ole mitään täsmällisempää kuin isäntäreitti vastapuoleen. Yksityinen aliverkko tulee tavoitettavaksi vasta, kun jokin reitti osoittaa tuohon käyttöliittymään oikealla etuliitteellä, ja kun työntäminen on poissa päältä, se reitti ei koskaan saavu. Ladattu profiilikaan ei yleensä auta, koska se kirjoitettiin olettaen, että palvelin toimittaa juuri tämän tiedon. Siksi käyttöliittymä voi näyttää terveeltä, kun aliverkko pysyy pimeänä.

Profiilin lukeminen todistaa siis hyvin vähän. Lue sen sijaan käynnissä oleva tila yhdistetystä koneesta:

ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10

Osoite ilman aliverkkoreittiä toisessa komennossa on tämän ongelman allekirjoitus. Kolmas komento vastaa sitten kysymykseen, josta käyttäjät todella välittävät, koska se kertoo käyttöliittymän, jonka ydin valitsisi tietylle kohteelle, eikä listaa, jonka toivoit sen käyttävän. Jos se vastaa fyysisen yhteytesi kautta, tunnelia ei ole reitillä lainkaan.

Nimien selvitys epäonnistuu liittyvästä syystä, ei erillisestä. Työnnetyt dhcp-option DNS-merkinnät ohitetaan samalla lipulla, joten kyselyt sisäisistä isännistä menevät mille tahansa selvittimelle, jonka paikallisverkko on tarjonnut. Sillä selvittimellä ei ole toimiston vyöhykettä, joten kysely epäonnistuu tai palauttaa julkisen vastauksen, ja vika näyttää palvelinongelmalta, vaikka se on asiakkaan kokoonpano-ongelma. Osoitteen testaaminen ennen nimeä on se, mikä erottaa nämä kaksi.

Valinta lipun ja etuliitesuodattimen välillä

Kaksi vaihtoehtoa ratkaisevat saman valituksen erilaisia muotoja, ja huono valinta tuottaa yhdistetty-mutta-hyödytön-tilan. Toinen korvaa työnnetyn käytännön kokonaan, toinen muokkaa sitä etuliitteittäin. Taulukko antaa lyhyen version, ja sen jälkeinen kappale kattaa sen osan, joka yllättää ihmiset.

pull-filter on kolmen verbin etuliitesovitin, joten se voi hyväksyä rivien perheen, jättää ne hiljaa huomiotta tai hylätä yhteyden kokonaan, kun etuliite ilmestyy. Juuri viimeinen käytös on tiedon arvoinen: hylkäyssääntö tekee käytäntöerimielisyydestä epäonnistuneen kättelyn hiljaisen poisjätön sijaan. OpenVPN 2.6 -käsikirja luettelee hyväksytyt etuliitteet ja kunkin verbin tarkan merkityksen.

Yleinen keskitie on hylätä vain redirect-gateway ja antaa toimiston reittien ja DNS:n saapua tarkoitetulla tavalla. Se pitää työntämisen toimivana niiden osien osalta, jotka palvelin ymmärtää sinua paremmin, ja estää samalla sen yhden rivin, joka ottaisi oletusreittisi haltuunsa.

Reittien ja selvittimen lisääminen käsin

Jos pidät lipun, profiilin on sanottava se, mitä palvelin olisi sanonut. Asiakaspuolen route-ohjeet sovelletaan yhteyden muodostamisen jälkeen, joten ne toimivat lipun rinnalla sen sijaan, että lippu estäisi ne. Laita ne profiiliin, älä interaktiiviselle komentoriville, tai seuraava uudelleenyhdistäminen ei toista toimivaa tilaa.

route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53

DNS-rivi on hankalassa asemassa: se on asiakaspuolen ohje, mutta jotkin asiakkaat soveltavat sitä vain alustan DNS-integraation kautta, joka voi kirjoittaa sen yli, kun yhteys muuttuu. systemd-isännässä selvittimen asettaminen suoraan tunnelin käyttöliittymään on ennustettavampaa kuin toivoa asiakkaan voittavan prioriteettikilpailun:

resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.com

Reititysverkkotunnus on yhtä tärkeä kuin osoite. Ilman sitä myös julkisten nimien kyselyt voidaan lähettää sisäiselle selvittimelle, ja mikä tahansa sisäinen selvitin, joka kieltäytyy rekursiosta, rikkoo selaamisen jättäen yksityisen vyöhykkeen toimimaan. Sen kanssa vain kyseisen päätteen alla olevat nimet reititetään tunnelin selvittimelle ja kaikki muu seuraa fyysistä yhteyttä.

Tuloksen tarkistaminen: osoite, nimi ja ulkoinen polku

Kolme testiä erottavat mahdolliset viat. Hae yksityinen osoite IP:llä, sitten sama isäntä nimellä, sitten tavallinen julkinen sivusto. Toimiva IP ja epäonnistuva nimi osoittaa selvittimeen; epäonnistuva IP ja toimiva nimi osoittaa reititykseen; molempien epäonnistuminen tarkoittaa yleensä, ettei tunneli ole reitillä.

Katso sitten ulospäin, älä sisäänpäin. Tunnelipäätepisteen oman reitin on kestettävä muutos, ja kaiken estävän vian on rajattava tunneliin tarttumatta päätepisteeseen. Asiakas, joka jatkaa selaamista tunnelin pudottua, on käytäntöongelma, ei reititysongelma, eikä se näy missään kolmesta yllä olevasta testistä.

Kirjoita lopullinen luettelo profiilin dokumentaatioon: reitit, selvitin, verkkotunnukset ja syy siihen, miksi kukin on olemassa. Uudelleenyhdistäminen, joka toistaa saman taulukon, on ainoa todiste siitä, että paikallinen käytäntö on täydellinen. Jos sovellukset yhä epäonnistuvat, kun tunneli on ylhäällä ja kaikki kolme testiä on läpäisty, seuraava paikka katsoa on yhdistetty-mutta-verkkoyhteydetön-ongelmien luokka eikä jo tarkistetut varmenteet.