VPN-asiakkaan palveluun pääseminen: käänteinen tunneli vai DNAT

Jopa operaattorin NATin takana oleva kannettava voi palvella kollegaa, kunhan VPN-palvelin toimii kohtaamispaikkana. Sinne johtaa kaksi mekanismia: asiakas soittaa ulospäin ja pyytää palvelinta pitämään kuunteluporttia, tai palvelin julkaisee portin ja kääntää sen tunneliin. Molemmat ratkaisevat saman tavoitettavuusongelman ja käyttäytyvät eri tavoin vian, valvonnan ja lokituksen aikana. Kolme ehtoa ratkaisee, kumpi kuuluu sinun kokoonpanoosi.

Kaksi muotoa, yksi kohtaamispaikka

Ensimmäisessä muodossa asiakas avaa SSH-istunnon ulospäin ja pyytää palvelinta kuuntelemaan valitulla portilla ohjaten jokaisen yhteyden takaisin saman istunnon kautta. Palvelimella ei ohjata mitään eteenpäin eikä pakettikäännöstä tapahdu, joten ainoat vaatimukset ovat SSH-tili, sallittu edelleenohjaus ja portin palomuurisääntö. Palvelu pysyy sidottuna asiakkaan loopbackiin, mikä on yleensä se, mitä halutaan.

ssh -N -R 8081:127.0.0.1:8080 -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 [email protected]

Toisessa muodossa palvelin omistaa julkisen portin ja kirjoittaa jokaisen yhteyden uudelleen asiakkaan tunneliosoitteeseen päin. Se vaatii IP-edelleenohjauksen käyttöön, kohdekäännöksen sisääntulossa ja lähdekäännöksen ulostulossa, ja se toimii edelleen, kun SSH-istuntoa ei ole. Portti kuuluu palvelimelle eikä istunnolle, ja juuri tämä ominaisuus ratkaisee useimmat todelliset tapaukset.

Kumpikaan muoto ei ole rakenteellisesti turvallisempi. Molemmat altistavat yhden palveluportin kaikille, jotka pääsevät palvelimen julkiseen osoitteeseen, ja molemmat ovat edelleen riippuvaisia palvelun omasta todennuksesta.

Ehto yksi: täytyykö portin elää istuntoa pidempään

Käänteinen edelleenohjaus elää täsmälleen niin kauan kuin sen luonut SSH-istunto. Kun yhteys katkeaa, kuuntelija katoaa ja kollega näkee hitaan polun sijasta hylätyn yhteyden. Komennon valvonta systemd-yksiköllä ja uudelleenkäynnistyskäytännöllä korjaa tämän, ja ExitOnForwardFailure=yes tekee epäonnistuneen sidonnan heti näkyväksi sen sijaan, että jättäisi istunnon ilman edelleenohjausta.

Käännetty portti selviää uudelleenkäynnistyksistä, jos säännöt tallennetaan pysyvästi, mutta se riippuu siitä, että asiakas säilyttää saman tunneliosoitteen. Dynaaminen allas, joka antaa kannettavalle eri osoitteen uudelleenyhdistämisen jälkeen, osoittaa säännön hiljaa tyhjään. Varaa tunneliosoite ensin, kirjoita sääntö vasta sitten ja käsittele molempia yhtenä muutoksena.

Jos palvelun on vastattava kolmelta aamuyöllä ilman ketään katsomassa, palvelimen julkaiseman portin muodossa on vähemmän liikkuvia osia, koska ainoa prosessi, jonka on pysyttävä pystyssä, on itse tunneli.

Ehto kaksi: kuka omistaa palomuurin ja lokit

Käänteinen muoto pitää kaiken käytännön kahdessa paikassa. sshd päättää AllowTcpForwarding kautta, ovatko etäedelleenohjaukset ylipäätään sallittuja, ja GatewayPorts päättää, sitoutetaanko kuuntelija loopbackiin vai jokaiseen osoitteeseen. Oletusarvolla no palvelimen ulkopuolinen kollega ei pääse porttiin, vaikka edelleenohjaus onnistui, ja se näyttää rikkinäiseltä tunnelilta, vaikka kyse on todellisuudessa sidontaosoitteesta.

sudo ss -ltn '( sport = :8081 )'
sudo grep -E '^(GatewayPorts|AllowTcpForwarding)' /etc/ssh/sshd_config

