VPN-asiakkaat yhdistävät mutta internetiä ei ole: kolme puuttuvaa osaa

Asiakas saa osoitteen, palvelin vastaa pingiin, ja silti jokainen sivu aikakatkeaa. Useimmat alkavat tässä vaiheessa muokata asiakasprofiilia, mikä on yleensä hukattua vaivaa: kun tunneli on pystyssä, palvelimen on käyttäydyttävä kuin reititin. Kolmen ehdon on oltava voimassa yhtä aikaa ennen kuin paketti lähtee ja vastaus palaa, ja oire on sama riippumatta siitä, mikä niistä puuttuu.

Miksi toimivalla tunnelilla ei silti ole ulospääsyä

Ytimen on välitettävä paketteja rajapintojen välillä, mikä on useimmissa Linux-jakeluissa oletuksena pois päältä. Liikenne on käännettävä osoitteeseen, johon ulkomaailma voi vastata, ellei jokainen ylävirran reititin jo tunne paluureittiä tunnelin aliverkkoon. Palomuurin edelleenlähetyspolun on sallittava liikenne molempiin suuntiin, vastaukset mukaan lukien.

Jokainen näistä voidaan korjata erikseen, ja siinä on ansa. Edelleenlähetyksen kytkeminen päälle ilman käännössääntöä jättää paketit lähtemään yksityisellä lähteellä ja ilman paluureittiä. Käännöksen lisääminen ilman edelleenlähetyssääntöä jättää ytimen pudottamaan paketin askelta myöhemmin.

Testaa siis kolmea kerrosta asiakkaan sijaan ja muuta yhtä kerrallaan, jotta tuloksella on merkitystä.

Edelleenlähetys on ytimen kytkin, joka sinun on tehtävä pysyväksi

Tarkista nykyinen arvo ennen muuttamista, aseta se sitten ja vahvista, että muutos tuli voimaan.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

Ensimmäinen komento ilmoittaa nykyisen arvon, toinen asettaa sen ajon aikana ja kolmas todistaa, että kirjoitus toimi. Ajon aikainen arvo katoaa seuraavassa uudelleenkäynnistyksessä, minkä vuoksi toimiva istunto voi rikkoutua huollon jälkeen ilman mitään kokoonpanomuutosta.

Tee siitä pysyvä tiedostossa /etc/sysctl.d/ alla ja käytä sitten sitä tiedostoa sen sijaan, että käynnistäisit uudelleen saadaksesi selville. FreeBSD:ssä vastine on net.inet.ip.forwarding, ja pysyvyyteen gateway_enable=YES tiedostossa rc.conf. Laite, joka ilmoittaa edelleenlähetyksen olevan pois päältä, selittää kokonaisen luokan raportteja „paketit saapuvat eikä mitään tule takaisin”. Tarkista asetus myös jokaisen päivityksen jälkeen, sillä uudelleenrakennettu ydin tai vaihdettu laitekuva voi nollata sen kertomatta kenellekään.

Valitse masquerade tai yksi kiinteä käännösosoite

Dynaamisella ulkoisella osoitteella masquerading on yksinkertaisin oikea muoto. Nimeä tunnelin aliverkko lähteeksi ja ulkoinen rajapinta poistumaksi.

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

Staattisella julkisella osoitteella lähteen kääntäminen juuri siihen osoitteeseen on ennustettavampaa ja helpompi auditoida.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

Toinen muoto kantaa huoltoansan: kovakoodattu osoite, joka myöhemmin muuttuu, pitää tunnelin toiminnassa samalla kun internetyhteys hiljaa lakkaa. Käytä joko masqueradea tai päivitä sääntö aina, kun palveluntarjoaja siirtää sinut. Myös rajapinta on merkityksellinen, koska reitittimen, joka jakaa oman ylävirran tunnelinsa, on käännettävä tuon tunnelin kautta eikä fyysisen WAN:in kautta.

Suodatintaulukko on kolmas portti

Edelleenlähetys ja käännös voivat olla molemmat oikein, kun paketti silti kuolee suodatintaulukossa. ufw on usein syyllinen: sen edelleenlähetyskäytäntö toimitetaan DROP:na, ja muu kokoonpano voi näyttää täysin oikealta, kun taas se yksi asetus tappaa liikenteen. Sen nostaminen on tietoinen turvallisuuspäätös eikä valintaruutu.

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Ensimmäinen sääntö sallii uuden liikenteen tunnelista ulospäin ja toinen vain vastaukset takaisin. Kavenna molemmat tunnelin aliverkkoon ja aiottuun kohteeseen, sillä tunnelirajapinnan yleinen sallinta tekee VPN:stä avoimen ulostulopisteen kenelle tahansa, joka pystyy todentamaan itsensä.

Sillattu tunneli tarvitsee toisenlaisen vastauksen. Osoite kuuluu sillalle, ei fyysiselle portille, joten rajapinnan orjuuttaminen poistaa osoitteen, joka sillä aiemmin oli, ja isäntä näyttää tavoittamattomalta, kunnes silta itse saa osoitteen, jonka dhclient br0 voi antaa. Tämä vika näyttää VPN-ongelmalta ja on toisen kerroksen ongelma. Tarkista sillan oma osoite ennen kuin kosket palomuuriin, sillä suodatinmuutos ei voi korjata isäntää, jolla ei enää ole osoitetta, josta lähettää.

Mihin katsoa, kun sivu ei koskaan lataudu

Pingaa palvelimen tunneliosoitetta todistaaksesi, että tunneli on olemassa. Aja sitten traceroute asiakkaasta julkiseen osoitteeseen ja lue, mihin se pysähtyy: palvelimella paketti saapuu, mutta sitä ei välitetä eikä käännetä; palvelimen tuolla puolen ongelma on ylävirrassa ja poissa käsistäsi.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

Ensimmäinen komento todistaa, että tunneli kuljettaa liikennettä palvelimelle itselleen, ja toinen näyttää, kuinka kauas paketti pääsee ulospäin. Tunneliosoitteeseen päättyvä jälki viittaa palvelimen edelleenlähetykseen tai käännökseen, kun taas yhden hypyn myöhemmin pysähtyvä jälki viittaa palveluntarjoajaan tai ylävirran reitittimen paluureittiin.

Tarkkaile palvelimella ulkoista rajapintaa, kun asiakas lataa sivua. Yksityisellä lähdeosoitteella lähtevä liikenne tarkoittaa, että käännös puuttuu, ja täysi vastauksen puute tarkoittaa, että edelleenlähetyspolku tai ylävirran paluureitti pudottaa sen.

Jos etäasiakkaiden on päästävä myös palvelimen lähiverkon isäntiin, muista, että lähiverkko tarvitsee paluureitin tunnelin aliverkkoon. Tämä on reititystä eikä käännöstä, ja se on vaihe, joka useimmin unohdetaan, kun internetyhteys lopulta toimii.