OpenVPN iroute vai ytimen reitti: kumpi puuttuu?

Paketti osoitteeseen 10.77.20.0/24 tekee OpenVPN-palvelimella kaksi erillistä päätöstä: käyttöjärjestelmän on luovutettava se VPN-rajapinnalle, ja OpenVPN tarvitsee tiedon siitä, mikä yhdistetty asiakas omistaa kyseisen etuliitteen. Puuttuva ytimen reitti pudottaa sen ennen tunnelia, puuttuva vastapuolen reitti pudottaa sen jälkeen. Molemmat viat näyttävät samoilta kaukaisesta lähiverkosta, ja sen diagnosointi, kumpi sinulla on, vaatii yhden komennon kummallakin puolella.

Klassisessa käyttäjäavaruuden datapolussa ytimen reitti vie paketin tunneliprosessiin, ja iroute kertoo sille prosessille, minkä vastapuolen se pitäisi vastaanottaa. Kumpikaan ei korvaa toista, ja vain toisen sisältävä kokoonpano näyttää järkevältä ensimmäiseen pingiin asti.

Kaksi päätöstä, ei yksi reitti

Kuvittele toimipaikkojen välinen yhteys, jossa 10.77.20.0/24 on yhden asiakkaan takana. Palvelimen ytimen reitti, esimerkiksi ip route add 10.77.20.0/24 dev tun0, lähettää vastaavat paketit tunnelilaitteelle. Sen jälkeen OpenVPN tarkistaa oman sisäisen taulukkonsa, joka on rakennettu asiakkaan kokoonpanohakemiston iroute-merkinnöistä, päättääkseen mikä vastapuoliyhteys ne vastaanottaa. Ilman ytimen reittiä paketti ei koskaan saavuta prosessia, ja ilman vastapuolen reittiä se saavuttaa prosessin eikä mene minnekään.

Tuo jako on helppo unohtaa, koska yksi reittirivi asiakasprofiilissa voi näyttää tekevän molemmat työt. Se ei tee: reitin työntäminen kertoo asiakkaille, mitä tunnelin kautta lähetetään, kun taas iroute kertoo palvelimelle, kuka omistaa asiakkaan takana olevan osoitealueen. Ne elävät eri tiedostoissa, eri puolet lukevat niitä, ja ne epäonnistuvat vastakkaisiin suuntiin.

Mihin iroute kuuluu ja mitä se sanoo

Merkintä menee asiakaskohtaiseen tiedostoon, joka on nimetty asiakkaan common_name -arvon mukaan, client-config-dir-hakemistoon, muodossa iroute 10.77.20.0/24. Tiedostonimen täsmäytys ei ole kosmeettista: OpenVPN etsii todennetun identiteetin ja lukee tiedoston juuri sillä nimellä, joten tiedosto nimeltä site-a vaikuttaa vain asiakkaaseen, jonka yleisnimi on site-a. Lisää ccd-exclusive, jos asiakkaat ilman tällaista tiedostoa on hylättävä kokonaan, mikä on oikea asetus, kun jokainen asiakas on toimipaikan yhdyskäytävä. Pidä yksi tiedosto yhdyskäytävää kohden ja nimeä se sen varmenteen subjektin mukaan, jonka todella myönnät.

Testaa merkintä palvelimelta ennen kuin syytät kaukaista lähiverkkoa. Tilatiedosto luettelee yhdistetyt asiakkaat niiden yleisnimineen, ja --verb 4 -asetuksella ajettava palvelin kirjaa iroute-merkinnän asentamisen, kun vastapuoli yhdistää. Jos yhdistämisen yhteydessä ei näy mitään, tiedosto on väärässä hakemistossa tai nimeää väärän identiteetin.

Ansa: tiedosto on olemassa, identiteetti on väärä

Oikealta näyttävä väärään vastapuoleen liitetty iroute tuhlaa enemmän aikaa kuin puuttuva tiedosto, koska kaikki levyllä näyttää oikealta. Varmenteiden uudelleennimeäminen, päällekkäiset yleisnimet ja tehokkaan identiteetin muuttava username-as-common-name tuottavat sen kaikki. Tarkista, minkä identiteetin palvelin todensi, sen sijaan mitä odotit: tilarivi on ratkaiseva, kun taas tiedostonimi on vain hakukahva.

Reitti voi elää omistajaansa pidempään. Staattiset reitit ja iroute-merkinnät kuvaavat etuliitteen, eivät saatavuustakuun, joten liikenne voi jatkaa ohjautumista vastapuolelle, joka on juuri nyt katkaistu.

Viimeistele polku vastapuolen taakse

Vastapuolen omistajuus on polun keskikohta, ei loppu. Asiakkaan on välitettävä paketit tunnelista omaan lähiverkkoonsa, mikä tarkoittaa IP-välityksen olevan käytössä kyseisellä isännällä ja palomuurisäännön sallivan läpikulun. Kaukaisen lähiverkon isännät tarvitsevat paluupolun tunneliosoitteelle: joko yhdyskäytävää kohti osoittavan reitin tai asiakkaan puolella tarkoituksella suunnitellun NAT-ratkaisun. Vahvista välitysasetus asiakkaalla komennolla sysctl net.ipv4.ip_forward sen sijaan, että olettaisit jakelun oletusarvon.

Jos muiden VPN-asiakkaiden on päästävä tuohon aliverkkoon, järjestely kasvaa taas: palvelin tarvitsee client-to-client-asetuksen, ja näiden asiakkaiden on reititettävä etuliite tunnelin kautta. Mikään tästä ei seuraa palvelimen omasta reititystaulusta.

Vahvista yksi kohde todellisesta lähteestä palvelimen itsensä sijaan. Ping asiaankuulumattomasta lähiverkon isännästä asiakkaan takana olevaan isäntään harjoittaa paluupolkua, välityssääntöä ja vastapuolen omistajuutta yhdellä liikkeellä, kun taas onnistunut kättely todistaa vain identiteetin. Katkaise sitten omistava vastapuoli ja kirjaa, mitä reitti tekee, koska se vastaus on sinun vikatilasi.