Miksi OpenVPN-asiakkaan takana oleva aliverkko on tavoittamaton?

Pingit palvelimen tunneliosoitteeseen onnistuvat, asiakkaan oma reititystaulukko näyttää oikealta, ja asiakkaan takana oleva LAN on yhä tavoittamaton. Asiakkaan reititystaulukko näyttää oikealta, palvelimella on tunneliin osoittava reitti, ja paketit katoavat silti. Se on klassinen oire layer-3-tunnelista, joka ei tiedä yhden asiakkaistaan olevan myös yhdyskäytävä.

tun-rajapinnalla ei ole seuraavaa hyppyä asiakaskohtaisesti. Ydin näkee yhden rajapinnan, jolla on monta vertaisverkkokumppania, joten päätös siitä, mikä asiakas saa etä-LANin paketin, on tehtävä OpenVPN-prosessin sisällä. Tämä päätös määritetään iroute-merkinnällä, ja ilman sitä paketilla ei ole minne mennä.

Palvelin reitittää asiakkaan, ei rajapinnan mukaan

Kun palvelimen on lähetettävä paketti asiakkaan tunneliosoitteeseen, vastaus on yksiselitteinen: osoite kuuluu kyseisen asiakkaan istuntoon. Kun kohteena on koko asiakkaan takana oleva aliverkko, osoite ei kuulu kenellekään palvelimen tuntemalle, ja ytimen reitti tunneliin sanoo vain "tästä rajapinnasta", kertomatta kumpi vertaisverkkokumppani.

OpenVPN ratkaisee tämän sisäisellä reititystaulukolla, joka liittää kohdeprefiksin tiettyyn asiakkaaseen. Taulukko rakennetaan iroute-merkinnöistä, siksi tavallinen reitti palvelimen isäntäkoneessa ei riitä. Ytimen reitti vie paketin tunnelirajapinnalle; sisäinen liitos päättää, mikä istunto vastaanottaa sen. Siksi korjaus ei koskaan näy ytimen reittitulosteessa.

Jos liitos puuttuu, paketti saapuu palvelimelle, vastaa tunnelireittiä ja hylätään, koska mikään asiakas ei vaadi kohdetta. Mikään ei kirjaa puhdasta virhettä, siksi vika näyttää hiljaiselta mustalta aukolta eikä reitityssilmukalta.

Kirjoita iroute-merkintä, joka nimeää asiakkaan

iroute asuu asiakaskohtaisessa kokoonpanotiedostossa, ei palvelimen pääkokoonpanossa. Osoita palvelin hakemistoon client-config-dir-valinnalla, luo sitten tiedosto, jonka nimi on asiakkaan varmenteen yleinen nimi, ja laita prefiksi sen sisään.

Haaralle, jonka LAN on 10.20.0.0/24 ja varmenteen yleinen nimi branch-router, tiedosto kyseisellä polulla sisältää rivin kuten iroute 10.20.0.0 255.255.255.0. Pääkokoonpano tarvitsee vain hakemistovalinnan; prefiksi asuu asiakkaalla.

Yleinen nimi on hauras osa. Eri subjectilla myönnetty varmenne tai käyttöönotto, joka todentaa käyttäjät käyttäjänimellä tiedoston ollessa nimetty varmenteen mukaan, tuottaa tiedoston, jota ei koskaan lueta. Tarkista nimi, jonka palvelin todella raportoi istunnolle, ja harkitse valintaa, joka saa yhteensopimattoman asiakkaan epäonnistumaan sen sijaan, että se liittyisi hiljaa ilman reittejään. Tiedoston uudelleennimeäminen varmenteen mukaiseksi on viiden minuutin korjaus, joka estää hyvin pitkän illan.

Yksi asiakas voi omistaa useita prefiksejä. Lisää yksi iroute-rivi verkkoa kohden ja pidä lista kyseisen asiakkaan muiden asetusten vieressä, jotta liitos pysyy tarkastettavana.

Paluureitin rakentaminen molempiin suuntiin

Pakettien saaminen etä-LANiin on puoli työtä. Asiakkaan on myös lähetettävä kyseisen LANin liikenne tunneliin, mikä tehdään yleensä työntämällä reitti asiakkaalle: rivi kuten push "route 10.8.0.0 255.255.255.0" kertoo jokaiselle asiakkaalle, miten palvelinpuolen verkkoon päästään. Haaralle vastaava reitti osoittaa tunneliin kaikelle, mihin sen on palvelinpuolella päästävä.

Paluusuunta tarvitsee omistajan kaukokulmalla. Siellä jonkun on tiedettävä tie takaisin: staattinen reitti LAN-reitittimellä, joka osoittaa VPN-poolin palvelimelle, tai osoitemuunnos palvelimella ennen kuin liikenne tulee LANiin. Staattinen reitti pitää alkuperäiset osoitteet näkyvinä lokeissa ja käyttösäännöissä, mutta vaatii LANin omistajan yhteistyötä; muunnos on itsenäinen mutta kätkee, kuka todella yhdisti.

Edelleenlähetys on oltava käytössä palvelimen isäntäkoneella. Ilman sitä ydin hyväksyy paketin tunnelista ja kieltäytyy välittämästä sitä LAN-rajapinnalle, mikä asiakkaan näkökulmasta näyttää täsmälleen samalta kuin puuttuva iroute.

Tavoitettavuuden tarkistaminen oikeilla luotaimilla

Testaa kerroksittain sen sijaan että pingaat kaukokulmaa ja arvailet. Palvelimelta tarkista, että prefiksin sisäinen liitos on olemassa ja että ytimen reitti osoittaa tunneliin. Asiakkaalta varmista, että työnnetty reitti on asennettu ja että sen oletuspolku LAN-osoitteeseen on tunneli.

Seuraa sitten paketteja. Kaappaus tunnelirajapinnalla näyttää, lähettääkö palvelin asiakasta kohti, ja kaappaus LAN-rajapinnalla näyttää, välittääkö se. Jos ensimmäinen näyttää paketteja ja toinen ei, ongelma on välityksessä tai suodattimessa; jos kumpikaan ei näytä mitään, haku epäonnistui aiemmin.

Kaksi tunnelilla yhdistettyä palvelinta toistavat saman säännön molemmilla puolilla: kumpikin tarvitsee iroute-merkinnän toisen poolille, ja kumpikin tarvitsee reitin ja edelleenlähetyksen, jotka tekevät polusta symmetrisen. Reititys ja käytäntö ovat tässä erillisiä asioita. Reititys päättää, minne paketti voi mennä, kun taas FORWARD-sääntö päättää, saako se, joten asiakas, jolla on kaksi iroute-riviä, tavoittaa molemmat prefiksit, ellei suodatin sano toisin.