Pitäisikö SNAT ottaa käyttöön portin edelleenohjauksessa VPN-aliverkkoon?

Portin edelleenohjaus isäntään, joka on reitittimen oman VPN-asiakkaan takana, epäonnistuu tavalla, joka näyttää palomuuriongelmalta, koska pyyntö saapuu selvästi. Palvelu kirjaa yhteyden, asiakas odottaa, eikä mitään tule takaisin. Kohdeosoitteen käännös teki tehtävänsä; paluupaketti on se osa, joka katosi. Yksi valikoiva lähde-NAT-sääntö reitittimessä korjaa sen, ja kiinnostava osa on päättää, kuinka kapea tuo sääntö voi olla.

Miksi vastaus kulkee eri tietä

Portin edelleenohjaus kirjoittaa uudelleen, minne paketti menee, ei koskaan sitä, mistä se tuli. Internet-asiakkaan osoite pysyy lähdekentässä koko tunnelin matkan, joten etäpalvelu näkee vieraan ja vastaa ainoalla tavalla, jonka tuntee: oman oletusyhdyskäytävänsä kautta. Se yhdyskäytävä on vastakkaisella puolella oleva VPN-keskitin, jolla ei ole reittiä takaisin mielivaltaiseen julkiseen osoitteeseen.

Katso kaappausta tunneliliitännällä, ja epäsymmetria on ilmeinen: pyyntöpaketit ulos, ei mitään sisään. Edelleenohjausketju salli virtauksen ja tunneli kuljetti sen, joten pudotus tapahtuu sen jälkeen, kun etäisäntä on jo valinnut paluupolun.

Lähdesääntö, joka on tarpeeksi kapea luotettavaksi

Tee reitittimestä lähde, johon etäisäntä vastaa. Tässä asetelmassa WAN-osoite on 203.0.113.24, LAN on 192.168.88.0/24, reitittimen tunneliosoite on 172.20.5.1 ja palvelu vastaa osoitteessa 172.20.5.40:8443. Alla oleva sääntö osuu pakettiin kohdeosoitteen käännöksen jälkeen, siksi se nimeää käännetyn osoitteen eikä julkista. Mikään siinä ei riipu asiakkaan osoitteesta, ja juuri se on pointti.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

Jokainen tuon rivin osuma on olemassa, jotta uudelleenkirjoitus pysyy paikallisena yhdelle palvelulle yhdessä tunnelissa. Poista liitäntä tai portti, ja kirjoitat uudelleen enemmän liikennettä kuin ongelma vaatii, ja näin kohdennettu korjaus muuttuu seuraavalle ihmiselle arvoitukseksi.

Milloin yleinen maskeraus on rehellinen valinta

Jos reititin ohjaa monta palvelua samaan VPN-aliverkkoon, palvelukohtaisesta säännöstä tulee lista, jota kukaan ei ylläpidä. Kaiken tunneliliitännältä lähtevän maskaaminen on yksinkertaisempaa ja ennustettavampaa, mutta sen hinta on alkuperäisen asiakkaan piilottaminen jokaiselta vastakkaisen puolen isännältä. Valitse se, kun siellä olevia lokeja ei käytetä attribuutioon; pidä kapea sääntö, kun käytetään.

Molemmat vaihtoehdot myös epäonnistuvat eri tavoin. Puuttuva kapea sääntö rikkoo yhden palvelun; liian paljon osumia saava laaja maskeraus voi hiljaa kirjoittaa uudelleen liikennettä, joka jo toimi, mukaan lukien reitittimen omat lähtevät yhteydet.

Tarkista laskurit ennen julkaisua

Säännöt, jotka eivät koskaan osu, näyttävät samalta kuin toimivat säännöt, kunnes lasket paketteja. Lue taulukko uudelleen tavulaskureineen ennen kuin mikään asiakas yhdistää, yhdistä sitten verkosta, joka ei ole LAN, ja lue se uudelleen. Kaksi lukemaa on se, mikä muuttaa arvauksen tosiasiaksi. Julkaise edelleenohjaus vasta, kun toinen liikahtaa.

iptables -t nat -L POSTROUTING -v -n --line-numbers

Nollalaskuri lähdesäännöllä todellisen yhteyden jälkeen tarkoittaa, että osuma on väärä, yleensä siksi, että kohde tai portti ei vastaa käännöksen jälkeistä pakettia. Jos laskuri kasvaa mutta asiakas silti aikakatkaistaan, paluupolku on korjattu ja jokin muu pudottaa vastauksen, joten katso seuraavaksi vastakkaisen puolen edelleenohjauskäytäntöä. LANin sisältä tuleva hairpin-käyttö on erillinen ongelma ja tarvitsee oman sääntönsä, ei tämän leveämpää versiota.