Publiseer 'n VPN-kliëntpoort van agter CGNAT: kontrolelys

Plaas 'n diens op 'n skootrekenaar agter carrier-grade NAT, wys daardie skootrekenaar na 'n VPS oor 'n VPN, en niemand buite kan dit bereik nie. Jy voeg 'n bestemming-NAT-reël op die VPS by en kry iets erger as stilte: verbindings open, dan stagneer hulle. Die antwoord is nie weg nie, dit verlaat via die kliënt se eie verstekroete, wat beteken die bediener sien dit nooit. Werk hierdie vyf kontroles in volgorde deur en stop by die eerste een wat nie hou nie.

Bevestig dat die bediener hoegenaamd sal aanstuur

Merk hierdie blokkie voordat jy 'n enkele vertaling skryf. 'n DNAT-reël vir 'n pakket wat die kernel weier om aan te stuur, word deur die reël-ontleder aanvaar en dan deur die aanstuurpad laat val, wat 'n tydsverloop oplewer wat soos 'n firewall-probleem lyk.

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

Om dit in 'n lopende kernel te stel is nie dieselfde as om dit oor 'n herlaai heen te stel nie. Skryf net.ipv4.ip_forward=1 in 'n lêer onder /etc/sysctl.d/, voer sysctl --system uit, en lees dan die waarde terug in plaas daarvan om te vertrou dat die lêer opgetel is. 'n Houer wat sy eie netwerknaamruimte bestuur, het dieselfde waarde binne daardie naamruimte nodig, nie net op die gasheer nie.

As die teruglees nog steeds nul is, stop hier. Niks verder sal werk nie.

Pen die tonneladres vas voordat enige reël daarna verwys

Die poel deel adresse in verbindingsorde uit, so 'n reël wat vir vandag se huurkontrak geskryf is, kan volgende week stilweg na 'n ander kliënt wys. Bind die adres aan die sertifikaat se identiteit eerder as aan aankomsorde.

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

Daardie paar is die kliëntkant en die ewekniekant van 'n punt-tot-punt-tonnel, met die bediener gesleutel op die sertifikaat se algemene naam. Onder 'n subnet-topologie word die tweede waarde eerder as 'n netmasker gelees, so skryf die vorm wat by die topologie in gebruik pas. Herverbind dan die kliënt en lees die adres op die kliënt self, want die bediener se siening van die poel is nie bewys van wat die kliënt opgestel het nie.

As die adres ná 'n herverbinding verander, stop. 'n NAT-reël wat 'n bewegende teiken volg, sal met tussenposes misluk en jou niks leer nie.

Vertaal in beide rigtings

Bestemmingsvertaling stuur die inkomende pakket na die kliënt. Bronvertaling is wat die kliënt die bediener laat antwoord eerder as die oorspronklike sender, en dit is die reël wat mense uitlaat.

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

Sonder die tweede reël antwoord die kliënt deur sy ISP-oplink, so die afgeleë eweknie sien 'n bronadres waarmee dit nooit gepraat het nie, terwyl die bediener geen naspeuringsinskrywing vir die antwoord het nie. Die buitestaander sien 'n handdruk wat halfvoltooi, wat presies die simptoom is wat mense 'n firewall-fout laat soek wat nie daar is nie.

Lees beide reëls terug met iptables -t nat -S en bevestig die koppelvlaknaam is die een wat die publieke adres dra. Op 'n gasheer wat reeds met nftables filter, skryf die vertaling in 'n nftables-NAT-ketting van die ooreenstemmende adresfamilie in plaas van om gereedskap te meng.

Laat die filtertabel deur

Die NAT-tabelle herskryf koptekste; hulle verleen nie toestemming nie. Met 'n verstek-DROP-beleid het die deurgestuurde vloei sy eie aanvaarding nodig, plus die terugrigting wat die meeste beleide reeds met 'n established,related-reël dek.

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

Kontroleer die beleid van die FORWARD-ketting voordat jy iets byvoeg, want die orde van 'n vroeë DROP bepaal of jou reël ooit geraadpleeg word. Op 'n gasheer wie se filtering in nftables woon, voeg die ekwivalente reël by die forward-haak van die inet-tabel en bevestig dat die basisketting werklik deurgestuurde verkeer sien, nie net plaaslike inset nie. As 'n pakketteller op die nuwe reël op nul bly terwyl die NAT-tellers styg, word die pakket voor jou reël laat val. Dit is die sein om die kettingorde te lees, nie om 'n tweede kopie van dieselfde reël by te voeg nie.

Bewys dit vanaf 'n buitenste netwerk

Toets vanaf 'n onverwante netwerk. 'n Peiling vanaf 'n ander masjien op dieselfde LAN kan deur hairpin-NAT-ondersteuning gaan en nooit die pad wat 'n afgeleë kliënt gebruik, beoefen nie, so 'n groen resultaat daar bewys die verkeerde ding.

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

Voer die opname op die bediener en op die kliënt op dieselfde tyd uit. Die bediener se opname wys of die vertaalde pakket na die tonnel vertrek; die kliënt se opname wys of die versoek aankom en waar die antwoord geadresseer is. 'n Vertalingsinskrywing in conntrack -L bewys die reël het gepas, en die afwesigheid daarvan bewys die pakket het nooit die NAT-ketting bereik nie.

Poortskandeerders is swak bewyse. Hulle rapporteer die poort as gesluit totdat die toepassing gebind is en luister, so gebruik 'n werklike verbinding na die werklike diens. Wanneer dit uiteindelik werk, hou die blootstelling by daardie een poort: om SSH of 'n administrasiepaneel deur te stuur omdat die eerste reël ongemaklik gevoel het, is 'n veel groter besluit as om 'n diens te publiseer.