VPN-asiakkaat tavoittavat palvelimen mutta eivät lähiverkkoa: mikä korjaus?

Asiakas pingaa OpenVPN-palvelimen tunneliosoitetta ja saa vastauksen, yrittää sitten lähiverkon isäntää eikä saa mitään. Tämä ero rajaa vian tehokkaasti: tunneli on pystyssä, välitys todennäköisesti toimii ja vastaus lähtee ovesta, joka ei johda takaisin. Korjauksia on kolme, ja oikea riippuu siitä, mitä hallitset ja mistä olet valmis luopumaan. Vastaa alla oleviin kolmeen kysymykseen järjestyksessä, niin valinnasta ei tule enää makuasia.

Varmista ensin, kumpi suunta on rikki

Pyyntö saapuu tunnelirajapintaan VPN-poolin lähdeosoitteella. Palvelin välittää sen lähiverkon isännälle, ja tämä isäntä vastaa sille yhdyskäytävälle, jonka sen oma taulu nimeää, yleensä lähiverkon reitittimelle. Jos reitittimellä ei ole reittiä pooliin, vastaus kuolee siihen tai harhailee kohti internetiä.

Testaa molemmat koneet ennen kuin muutat kumpaakaan. Kysy palvelimelta reititystaulusta, miten se tavoittaisi asiakkaan; kysy lähiverkon isännältä, miten se tavoittaisi saman osoitteen. Ensimmäinen haku osoittaa yleensä tunneliin ja toinen lähiverkon reitittimeen, ja tuo ero on vika yhdellä rivillä. Kaksi hakua on halvempaa kuin palomuurin auditointi ja ne ratkaisevat ongelman suunnan.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

Jos lähiverkon isäntä osoittaa jo VPN-palvelimeen, ongelmasi on palomuurisääntö tai MTU-raja eikä puuttuva paluureitti. Älä lisää reittiä suodattimen korjaamiseksi.

Kysymys yksi: voitko muokata kaukolähiverkon reititintä?

Kun lähiverkon reititin on sinun, puhdas vastaus on staattinen reitti VPN-pooliin VPN-palvelimen lähiverkko-osoitteen ollessa seuraava hyppy. Se pitää asiakkaiden lähdeosoitteet ennallaan, millä on väliä, kun lähiverkon isännät kirjaavat, suodattavat tai rajoittavat nopeutta osoitteen mukaan. Se ei myöskään vaadi käännöstä palvelimella, joten tunneli pysyy puhtaana reitityspolkuna. Velvoite, jonka se luo, on dokumentointi, koska poolin, reitin ja palvelimen kokoonpanon on oltava yhtäpitäviä.

Se pettää hiljaa sinä päivänä, kun joku muuttaa poolia. Kirjoita arvo kerran ylös ja kohtele muutosta missä tahansa kolmesta paikasta muutoksena kaikkiin kolmeen.

NAS tai Layer 3 -kytkin, joka isännöi palvelua, tarvitsee saman reitin, ellei se lähetä kaikkea reitittimen kautta, jolla se on. Tarkista laite, joka päättää aliverkon, ei vain internetiin päin olevaa. Pienissä verkoissa on usein kolme laitetta, joilla on mielipide reitityksestä.

Kysymys kaksi: voiko lähiverkko lakata näkemästä asiakkaiden osoitteita?

Kun reititin kuuluu jollekulle muulle, kääntäminen VPN-palvelimella ei vaadi yhteistyötä. Lähiverkon isäntä näkee palvelimen lähiverkko-osoitteen, vastaa siihen ja palvelin kääntää takaisin. Siksi laitteet ja NAT-pohjaiset etäkäyttöroolit käyttäytyvät näin.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Hinta on kohdistus: asiakaskohtaiset osoitteet katoavat lähiverkon lokeista. Lähiverkon isännän sallittujen luettelo saa silloin nimetä palvelimen poolin sijaan.

Valitse kääntäminen, kun yhteistyötä ei ole saatavilla, älä silloin kun se on vain hankalaa. Se piilottaa asiakkaan kaikilta tulevilta tutkinnoilta, myös niiltä, joissa sinun on tiedettävä, mikä kannettava avasi yhteyden. Se voi myös rikkoa protokollia, jotka upottavat osoitteita hyötykuormaan, koska käännös elää otsakkeessa. Kumpikaan vaihtoehto ei ole edistyneempi; ne vastaavat eri kysymyksiin omistajuudesta.

Kysymys kolme: onko palvelin itse toisen tunnelin asiakas?

Kuvittele toinen topologia: VPN-palvelin soittaa myös kaupalliselle operaattorille, joten sillä on kaksi tunnelia ja kahdet osoitteet. Liikenne, jonka se välittää omille asiakkailleen, lähtee operaattorin kautta, eikä se reititä vastauksia takaisin poolin osoitteisiin. Siksi vastaukset katoavat, vaikka molemmat tunnelit ovat terveitä.

Korjaus on naamioida myös lähtevä tunneli, jotta operaattori näkee vain palvelimen tunneliosoitteen. Vastakkainen suunta tarvitsee oman sääntönsä, koska palvelin, joka avaa yhteyden omaan asiakkaaseensa, on eri virtaus. Ilman sitä sääntöä asiakas vastaa osoitteeseen, jota se ei voi reitittää. Aseta kapea sääntö ennen mitään laajaa naamiointia, jotta täsmällinen käännös voittaa.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

Moniyhdistelmäiset isännät lisäävät samankaltaisen vian, joka näyttää asiakkaan suunnasta identtiseltä. Vastaus lähtee rajapinnasta, jonka metriikka on pienempi, koska lähdeosoite valittiin toisesta taulusta. Tarkista paluupolku haulla sen sijaan, että olettaisit menopolun sisältävän sen.

Varmista sitten molemmat suunnat ja molemmat koot

Pingaa muutoksen jälkeen asiakkaasta lähiverkon isäntään ja sitten lähiverkon isännästä asiakkaaseen. Toinen suunta on se, jonka ihmiset ohittavat, ja juuri se paljastaa puutteellisen käännössäännön. Kirjaa molemmat tulokset aikaleimoilla, jotta myöhempi regressio on vertailukelpoinen.

Siirrä sitten oikeaa dataa, koska pieni ping, joka onnistuu suuren siirron juuttuessa, on MTU-oire. Se vika ilmaantuu heti, kun olet onnitellut itseäsi reitin korjaamisesta.

Testaa lopuksi uudelleen uudelleenkäynnistyksen jälkeen. Ajon aikana annetut reitti- ja palomuurikomennot eivät selviä siitä, ja korjaus, joka katoaa seuraavalla käynnistyksellä, diagnosoidaan uudelleen jonkun toimesta, jolla on vähemmän kontekstia. Tee muutoksesta pysyvä sillä tavalla, jolla järjestelmäsi jo tekee sen, ja käynnistä sitten kerran tarkoituksella uudelleen.