OpenVPN-asiakas tavoittaa palvelimen mutta ei LAN-isäntiä: tarkistuslista

Asiakas ilmoittaa olevansa yhteydessä, tunnelin osoite vastaa pingiin, eikä mikään toimiston LANissa vastaa. Näen tämän lähes jokaisen asiakaspäivityksen jälkeen, ja ensimmäinen vaisto on avata palomuuri, mikä on yleensä väärä liike: tunneli on kunnossa ja katkos on yhdessä kolmesta hypystä, jonka paketin on ylitettävä. Käy reitti läpi siinä järjestyksessä kuin paketti sen kulkee, ensin asiakkaan reitti, sitten palvelimen edelleenlähetys, sitten paluumatka, ja löydät vian omistajan parissa minuutissa.

Ensimmäinen vaihe: tarkkaile asiakkaan reitityspäätöstä

Ennen kuin kosket palvelinta, todista että asiakas lähettää paketin tunneliin. Kysy ytimeltä, mitä liitäntää se käyttäisi yhdelle tietylle LAN-isännälle, sen sijaan että lukisit koko taulukon:

ip route get 192.168.50.10

Jos vastaus nimeää fyysisen sovittimesi ja toimiston yhdyskäytävän, mikään palvelinpuolen muutos ei auta. OpenVPN jakaa reittejä vain kun palvelin työntää ne, joten etsi palvelimen kokoonpanosta push "route 192.168.50.0 255.255.255.0" ja yhdistä asiakas sen jälkeen uudelleen. Useimmat asiakkaat soveltavat työnnetyt reitit yhdistäessä, eivät profiilia uudelleen ladattaessa.

Windowsissa samalla kysymyksellä on eri komento. Find-NetRoute -RemoteIPAddress 192.168.50.10 tulostaa liitännän ja seuraavan hypyn, jonka pino valitsisi, ja route print -4 näyttää, onko työnnetty etuliite ylipäätään olemassa.

Toinen vaihe: varmista, että palvelin välittää paketin eteenpäin

Jos asiakkaan reitti on oikein, paketti saapuu palvelimelle, ja palvelimen on hyväksyttävä sen välittäminen. Ytimen kytkin on ensimmäinen portti, ja sysctl net.ipv4.ip_forward:n on palautettava 1. Sen asettaminen komennolla echo 1 > /proc/sys/net/ipv4/ip_forward toimii seuraavaan uudelleenkäynnistykseen asti, ja juuri siksi sama valitus palaa viikkoja myöhemmin.

Kirjoita se paikkaan, joka kestää uudelleenkäynnistyksen:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

Toinen portti on suodatintaulu. Dockerin asentaneella isännällä on usein FORWARD-käytäntönä DROP, ja tunneli perii tämän päätöksen. iptables -L FORWARD -v -n näyttää sekä käytännön että pakettilaskurit; jos käytäntö on DROP, edelleenlähetys tarvitsee nimenomaisen sallinnan tunnelista LANiin -suunnalle ja toisen vastaukselle.

Kolmas vaihe: seuraa paketti LANiin ja etsi vastaus

Tarkkaile palvelimen molempia puolia yhtä aikaa. Kaappaa tunnelilta ja LAN-liitännältä, suodatettuna yhteen asiakkaaseen ja yhteen isäntään, jotta tuloste pysyy luettavana:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

Pyynnöt, jotka ilmestyvät tun0:lle ja uudelleen eth0:lle lähteellä 10.8.0.x ja joita seuraa hiljaisuus, tarkoittavat, että paketti saapui ja vastaus meni muualle. LAN-isäntä vastaa oletusyhdyskäytävälleen, sillä yhdyskäytävällä ei ole reittiä VPN-poolille, ja vastaus kuolee LAN-reitittimellä. LAN-isännän pingaaminen palvelimelta ei todista tästä reitistä mitään, koska se liikenne ei koskaan ylitä tunnelia.

Neljäs vaihe: valitse käännöksen ja paluureitin välillä

Kaksi korjausta sulkee aukon, ja valinnalla on seurauksia sen lisäksi, toimiiko ping. Lähdeosoitteen käännös tekee palvelimesta näennäisen lähettäjän:

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

Rajaa sääntö pooliin ja LAN-liitäntään ja tee siitä sitten pysyvä, muuten seuraava palomuurin uudelleenlataus poistaa korjauksesi hiljaa. Hinta on identiteetti: jokainen asiakas näyttää VPN-palvelimelta LAN-lokeissa ja käyttösäännöissä, ja per-client policy becomes guesswork.

Staattinen reitti 10.8.0.0/24:lle LAN-reitittimellä VPN-palvelimeen osoittaen pitää asiakkaiden osoitteet näkyvinä ja on parempi pitkän aikavälin vastaus, kun reititin on sinun. Monet paikat ajavat molempia jonkin aikaa, NATia välittömään korjaukseen ja reittiä, kun palomuurikäytäntö on kirjoitettu. Jos palvelin on sivusto-sivusto-vertaiskumppani eikä pool, palvelinpuoli tarvitsee myös iroute:n etäaliverkolle, muuten vertaisreitti on olemassa, mutta asiakasliikennettä ei koskaan liitetä siihen.

Viides vaihe: varmista asiakkaalta ja kirjaa mikä muuttui

Sulje silmukka asiakkaalta, ei palvelimelta. Yhdistä LAN-isännän todelliseen palveluun ja varmista sitten, että käännöslaskurit ovat liikkuneet komennolla iptables -t nat -L POSTROUTING -v -n, koska sääntö ilman paketteja on sääntö, joka ei koskaan osunut. conntrack -L -s 10.8.0.5 näyttää virran ja sen tilan, kun tarvitset todisteen siitä, että paluusuuntaa seurataan.

Jätä muistiinpano palvelimen kokoonpanoon: mikä aliverkko, mikä liitäntä, mikä sääntö ja kuljettaako LAN-reititin paluureittiä. Kun asiakaspäivitys seuraavan kerran pyyhkii työnnetyn reitin, se muistiinpano muuttaa tulipalon sammutuksen yhden rivin korjaukseksi.