Miksi lähiverkkosi ei tavoita VPN-asiakkaan palvelua

Tunnelisi on pystyssä, palvelu kuuntelee, eikä toimiston lähiverkko silti saa mitään takaisin. Kukaan ei rikkonut VPN:ää. Lähiverkon puolelta kannettavan tunneliosoitetta ei ole olemassa ennen kuin jokin kertoo lähiverkolle, miten sinne päästään, ja vastauksen on tultava takaisin samaa tietä kuin pyyntö meni ulos. Olen nähnyt ihmisten rakentavan täysin kunnossa olevan tunnelin uudelleen kolme kertaa ennen kuin kukaan katsoi paluupolkua.

Tunneli ei ole se, mikä rikkoutui

Molemmat päät istuvat yksityisissä osoiteavaruudissa, mikä on normaali tapaus eikä väärä kokoonpano. Osoite kuten 10.8.0.6 on todellinen tunnelin sisällä eikä ole olemassa missään muualla, joten lähiverkolla ei ole syytä lähettää sinne mitään. Ennen kuin kosket reititykseen, varmista että palvelu ylipäätään on tavoitettavissa tunnelin sisällä: asiakkaassa ss -ltn näyttää, sitoutuuko kuuntelija 127.0.0.1-osoitteeseen, lähiverkon rajapintaan vai tunneliosoitteeseen. Vain loopbackiin sidottu daemon ei vastaa kenellekään muulle kuin itselleen, eikä mikään reitti, DNAT tai portinohjaus muuta sitä.

Portin 80 tai 443 välityspalvelin on toinen työkalu, jolla on toinen näkyvyys. Se siirtää pyyntöjä, ei paketteja, joten se on väärä kerros raa'alle tietokantayhteydelle, ja juuri siihen tarttuminen johtaa siihen, että tämä ongelma päätyy kolme työkalua syvälle ennen kuin kukaan mittaa mitään.

Reitin muoto: kerro lähiverkolle, missä allas on

Staattinen reitti lähiverkon yhdyskäytävässä on puhtain vastaus, kun lähiverkko ja tunnelin allas eivät mene päällekkäin. Osoita allas koneeseen, joka päättää tunnelin:

ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12   # Windows, persistent

Se korjaa vain yhden suunnan, ja siksi tämän muutoksen puolivalmiit versiot näyttävät edistykseltä. Tunnelipuoli tarvitsee vastaavan puolikkaan, muuten vastaus lähtee asiakkaasta sen omaa oletusreittiä pitkin ja kuolee matkalla:

push "route 192.168.1.0 255.255.255.0"

Aliverkolle, joka on yhden asiakkaan takana eikä palvelimen takana, palvelin tarvitsee sekä järjestelmäreitin että iroute-merkinnän kyseisen asiakkaan tiedostoon client-config-dir-kohdassa. Ilman iroute-merkintää OpenVPN tietää, että etuliite on olemassa, eikä tiedä lainkaan, mikä asiakas sen omistaa: paketit saapuvat, eikä daemonilla ole mitään, mihin ne sovittaa.

Tässä on myytti, joka kannattaa nimetä. Reitti tekee osoitteesta tavoitettavan; se ei tee vastapuolesta halukasta vastaamaan. Sivusto-sivusto-kumppanit lisäävät siihen vielä yhden kerroksen, koska etäinen yhdyskäytävä hyväksyy vain lähteet, jotka ovat sen käytännössä lueteltujen etuliitteiden sisällä, eikä koti altaasta saapuva kannettava ole niiden sisällä.

NAT:n muoto: DNAT sisään ja SNAT-rivi, jonka kaikki ohittavat

Kun et voi koskea lähiverkon yhdyskäytävään tai haluat julkaista täsmälleen yhden portin, VPN-isännän käännös toimii ilman minkäänlaista reittiä lähiverkossa. Julkaise portti, välitä se eteenpäin ja käännä lähde matkalla tunneliin:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1

