Julkaise LAN-palvelu VPN-yhdyskäytävän omassa osoitteessa

LAN-laitteen esittäminen yhdessä yhdyskäytävän omista tunneliosoitteista vaatii yhden rivin NATia. Yhteys epäonnistuu silti, koska vastaava laite ei tiedä, että asiakkaan osoite on tavoitettavissa tuon yhdyskäytävän kautta. Käy paketti läpi asiakkaasta sisäänpäin ja sitten vastaus takaisin ulospäin, niin puuttuva puolisko tulee ilmeiseksi.

Aloita asiakkaan näkökulmasta

Tämän esimerkin asiakas on VPN-altaassa 10.62.0.0/24 ja yhdistää osoitteeseen 10.62.0.1 portissa 8080. Osoite kuuluu yhdyskäytävälle itselleen, joten paketti saapuu yhdyskäytävän ytimeen eikä toiselle vertaiselle. Yhdyskäytävän takana LAN on 172.21.4.0/24. Yhdyskäytävällä on 172.21.4.10, ja laite, joka todella palvelee HTTP:tä, on 172.21.4.40.

Toiselle VPN-vertaiselle kuuluva osoite ei ole vaihdettavissa yhdyskäytävän palveluosoitteeseen. Jos asiakas yhdistää vertaisen osoitteeseen, mikään yhdyskäytävän sääntö ei ole mukana lainkaan, ja koko tämä läpikäynti on väärä.

Rajaa kohdeosoitteen käännös tarkoituksella

Kapea versio esittää yhden portin ja kirjoittaa uudelleen vain kohteen. Paketti säilyttää protokollansa ja lähteensä, ja juuri se tekee loppumatkasta kiinnostavan.

iptables -t nat -A PREROUTING -i tun0 -s 10.62.0.0/24 -d 10.62.0.1 -p tcp --dport 8080 -j DNAT --to-destination 172.21.4.40:80

Sääntö ilman protokollan ja portin ehtoja on leveä versio: se säilyttää minkä tahansa portin, jonka asiakas valitsi, ja muuttaa vain osoitetta. Se on perusteltua, kun koko isäntä on tarkoitus esittää, ja väärin, kun tarkoitus oli yksi palvelu. Lue sääntö takaisin ja vahvista liitännän nimi. Väärän liitännän DNAT-sääntö ei vastaa mitään, mikä tuottaa saman aikakatkaisun kuin puuttuva sääntö ja tuhlaa tunnin laitteen katseluun.

Anna välitysrajan olla samaa mieltä

Käännös muuttaa otsaketta, mutta ei myönnä lupaa. Oletusarvoisella hylkäyskäytännöllä välitetty virtaus tarvitsee oman hyväksyntänsä, ja paluusuunta tarvitsee vakiintuneen yhteyden säännön, joka käytännössäsi todennäköisesti jo on.

iptables -A FORWARD -i tun0 -o lan0 -d 172.21.4.40 -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Ehdoton hyväksyntä jokaiselle DNAT-virtaukselle on leveämpi kuin tämä suunnittelu ja sallii myös yhdistämiset, jotka joku muu lisää myöhemmin. Nimeä kohde ja portti ja jätä loput suljetuksi. Jos välityssäännön laskurit pysyvät nollassa NAT-laskurien noustessa, paketti pudotetaan ennen sääntöäsi. Lue ketjujen järjestys sen sijaan, että lisäisit toisen kopion.

Laitteen on vastattava jotenkin

Käännöksen jälkeen laite näkee lähteen osoitteessa 10.62.0.0/24. Sen vastaus menee oletusyhdyskäytävälle, joka on LAN-reititin, ei VPN-yhdyskäytävä, ellei jokin kerro sille muuta. Kaksi järjestelyä korjaa sen, eivätkä ne ole samanarvoisia. Reitti laitteessa tai LAN-reitittimessä lähettää 10.62.0.0/24:n osoitteeseen 172.21.4.10 ja säilyttää asiakkaan lähteen. Rajattu lähdeosoitteen käännös piilottaa asiakkaan sen sijaan yhdyskäytävän LAN-osoitteen taakse.

ip route add 10.62.0.0/24 via 172.21.4.10 dev eth1
iptables -t nat -A POSTROUTING -s 10.62.0.0/24 -d 172.21.4.40 -o lan0 -p tcp --dport 80 -j SNAT --to-source 172.21.4.10

Valitse sen mukaan, mitä palvelu tarvitsee. Asiakaskohtainen käytäntö ja merkitykselliset lokit haluavat reititetyn muodon; laite, jolle ei voi antaa reittiä, tai palvelu, jonka on yksinkertaisesti nähtävä LAN-osoite, osoittavat käännettyyn muotoon. Älä tartu globaaliin masquerade-sääntöön, jotta yksi vastaus toimisi. Se piilottaa jokaisen asiakkaan jokaiselta kohteelta ja rikkoo hiljaa käytännöt, jotka riippuvat lähdeosoitteista.

Älä testaa yhdyskäytävästä itsestään

Yhdyskäytävällä osoitteeseen 10.62.0.1 luotu pyyntö lähtee OUTPUT-ketjun kautta, ei saapuvan PREROUTINGin kautta. Sen epäonnistuminen tai onnistuminen ei kerro mitään asiakkaaseen päin olevasta säännöstä, ja juuri niin ihmiset päätyvät siihen, että toimiva sääntö on rikki.

conntrack -L | grep 172.21.4.40
tcpdump -ni any 'port 8080 or port 80'

Aja todellinen asiakaspyyntö ja lue molemmat. conntrack-merkintä näyttää käytetyn käännöksen, ja kaappaukset näyttävät, ylittikö pyyntö LANiin ja tuliko vastaus takaisin tunnelia kohti. Käytä uutta yhteyttä sääntöjen muuttamisen jälkeen, koska olemassa oleva tila pitää aiemman yhdistämisensä ja epäonnistuu edelleen vanhaan tapaan. Vahvista sitten koko keskustelu: laitteen osoite, välityslupa ja vastauksen reitti kuvaavat kaikki samaa virtausta.