Kial VPN-servilo malantaŭ CGNAT neniam akceptas konektojn

La enkursigilo raportas WAN-adreson komenciĝantan per 100.72, la dinamika DNS-nomo solviĝas al alia publika adreso, kaj la VPN-servilo sur tiu enkursigilo neniam kompletigas manpremon de ekstere. Pordoadreso estas agordita, la servo funkcias, kaj testo el la loka reto ankoraŭ sukcesas. Nenio en la enkursigila protokolo aspektas kiel eraro. Tiu kombinaĵo estas operatornivela NAT, kaj neniu fajroŝirma regulo povas malfermi pordon sur adreso, kiun la provizanto tenas.

Konfirmi la dividitan adreson daŭras du minutojn kaj malhelpas semajnon da agordaj ŝanĝoj.

La signoj, kiuj montras al operatora NAT

Komparu la WAN-adreson sur la stata paĝo de la enkursigilo kun la adreso, kiun raportas ekstera serĉo. WAN-adreso ene de 100.64.0.0/10 estas la kutima signo, kaj la privataj intervaloj 10/8, 172.16/12 kaj 192.168/16 signifas la samon. Se traceroute montras la saman publikan salton ripetite, aŭ frua salto respondas per privata adreso, alia tradukilo sidas inter la enkursigilo kaj la interreto. Iuj provizantoj listigas la atribuitan adreson nur en la klienta portalo, do eksportu tiun valoron kune kun la traceroute.

Ŝanĝi protokolojn aŭ pordojn ne helpas, ĉar la problemo estas envenanta atingeblo, ne fermita pordo.

Kial plusendo kaj dinamika DNS ne povas ripari ĝin

Pordoadresa regulo mapas pordon sur la WAN-interfaco de la enkursigilo, sed envenanta trafiko neniam atingas tiun interfacon: la provizanto unue tradukas ĝin kaj plusendas nur tion, kion permesas ĝia propra tabelo. Publikigi la dividitan adreson en dinamika DNS direktas klientojn al provizanta kluzo uzata de multaj abonantoj, tial la nomo solviĝas kaj la manpremo ankoraŭ malsukcesas. Hairpin-testoj sukcesas ĉar la enkursigilo respondas sian propran regulon de interne, kaj UPnP havas precize la saman blindan makulon.

Ankaŭ reagordi la klienton ne helpos, ĉar la fiasko okazas antaŭ ol iu ajn klienta agordo estas legata.

Plusendu tra VPS kun eksplicitaj vojoj

Metu publikan adreson antaŭe per lui la plej malgrandan VPS, kiu povas porti la trafikon, poste igi la hejman enkursigilon elkonekti al ĝi. Eliranta UDP el la hejma reto trapasas operatoran NAT, do la tunelo establiĝas de interne kaj la VPS fariĝas la atingebla finpunkto. La hejma flanko fariĝas kliento kun fiksa tunela adreso, ne servilo.

Sur la VPS aldonu klient-specifan dosierujan eron, por ke la servilo sciu, kiu samtavolo posedas la hejman subreton, kaj aldonu kongruan kernan vojon.

# /etc/openvpn/server/ccd/home-site.conf
ifconfig-push 10.8.0.10 255.255.255.0
iroute 192.168.50.0 255.255.255.0

# server.conf
client-config-dir /etc/openvpn/server/ccd
route 192.168.50.0 255.255.255.0
push "route 10.8.0.0 255.255.255.0"

La linio iroute diras al OpenVPN, kiu kliento ricevas trafikon por la hejma subreto; la linio route metas tiun subreton en la kernan tabelon de la VPS, por ke pakaĵoj entute eniru la tunelon. Por publikigita servo aldonu destinacian NAT-regulon, kiu plusendas la publikan pordon al 10.8.0.10, kaj ebligu net.ipv4.ip_forward.

Testu la vojon de ekstere

Kontrolu ĉiun salton sur la publika flanko, ĉar sukcesa tunelo ne pruvas, ke la servo estas atingebla. Aŭskulta stato kaj pakaĵa kaptado sur la VPS apartigas 'nenio alvenis' de 'alvenis kaj estis forĵetita'.

ss -lunp | grep 1194
tcpdump -ni any udp port 1194
nft list ruleset | grep -A4 dnat

# from a phone on mobile data, not the home Wi-Fi
nc -vz -u 203.0.113.10 1194

Se la kaptado montras pakaĵojn de la telefono sed neniun respondon, la sekva halto estas la servila agordo aŭ la fajroŝirmilo. Se la kaptado montras nenion, la kliento ankoraŭ solvas aŭ sendas al la malĝusta adreso.

Alternativoj indaj je unua prikalkulo

Dediĉita IPv4-adreso de la provizanto estas la plej mallonga solvo kaj kutime malgranda monata kotizo. Denaska IPv6 forigas tradukadon ĉe ambaŭ finoj, kiam la VPN, la klienta reto kaj la DNS-rikordoj ĉiuj portas ĝin. Mesh-tavolo kun subreta enkursigilo ene de la hejma reto atingas la saman plusendon sen VPS, je la kosto dependi de kunordiga servo.

Elektu la plusendon, kiam la postulo estas stabila envenanta aliro kaj ĉiu regulo devas resti sub via kontrolo. Elektu la provizantan adreson, kiam la buĝeto permesas kaj la celo simple estas ĉesi pripensi ĝin.