Kolmas rivi on se, joka jää pois. Ohita se, niin asiakas näkee alkuperäisen lähiverkon osoitteen lähteenä, vastaa oman oletusreittinsä kautta, ja vastaus suuntautuu tunneliin eikä takaisin lähiverkkoon. Jääkö yhteys henkiin, riippuu silloin reitityksestä, jota et koskaan suunnitellut. SNAT:n kanssa asiakas näkee palvelimen tunneliosoitteen, joten vastaus seuraa tunnelia takaisin ainoaan isäntään, joka voi perua käännöksen.

Kuluttajalaiteohjelmisto käyttää omia ketjunimiään eikä luo tuota käännöstä puolestasi. Tomatossa saapuva sääntö putoaa WANPREROUTING-ketjuun ja sitten suodatinketjuun kuten wanin, ja täydelliseltä näyttävä sääntöjoukko tarvitsee silti käsin kirjoitetun POSTROUTING-rivin. Se ei ole laiteohjelmiston virhe; se on sääntöjoukko, joka on kirjoitettu vain saapuvalle liikenteelle.

Miksi oikealta näyttävä sääntö silti pudottaa paketin

Useimmat näistä vioista eivät ole siinä säännössä, jota tuijotat. Tarkista neljä asiaa tässä järjestyksessä ja pysähdy ensimmäiseen, joka ei pidä:

• Ketjujen järjestys. iptables -I lisää alkuun ja -A lisää loppuun, joten aiempi salliva tai estävä sääntö ratkaisee ensin.
• Väärä ketju. Reitittimelle itselleen osoitettu liikenne kulkee INPUTin kautta, eikä edelleen välitetty liikenne kosketa sitä koskaan. Yhden palvelun julkaiseminen voi vaatia sääntöjä molemmissa.
• Suuntaliput. -i tun0 vastaa asiakkailta saapuvaa liikennettä ja -o tun0 heitä kohti lähtevää liikennettä. Väärällä lipulla varustettu REJECT estää jotain, mitä et tarkoittanut.
• Lähteen rajoitus. Edelleenvälitys, joka hyväksyy yhden asiakasosoitteen, toimii siitä asiakkaasta ja pudottaa kaikki muut lähteet sanaakaan sanomatta.

Sääntö, jonka pakettilaskuri on nolla, ei ole polulla lainkaan, ja laskurien lukeminen on nopein tapa erottaa väärän ketjun ongelma väärän säännön ongelmasta.

Paikallinen edelleenvälitys, kun lähiverkossa ei voi muuttaa mitään

SSH:n paikallinen edelleenvälitys kiertää koko kysymyksen. Se ei tarvitse reittiä lähiverkossa, asiakkaan palomuurin yhteistyötä eikä missään julkaistua porttia:

ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host

Palvelu ilmestyy silloin tunnelia pitävän koneen localhost:3000-osoitteeseen, eikä mihinkään muualle. Se on raja: yksi työasema, yksi portti, ja edelleenvälitys kuolee istunnon mukana, ellei jokin käynnistä sitä uudelleen. Testitietokantaa tarkistavalle ylläpitäjälle se on oikea työkalu. Kameralle tai skannerille, johon muiden ihmisten on päästävä, se ei ole, koska jokainen käyttäjä tarvitsisi oman välityksensä.

Varmista molemmat suunnat ennen kuin lisäät uuden säännön

Käännös jättää jälkiä, ja niiden lukeminen on parempaa kuin arvaaminen. VPN-isännässä conntrack -L näyttää, tapahtuiko käännös ylipäätään, iptables -t nat -L -n -v näyttää, liikkuivatko laskurit, ja tcpdump -ni any port 3000 näyttää, mikä lähdeosoite todella saapui. Asiakkaassa ss -ltn vahvistaa, että kuuntelija on osoitteessa, johon tunneli pääsee.

Valitse sitten se muoto, jonka pidät. Yksi julkaistu portti, reitti koko altaalle ja välitys yhdelle ylläpitäjälle ovat kolme eri sitoumusta, ja niiden sekoittaminen on se tapa, jolla toimivasta kokoonpanosta tulee sellainen, jota kukaan ei osaa selittää puolen vuoden päästä. Kirjoita muistiin, mikä osoite on mistäkin tavoitettavissa, ja seuraava tätä debuggaava aloittaa vastauksesta eikä tunnelista.