Julkaise VPN-asiakasportti CGNATin takaa: tarkistuslista

Aseta palvelu kannettavaan tietokoneeseen operaattoritason NATin taakse, ohjaa se kannettava VPN:n kautta VPS:ään, eikä kukaan ulkopuolella pääse siihen. Lisäät VPS:ään kohde-NAT-säännön ja saat jotain pahempaa kuin hiljaisuuden: yhteydet avautuvat ja pysähtyvät sitten. Vastaus ei puutu, se lähtee asiakkaan omalta oletusreitiltä, mikä tarkoittaa, ettei palvelin näe sitä koskaan. Käy nämä viisi tarkistusta järjestyksessä läpi ja pysähdy ensimmäiseen, joka ei pidä.

Varmista, että palvelin ylipäätään välittää

Rastita tämä ruutu ennen kuin kirjoitat yhtään käännöstä. Ydinkäyttöjärjestelmän välittämisestä kieltäytyvän paketin DNAT-säännön sääntöjäsentäjä hyväksyy ja sitten välityspolku hylkää, mikä tuottaa aikakatkaisun, joka näyttää palomuuriongelmalta.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1

Sen asettaminen käynnissä olevaan ytimeen ei ole sama asia kuin asettaminen uudelleenkäynnistyksen yli. Kirjoita net.ipv4.ip_forward=1 tiedostoon /etc/sysctl.d/-hakemistossa, suorita sysctl --system ja lue arvo sitten takaisin sen sijaan, että luottaisit tiedoston tulleen poimituksi. Säiliö, joka hallinnoi omaa verkkonimiavaruuttaan, tarvitsee saman arvon kyseisen nimiavaruuden sisällä, ei vain isännässä.

Jos takaisinluku on edelleen nolla, pysähdy tähän. Mikään alempana ei toimi.

Kiinnitä tunnelin osoite ennen kuin mikään sääntö viittaa siihen

Allas jakaa osoitteita yhteyksien järjestyksessä, joten tämän päivän vuokralle kirjoitettu sääntö voi ensi viikolla hiljaa osoittaa toiseen asiakkaaseen. Sido osoite varmenteen identiteettiin äläkä saapumisjärjestykseen.

client-config-dir /etc/openvpn/ccd
ifconfig-push 10.77.0.14 10.77.0.13

Tuo pari on pisteestä pisteeseen -tunnelin asiakaspää ja vertaispää, ja palvelin on sidottu varmenteen yleisnimeen. Aliverkkotopologiassa toinen arvo luetaan sen sijaan verkkopeitteenä, joten kirjoita käytössä olevaan topologiaan sopiva muoto. Yhdistä asiakas sitten uudelleen ja lue osoite asiakkaasta itsestään, sillä palvelimen näkemys altaasta ei ole todiste siitä, mitä asiakas konfiguroi.

Jos osoite muuttuu uudelleen yhdistämisen jälkeen, pysähdy. Liikkuvaa kohdetta seuraava NAT-sääntö epäonnistuu ajoittain eikä opeta sinulle mitään.

Käännä molempiin suuntiin

Kohdekäännös lähettää saapuvan paketin asiakkaalle. Lähdekäännös on se, joka saa asiakkaan vastaamaan palvelimelle eikä alkuperäiselle lähettäjälle, ja se on sääntö, jonka ihmiset jättävät pois.

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 29443 -j DNAT --to-destination 10.77.0.14:29443
iptables -t nat -A POSTROUTING -d 10.77.0.14 -p tcp --dport 29443 -j SNAT --to-source 10.77.0.13

Ilman toista sääntöä asiakas vastaa oman ISP:n ylälinkkinsä kautta, joten etävertais näkee lähdeosoitteen, jonka kanssa se ei ole koskaan puhunut, samalla kun palvelimella ei ole vastaukselle seurantamerkintää. Ulkopuolinen tarkkailija näkee kättelyn, joka täydentyy puoliksi, ja juuri se oire saa ihmiset etsimään palomuurivikaa, jota ei ole.

Lue molemmat säännöt takaisin komennolla iptables -t nat -S ja varmista, että liittymän nimi on se, joka kantaa julkista osoitetta. Isännässä, joka jo suodattaa nftablesilla, kirjoita käännös sopivan osoiteperheen nftables-NAT-ketjuun sen sijaan, että sekoitat työkaluja.

Päästä suodatintaulu läpi

NAT-taulut kirjoittavat otsikot uudelleen; ne eivät myönnä lupaa. Oletusarvoisella DROP-käytännöllä välitetty virta tarvitsee oman hyväksyntänsä sekä paluusuunnan, jonka useimmat käytännöt jo kattavat established,related-säännöllä.

iptables -A FORWARD -i eth0 -o tun0 -p tcp --dport 29443 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Tarkista FORWARD-ketjun käytäntö ennen kuin lisäät mitään, sillä varhaisen DROPin järjestys ratkaisee, kysytäänkö sääntöäsi koskaan. Isännässä, jonka suodatus elää nftablesissa, lisää vastaava sääntö inet-taulun forward-koukkuun ja varmista, että perusketju todella näkee välitetyn liikenteen eikä vain paikallista syötettä. Jos uuden säännön pakettilaskuri pysyy nollassa NAT-laskurien noustessa, paketti pudotetaan ennen sääntöäsi. Se on merkki ketjujen järjestyksen lukemisesta, ei saman säännön toisen kopion lisäämisestä.

Todista se ulkoisesta verkosta

Testaa verkosta, joka ei liity asiaan. Toisen koneen koe samassa lähiverkossa voi kulkea hairpin-NAT-tuen kautta eikä harjoita koskaan reittiä, jota etäasiakas käyttää, joten vihreä tulos siellä todistaa väärää asiaa.

tcpdump -ni any port 29443
conntrack -L | grep 29443

Suorita kaappaus palvelimella ja asiakkaalla samanaikaisesti. Palvelimen kaappaus näyttää, lähteekö käännetty paketti tunnelia kohti; asiakkaan kaappaus näyttää, saapuuko pyyntö ja mihin vastaus on osoitettu. Käännösmerkintä komennossa conntrack -L todistaa, että sääntö osui, ja sen puuttuminen todistaa, ettei paketti koskaan saavuttanut NAT-ketjua.

Porttiskannerit ovat heikko todiste. Ne ilmoittavat portin suljetuksi, kunnes sovellus on sidottu ja kuuntelee, joten käytä todellista yhteyttä todelliseen palveluun. Kun se vihdoin toimii, pidä altistus tuossa yhdessä portissa: SSH:n tai hallintapaneelin välittäminen siksi, että ensimmäinen sääntö tuntui kömpelöltä, on paljon suurempi päätös kuin palvelun julkaiseminen.