Hindi maabot ang home VPN server: sundan ang NAT chain

Sumasagot ang server sa LAN, mukhang tama ang port-forwarding rule, at hindi pa rin makakonekta ang panlabas na kliyente. Mas mabilis ang pagdaan sa isang hangganan kada pagkakataon palabas kaysa sa ika-apat na pag-edit ng rule, dahil may sariling ebidensya ang bawat hangganan: ang WAN page ng router, ang pagsasalin ng provider at ang tagapakinig sa host. Magsimula sa admin page na bukas na at tapusin sa isang pagsubok mula sa network na hindi mo kontrolado. Isulat ang bawat resulta habang tumatakbo, dahil ang pagkakasunod-sunod ang diagnosis at ang naaalalang numero ay hindi ebidensya. Kung outbound tunnel lang ang kailangan mo, hindi mo problema ang pagsasalin: ang hindi hinihiling na papasok na trapiko lang ang hinaharangan.

Magsimula sa WAN page ng router

Mag-log in sa router at basahin ang status page sa halip na ang listahan ng port forwarding. Itala ang WAN address, ang interface kung saan ito kabilang at kung ang uri ng koneksyon ay DHCP, PPPoE o iba pang ibinibigay ng provider. Pagkatapos ihambing ang address na iyon sa iniuulat ng panlabas na serbisyo, gamit ang telepono sa mobile data upang ang obserbasyon ay hindi bumalik sa parehong router. Magkaibang tanong ang sinasagot ng dalawang numero, at ang paghahambing sa kanila ang buong layunin ng hakbang na ito.

Ang WAN address na naiiba sa naobserbahang pampublikong address ay nangangahulugang may hindi bababa sa isang tagasalin sa itaas ng router. Hindi pa ito sira, dahil maraming provider ang nagsasalin ayon sa disenyo at gumagana pa rin ang serbisyo. Kung magtugma ang dalawa, malamang pag-aari ng router ang address at lumipat ang problema sa loob ng iyong network. Sa anumang kaso itala ang pares kasama ang petsa, dahil naglalaan muli ng address ang mga provider at walang halaga ang paghahambing sa mga tala noong nakaraang buwan.

Umakyat ng isang hop

Magpatakbo ng traceroute mula sa router mismo at basahin ang unang mga hop. Paulit-ulit na pampublikong address, unang hop na sumasagot ng pribadong address o address sa loob ng pinagsasaluhang 100.64.0.0/10 saklaw ay tumuturo lahat sa tagasalin sa itaas. RFC 6598 ang naglalarawan sa saklaw na iyon para sa ganitong deployment, kaya ang makita ito sa WAN field ay malakas na senyales at hindi kuryosidad. Dalawang tagasalin sa landas ang nagpapalabo sa bakas, kaya basahin ang pattern at hindi isang linya.

Ang ilang provider ay nagpapakita ng inilaang address sa customer portal lang, kaya tumingin doon bago magpasya na nagsisinungaling ang router. Ang address sa portal na tumutugma sa panlabas na obserbasyon mo habang iba ang iniuulat ng router ang pinakamalinaw na ebidensya ng tagasalin sa itaas. Itago ang dalawang pahina sa change record, dahil ang debate kung kanino ang aling hangganan ay mas mabilis kapag may dalawang larawang may petsa.

Kumpirmahin ang tagapakinig at ang forwarding

Ang pagsubok sa LAN ay nagpapatunay na gumagana ang serbisyo sa lokal at wala itong pinapatunayan tungkol sa maabot mula sa labas. Maraming router ang sumasagot sa sariling forwarding rule mula sa loob, kaya nagtatagumpay ang hairpin test habang sarado pa ang panlabas na landas. Kumpirmahin na nakatali ang daemon sa address at port na inaakala mo, pagkatapos ay subukan mula sa labas. Ang lahat ng nasa ibaba ay para sa pagbabasa lang.

ss -lunp | grep -E '1194|51820'
ip -4 addr show | grep -E 'inet '
curl -s --max-time 5 ifconfig.me
traceroute -n -m 5 1.1.1.1

Kung ipakita ng panlabas na pagsubok na walang packet na dumarating sa router, nangyari ang pagbagsak sa itaas at walang lokal na rule ang makakapag-ayos nito. Kung dumarating ang mga packet at walang sumasagot, ang susunod na hangganan ay ang tagapakinig o ang firewall ng host. Ang paghuli ng packet sa host ang magpapasya kung alin sa dalawa ang tinitingnan mo, at mas kaunting oras ito kaysa sa isa pang ikot ng paghula ng rule. Panatilihing hindi nagbabago ang tagapakinig at ang transport nito habang naghahambing, kung hindi ay ibang tanong ang sasagutin ng susunod na pagsubok.

Baguhin ang topology, hindi ang parehong rule

Kapag pag-aari ng provider ang tagasalin, ang solusyon ay ibang landas at hindi isa pang forwarding. Ang maliit na VPS na may pampublikong address, na ikinabit ng outbound tunnel mula sa bahagi ng bahay, ay naglalagay ng maaabot na dulo sa harap ng serbisyo. Ang pampublikong address na ibinibigay ng provider ay mas simple kung saan ito umiiral at karaniwang mas mura kaysa sa pagpapatakbo ng makina. Inaalis ng IPv6 ang pagsasalin nang lubusan, sa kondisyon na sinusuportahan ito ng client network, mga DNS record at patakaran ng firewall.

Dynamic DNS ay nag-a-update lang ng pangalan; hindi ito lumilikha ng maabot, at ang pagturo nito sa pinagsasaluhang address ay nagpapadala ng mga kliyente sa gateway ng provider na ginagamit din ng ibang subscriber. Ang kabiguan na iyon ay kamukhang-kamukha ng patay na server, kaya mahalaga ang tala mula sa mga naunang hakbang. Itala kung saang address na-resolve ang pangalan noong nabigo ang pagsubok, at itago ang sagot kasama ang resulta ng pagsubok.

Isulat muli ang plano sa paligid ng hangganang kontrolado mo: ang tagapakinig, ang tunnel at ang mga ruta. Panatilihin ang lumang forwarding hangga't naglalarawan pa ito ng totoong bagay, dahil ang rule na hindi na tugma sa topology ay mas masama kaysa sa walang rule. Itala kung aling layer ang talagang humaharang at anong ebidensya ang nagpakita nito. Kung hindi, uulitin ng susunod na magbubukas ng admin page ang bawat hakbang ng paglalakbay na ito mula sa simula.