Dobleng NAT at ang Iyong VPN: Gumagana ang Kliyente, Hindi ang Server

Nasa likod ng isa pang router ang iyong router, pribado ang WAN address, at kumokonekta pa rin ang VPN client. Nakakagulat ang kombinasyong iyon sa mga umaasang masisira ng dobleng NAT ang mga tunnel, ngunit ang papalabas na koneksyon ang pinakahusay na hinahawakan ng pagsasalin. Ang mag-host ng VPN server sa likod ng parehong dalawang suson ang kadalasang nabibigo. Iguhit ang direksyon ng koneksyon bago ka magbago ng anuman.

Iguhit muna ang direksyon ng koneksyon

Buksan ang status page ng panloob na router at isulat ang WAN address nito, pagkatapos ay ihambing ito sa address na iniuulat sa iyo ng isang pampublikong serbisyo. Kung magkaiba ang dalawa, may hindi bababa sa isang tagasalin sa pagitan ng iyong router at ng internet. Kung ang WAN address ay nasa loob ng 100.64.0.0/10, malamang ay pag-aari ng iyong provider ang panlabas na tagasalin, at hindi mo ito kontrolado. Ang dalawang katotohanang ito ang nagtatakda kung alin sa mga susunod na hakbang ang talagang maaaring gumana.

curl -s https://ifconfig.me
ip -brief address
traceroute -n 1.1.1.1

Ang dobleng NAT ay hindi dobleng VPN. Isinusulat muli ng pagsasalin ang mga address at port; hindi ito nagdadagdag ng pangalawang naka-encrypt na tunnel, at wala itong ini-encrypt. Mahalagang paghiwalayin ang dalawang ideya dahil lubos na magkaiba ang mga solusyon, at ang isa sa kanila ay nangangailangan ng usapan sa iyong provider kaysa sa isang page ng setting.

Papalabas: nagtatanong ang kliyente, nagmamapa ang mga tagasalin

Nagsisimula ang papalabas na tunnel sa isang packet mula sa iyong makina, kaya makakagawa ang bawat tagasalin ng mapping at maipapasok muli ang tugon. Ang protocol, port at idle timer ang nagtatakda kung mabubuhay ang mapping na iyon nang sapat upang maging kapaki-pakinabang. Halos lahat ng consumer router ay hinahawakan ito nang walang anumang configuration.

Ang mga pagpalya na talagang lumilitaw ay karaniwang tungkol sa timeout at suporta sa protocol, hindi sa bilang ng router. Ang tunnel na bumabagsak pagkatapos ng ilang minutong katahimikan ay isang mapping na nag-expire, at ang keepalive ang karaniwang sagot. May mga standard na NAT-traversal extension ang IPsec, kaya ang pagsasabing hindi ito makakatawid sa pagsasalin ay mali lang. Kung hindi talaga nabuo ang tunnel, tingnan ang endpoint at ang mga credential bago sisihin ang topology.

wg show
ping -c3 10.8.0.1

Huminto kung gumagana ang papalabas na tunnel mula sa isang network at hindi mula sa iba. Tungkol sa mga network ang paghahambing na iyon, hindi sa bilang ng router.

Papasok: ang forwarding ay sumasaklaw lamang sa kagamitang pag-aari mo

Ang pagho-host ng server ay ang kabaligtaran: dumarating ang bagong koneksyon mula sa internet at kailangang makarating sa iyong makina sa bawat suson. Ang port-forwarding rule sa panloob na router ay nakakatulong lamang kung ihahatid din sa iyo ng panlabas na tagasalin ang trapikong iyon. Ang pag-uulit ng lokal na rule ay hindi nagbibigay ng kontrol sa kagamitan ng provider.

nc -vz 203.0.113.10 51820
ss -lunp 'sport = :51820'

Ihambing ang WAN address ng panloob na router sa pampublikong address na naobserbahan mo, at itala kung saan nanggaling ang bawat halaga. Kung pribado ang WAN address o nasa shared range, nagsasagawa ang panlabas na suson ng pagsasaling hindi mo makokontrol. Tanungin ang provider kung anong inbound reachability ang sinusuportahan bago ka magpalipas ng isang gabi sa mga rule na hindi maaaring magkabisa. Ang pagtanggal ng router o malawakang pagpatay ng firewall ay hindi diagnosis, at ito ay masamang palitan para sa isang bukas na port.

Huminto kung pag-aari ng provider ang panlabas na suson at hindi ito nagpapasa. Kung gayon, ang mga sinusuportahang sagot ay ibang paraan ng pag-access o isang relay, hindi isa pang rule sa iyong panig.

Subukan ang isang variable sa isang pagkakataon

Magbago ng isang bagay bawat pagsubok at itala ang resulta, dahil mas maraming variable ang landas na may dobleng NAT kaysa sa landas na may isang router. Panatilihing nakatakda ang profile at device, pagkatapos ay ihambing ang ibang network ng pag-access. Pansinin kung nabibigo ang negosasyon, kung bumabagsak ang session pagkatapos ng idle, o kung ang mga pribadong destinasyon lamang ang nabibigo. Ang tatlong obserbasyong iyon ay tumuturo sa tatlong magkaibang suson.

journalctl -u wg-quick@wg0 -n 30 --no-pager
ip route get 10.20.30.40

Ang magkakapatong na pribadong subnet ay hiwalay na bitag na hindi kayang ayusin ng anumang dami ng pagsasalin. Kung ang iyong home network at ang remote network ay gumagamit ng parehong range, lilitaw ang salungatan ng ruta kahit gaano karaming tagasalin ang nasa gitna. Ang muling pagbilang sa isang panig ang tanging matibay na sagot.

Karapat-dapat din sa parehong atensyon ang remote gateway, dahil ang mga forwarding rule at return route nito ay maaaring ang nawawalang piraso. Ang tunnel na pumasa sa authentication ay maaari pa ring walang magamit na application path, at ang pagpalyang iyon ay magkapareho ang hitsura mula sa panig ng kliyente. Nagtatapos ang paglalakbay kapag masasabi mo kung aling direksyon ang nabibigo at aling suson ang may-ari nito.