Bakit hindi kailanman tumatanggap ng koneksyon ang VPN server sa likod ng CGNAT

Iniuulat ng router ang isang WAN address na nagsisimula sa 100.72, nagre-resolve ang dynamic na DNS name sa ibang pampublikong address, at hindi kailanman kinukumpleto ng VPN server sa router na iyon ang handshake mula sa labas. Naka-configure ang port forwarding, tumatakbo ang serbisyo, at gumagana pa rin ang pagsubok mula sa LAN. Wala sa log ng router ang mukhang error. Ang kombinasyong iyon ay carrier-grade NAT, at walang firewall rule ang makakabukas ng port sa address na hawak ng ISP.

Tumitagal ng dalawang minuto ang pagkumpirma sa shared address at pumipigil sa isang linggong pagbabago ng configuration.

Ang mga senyales na tumuturo sa carrier NAT

Ihambing ang WAN address sa status page ng router sa address na iniuulat ng panlabas na paghahanap. Ang WAN address sa loob ng 100.64.0.0/10 ang karaniwang senyales, at ang mga private range na 10/8, 172.16/12 at 192.168/16 ay pareho rin ang ibig sabihin. Kung paulit-ulit na ipinapakita ng traceroute ang parehong pampublikong hop, o may maagang hop na sumasagot gamit ang private address, may isa pang tagasalin sa pagitan ng router at ng internet. Ang ilang ISP ay naglilista ng itinalagang address sa portal ng customer lamang, kaya i-export ang value na iyon kasama ng traceroute.

Walang tulong ang pagpapalit ng protocol o port, dahil ang problema ay ang pag-abot ng papasok na trapiko, hindi ang saradong port.

Bakit hindi ito kayang ayusin ng forwarding at dynamic DNS

Ang port-forward rule ay nagmamapa ng port sa WAN interface ng router, ngunit hindi kailanman umaabot ang papasok na trapiko sa interface na iyon: unang isinasalin ito ng ISP at ipinapasa lamang ang pinapayagan ng sarili nitong table. Ang pag-publish ng shared address sa dynamic DNS ay nagtuturo sa mga client sa isang ISP gateway na ginagamit ng maraming subscriber, kaya nagre-resolve ang pangalan pero nabibigo pa rin ang handshake. Nagtatagumpay ang hairpin test dahil sinasagot ng router ang sarili nitong rule mula sa loob, at may eksaktong parehong blind spot ang UPnP.

Hindi rin makakatulong ang muling pag-configure ng client, dahil nangyayari ang pagkabigo bago basahin ang anumang setting ng client.

I-relay sa pamamagitan ng VPS na may malinaw na ruta

Maglagay ng pampublikong address sa harap sa pamamagitan ng pag-upa ng pinakamaliit na VPS na kayang magdala ng trapiko, pagkatapos ay hayaang tumawag palabas ang router ng bahay patungo roon. Ang palabas na UDP mula sa home network ay dumadaan sa carrier NAT, kaya nabubuo ang tunnel mula sa loob at ang VPS ang nagiging maabot na endpoint. Ang bahagi ng bahay ay nagiging client na may fixed tunnel address, hindi server.

Sa VPS, magdagdag ng client-specific directory entry para malaman ng server kung aling peer ang may-ari ng home subnet, at magdagdag ng tugmang kernel route.

# /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"

Sinasabi ng linyang iroute sa OpenVPN kung aling client ang tumatanggap ng trapiko para sa home subnet; inilalagay ng linyang route ang subnet na iyon sa kernel table ng VPS para makapasok ang mga packet sa tunnel. Para sa published na serbisyo, magdagdag ng destination NAT rule na nagpapasa ng pampublikong port sa 10.8.0.10 at paganahin ang net.ipv4.ip_forward.

Subukan ang landas mula sa labas

I-verify ang bawat hop sa pampublikong bahagi, dahil hindi pinapatunayan ng matagumpay na tunnel na maabot ang serbisyo. Ang listen state at packet capture sa VPS ay naghihiwalay ng 'walang dumating' sa 'dumating at itinapon'.

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

Kung nagpapakita ang capture ng mga packet mula sa telepono pero walang sagot, ang susunod na hintuan ay ang configuration ng server o firewall. Kung walang ipinapakita ang capture, nagre-resolve pa rin ang client o nagpapadala sa maling address.

Mga alternatibong dapat munang tantiyahin ang presyo

Ang dedicated na IPv4 address mula sa ISP ang pinakamaikling solusyon at karaniwang maliit na buwanang bayad. Tinatanggal ng native IPv6 ang pagsasalin sa dalawang dulo kapag sinusuportahan ito ng VPN, client network at DNS records. Ang mesh overlay na may subnet router sa loob ng home network ay nakakamit ng parehong relay nang walang VPS, kapalit ng pagdepende sa isang coordination service.

Piliin ang relay kapag ang pangangailangan ay stable na papasok na access at bawat rule ay dapat manatili sa ilalim ng kontrol mo. Piliin ang ISP address kapag kaya ng budget at ang layunin ay tumigil na lamang sa pag-iisip tungkol dito.