Publikigu VPN-klientan pordon malantaŭ CGNAT: kontrol-listo

Metu servon sur tekkomputilon malantaŭ operator-nivela NAT, direktu tiun tekkomputilon al VPS tra VPN, kaj neniu ekstere povas atingi ĝin. Vi aldonas cel-NAT-regulon sur la VPS kaj ricevas ion pli malbonan ol silento: konektoj malfermiĝas, poste haltas. La respondo ne mankas, ĝi eliras laŭ la propra implicita vojo de la kliento, kio signifas, ke la servilo neniam vidas ĝin. Trairu ĉi tiujn kvin kontrolojn laŭorde kaj haltu ĉe la unua, kiu ne tenas.

Konfirmu, ke la servilo entute plusendos

Marku ĉi tiun skatolon antaŭ ol skribi eĉ unu tradukon. DNAT-regulon por paketo, kiun la kerno rifuzas plusendi, akceptas la regulanalizilo kaj poste forĵetas ĝin la plusenda vojo, kio produktas tempolimon, kiu aspektas kiel fajroŝirma problemo.

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

Agordi ĝin en kuranta kerno ne samas al agordi ĝin trans restarto. Skribu net.ipv4.ip_forward=1 en dosieron sub /etc/sysctl.d/, rulu sysctl --system, poste relegu la valoron anstataŭ fidi, ke la dosiero estis prenita. Ujo, kiu administras sian propran retan nomspacon, bezonas la saman valoron ene de tiu nomspaco, ne nur sur la gastiganto.

Se la relegado ankoraŭ estas nulo, haltu ĉi tie. Nenio malsupre funkcios.

Fiksu la tunelan adreson antaŭ ol iu ajn regulo referencas al ĝi

La baseno disdonas adresojn laŭ konekta ordo, do regulo skribita por la hodiaŭa luo povas silente montri al alia kliento venontsemajne. Ligu la adreson al la identeco de la atestilo anstataŭ al alvena ordo.

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

Tiu paro estas la klienta fino kaj la partnera fino de punkt-al-punkta tunelo, kun la servilo ŝlosita al la komuna nomo de la atestilo. Sub subreta topologio la dua valoro estas legata kiel retmaska anstataŭe, do skribu la formon, kiu kongruas kun la uzata topologio. Poste rekonektu la klienton kaj legu la adreson sur la kliento mem, ĉar la vido de la servilo pri la baseno ne pruvas, kion agordis la kliento.

Se la adreso ŝanĝiĝas post rekonekto, haltu. NAT-regulo, kiu sekvas moviĝantan celon, malsukcesos intermitente kaj instruos al vi nenion.

Traduku ambaŭdirekte

Cel-traduko sendas la envenan paketon al la kliento. Fonta traduko estas tio, kio igas la klienton respondi al la servilo anstataŭ al la origina sendinto, kaj ĝi estas la regulo, kiun homoj preterlasas.

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

Sen la dua regulo la kliento respondas tra sia ISP-suprenligo, do la fora partnero vidas fontan adreson, al kiu ĝi neniam parolis, dum la servilo tenas neniun spurregistron por la respondo. La ekstera observanto vidas manpremon, kiu duone finiĝas, kaj tio estas ĝuste la simptomo, kiu sendas homojn serĉi fajroŝirman cimon, kiu ne ekzistas.

Religu ambaŭ regulojn per iptables -t nat -S kaj konfirmu, ke la interfaca nomo estas tiu, kiu portas la publikan adreson. Sur gastiganto, kiu jam filtradas per nftables, skribu la tradukon en nftables-NAT-ĉenon de la kongrua adresfamilio anstataŭ miksi ilojn.

Lasu la filtran tabelon trairi

La NAT-tabeloj reskribas kapliniojn; ili ne donas permeson. Kun implicita DROP-politiko la plusendata fluo bezonas sian propran akcepton, plus la returnan direkton, kiun plej multaj politikoj jam kovras per regulo established,related.

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

Kontrolu la politikon de la FORWARD-ĉeno antaŭ ol aldoni ion, ĉar la ordo de frua DROP decidas, ĉu via regulo entute estos konsultita. Sur gastiganto, kies filtrado vivas en nftables, aldonu la ekvivalentan regulon al la forward-hoko de la inet-tabelo kaj konfirmu, ke la baza ĉeno vere vidas plusendatan trafikon kaj ne nur lokan enigon. Se paketnombrilo sur la nova regulo restas ĉe nulo dum la NAT-nombriloj altiĝas, la paketo estas forĵetata antaŭ via regulo. Tio estas la signo legi la ordon de la ĉenoj, ne aldoni duan kopion de la sama regulo.

Pruvu ĝin el ekstera reto

Testu el senrilata reto. Sondado el alia maŝino en la sama LAN povas pasi tra hairpin-NAT-subteno kaj neniam ekzercas la vojon, kiun uzas fora kliento, do verda rezulto tie pruvas la malĝustan aferon.

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

Rulu la kaptadon sur la servilo kaj sur la kliento samtempe. La servila kaptado montras, ĉu la tradukita paketo eliras al la tunelo; la klienta kaptado montras, ĉu la peto alvenas kaj kien la respondo estas adresita. Traduka registraĵo en conntrack -L pruvas, ke la regulo kongruis, kaj ĝia manko pruvas, ke la paketo neniam atingis la NAT-ĉenon.

Portskaniloj estas malforta pruvo. Ili raportas la pordon kiel fermitan ĝis la aplikaĵo estas ligita kaj aŭskultas, do uzu realan konekton al la reala servo. Kiam ĝi fine funkcias, tenu la eksponon al tiu unu pordo: plusendi SSH aŭ administran panelon ĉar la unua regulo sentiĝis mallerta estas multe pli granda decido ol publikigi servon.