Käännetty muoto vaatii käyttöön otetun edelleenohjauksen ja kaksi sääntöä, ja toinen sääntö on se, missä useimmat ohjeet menevät pieleen. Lähdekäännöksen rajaaminen conntrack-tilaan DNAT tarkoittaa, että uudelleen kirjoitetaan vain ne yhteydet, jotka kohdesääntö loi, eikä jokaista pakettia, jonka palvelin lähettää tunneliin.

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8081 -j DNAT --to-destination 10.88.0.6:8080
sudo iptables -t nat -A POSTROUTING -o tun0 -m conntrack --ctstate DNAT -j SNAT --to-source 10.88.0.1

Tämä uudelleenkirjoitus tuhoaa myös kohdistuksen. Sen jälkeen asiakas näkee jokaisen soittajan palvelimen tunneliosoitteena, mikä romahduttaa minkä tahansa osoitekohtaisen nopeusrajan yhteen ämpäriin ja kätkee, kuka lähetti mitä. Jos kohdistus on tärkeä, lopeta yhteys palvelimella tai pidä lupapäätös siellä ja välitä identiteetti otsakkeessa, johon palvelu luottaa. Valinta näiden kahden korjauksen välillä riippuu siitä, lukeeko palvelu lainkaan välityspalvelinotsaketta.

Ehto kolme: yksi portti vai monta, ja kuka omistaa nimen

Yksi palvelu yhdellä portilla on tapaus, jossa käänteinen edelleenohjaus voittaa vaivassa. Tarvitset yhden komennon, yhden tilin ja yhden palomuurisäännön, ja siivoaminen on istunnon tappamista. Useat palvelut samassa julkisessa osoitteessa työntävät sinua palvelimen julkaisemaan muotoon, koska jokainen käänteinen edelleenohjaus tarvitsee oman palvelinportin ja joukko kasvaa jokaisen palvelun myötä.

Nimet mutkistavat asiaa. Käänteinen edelleenohjaus voi olla TCP-välityspalvelimen takana, joka reitittää SNIn mukaan, kun taas käännetty portti on yleensä yksi portti palvelua kohden. Jos palvelu lopettaa TLSin itse ja tarvitsee alkuperäisen isäntänimen, välityspalvelinratkaisu säilyttää sen, ja DNAT-ratkaisu säilyttää sen vain, jos palvelu hyväksyy kyseisen nimen kyseisellä portilla.

Kirjoita muistiin, mikä kolmesta ehdosta ratkaisi muodon. Muuten seuraava henkilö, joka lisää toisen palvelun, avaa saman vertailun uudelleen vähemmällä kontekstilla.

Päätä ja testaa sitten ulkopuolelta

Testaa polku verkosta, jolla ei ole reittiä kannettavalle, ja seuraa palvelimen laskureita pyynnön aikana. Testaaminen palvelimelta sen omaan julkiseen osoitteeseen ei todista tässä mitään, koska paketti luodaan paikallisesti eikä se koskaan saavuta saapuvan käännöksen koukkua, joten testi voi mennä läpi, vaikka todellinen polku on rikki.

sudo iptables -t nat -L PREROUTING -n -v
sudo tcpdump -ni any 'tcp port 8081' -c 20

Litteinä pysyvät laskurit tarkoittavat, ettei paketti koskaan saapunut säännölle, mikä viittaa palveluntarjoajaan tai isännän palomuuriin. Laskurit, jotka liikkuvat palvelun hylätessä, viittaavat asiakkaan omaan palomuuriin tai osoitteeseen, jolla palvelu kuuntelee. Tunneli, joka kuljettaa paketin mutta ei palauta mitään, on reitti- tai paluupolkuongelma, eikä mitään näistä kolmesta tuloksesta pitäisi debugata muokkaamalla asiakkaan sovitinta. Kirjoita muistiin, mikä laskuri liikahti, ennen kuin muutat mitään, koska seuraava testi tarvitsee sen lähtötason.

Kun muoto toimii, kirjaa portti, omistaja ja valvontatapa tunnelin kokoonpanon viereen. Tavoitettavuuskorjaus, joka on olemassa vain jonkun komentotulkin historiassa, on yhden uudelleenkäynnistyksen päässä toistuvasta tapauksesta.