VPN ng sangay sa 4G: panatilihing matatag ang pagkakakilanlan kapag lumipat ang IP

Magsimula sa sangay mismo, sa WAN status page ng 4G router. Kung ang address na nakikita mo ay nasa pribadong saklaw ng carrier sa halip na pampubliko, walang port forwarding sa kahon na iyon ang kailanman magpapahintulot sa hub na tumawag papasok, at ang tunnel ay kailangang itayo palabas mula sa sangay. Ang nag-iisang obserbasyon na iyon ang nagpapasya sa disenyo. Ang natitirang gawain ay tiyakin na nakikilala ng hub ang sangay sa pamamagitan ng mas mabuti kaysa sa address na nagbabago tuwing ilang oras.

Saan dapat magsimula ang tunnel

Suriin ang address laban sa ibinahaging address space na ginagamit ng mga carrier para sa kanilang sariling NAT, 100.64.0.0/10, at laban sa karaniwang pribadong saklaw. Ang makakita ng isa sa mga iyon sa mobile uplink ay karaniwang nangangahulugan na may NAT sa antas ng carrier sa pagitan ng sangay at ng internet, at ang mga papasok na koneksyon ay hindi available sa anumang presyong kayang bayaran ng sangay. Kapag ang WAN address ay pampubliko ngunit nagbabago, mayroon kang ibang, mas madaling problema.

Ang dynamic na DNS ay tumutulong lamang sa pangalawang kaso. Nagbibigay ito sa nagbabagong pampublikong address ng matatag na pangalan para tawagan, at hindi ito makakagawa ng mapping na hindi kailanman ibinigay ng carrier. Sulit pa ring i-configure ito para sa pampublikong kaso, dahil inaalis nito ang nag-iisang manu-manong hakbang sa muling pagbilang. Ang hindi dapat nitong maging ay ang sagot para sa sangay na hindi kailanman ginawang maabot ng carrier.

Paghiwalayin ang address na tinatawagan mo at ang pagkakakilanlang itinatapat mo

Ang hub ay nangangailangan ng matatag na bagay na matatagpuan, isang aprubadong nakapirming address o isang pinapanatili na hostname. Ang sangay ay nangangailangan ng matatag na paraan upang makilala, at sa IKEv2 iyon ang payload ng pagkakakilanlan na inihaharap nito sa panahon ng authentication, anuman ang source address na dinadala ng mga packet nito. Ang isang string tulad ng @branch-a.vpn.example ay gumagana bilang pagkakakilanlang iyon kahit nagbabago ang mobile address bawat oras.

Ang string na iyon ay itinatapat sa patakaran, hindi niresolba sa pamamagitan ng DNS, kaya huwag asahan ang isang paghahanap sa pag-set up ng tunnel. Ang configuration ng hub ay dapat na tahasang pangalanan ang inaasahang pagkakakilanlan, at sa authentication ng sertipiko ang pagkakakilanlan ay dapat ding tumugma sa aktwal na pinatutunayan ng sertipiko.

Ang pagtanggap ng anumang pagkakakilanlan dahil mukhang kapani-paniwala ang source address ay ang failure mode na dapat iwasan. Sa isang responder nangangahulugan iyon ng pagtanggap ng anumang peer, na may wildcard ng pagkakakilanlan at isang ibinahaging lihim, na nagpapatotoo sa isang string sa halip na isang device.

Isulat ang panig ng hub bilang pinangalanang peer

Sa mga termino ng strongSwan ang panig ng responder ay isang koneksyon na may right=%any, na tumatanggap ng peer mula sa anumang source address, kasama ang [email protected], na nagpi-pin kung ano ang dapat ipahayag ng peer na iyon. Idagdag ang rightsubnet=10.20.0.0/16 para sa mga LAN ng sangay, auto=add upang ma-load ang koneksyon nang hindi tinatawagan, dpd_delay=30s para sa sigla, at mobike=yes upang ang pagbabago ng address ay masipsip sa halip na ituring na bagong peer.

Ipinapahayag ng ibang vendor ang parehong mga bagay sa ilalim ng ibang mga pangalan, karaniwang isang uri ng dynamic o branch-office peer na may field ng pagkakakilanlan at field ng protektadong subnet. Punan ang dalawa; ang generic na dynamic na checkbox ay hindi isang plano sa pagiging tugma.

Panatilihin ang sangay bilang tagapagsimula

Sa sangay nalalapat ang mirror image: left=%defaultroute upang magamit ang lokal na mobile address kung ano ito ngayon, [email protected] upang iharap ang pagkakakilanlan, right=hub.example.com para sa matatag na pangalan ng hub, at auto=start upang umangat ang tunnel nang walang tao. Kapag muling kumonekta ang mobile link, muling nagsisimula ang sangay at itinatapat ng hub ang parehong pagkakakilanlan sa parehong bagay ng patakaran.

Payagan ang IKE sa UDP 500, ang pagdaan ng NAT sa UDP 4500, at ang naka-encapsulate na ESP na sumusunod, sa magkabilang panig. Pagkatapos ay hayaang payagan: ang isang patakarang bumubukas lamang sa oras ng trabaho ay magmumukhang pasulput-sulpot na tunnel.

Subukan ang pagbabago ng address, hindi lamang ang unang pakikipagkamay

Itaas ang tunnel, kumpirmahin ito, pagkatapos ay pilitin ang sangay sa bagong address sa pamamagitan ng pag-toggle ng mobile data o airplane mode sa loob ng isang minuto. Panoorin ang listahan ng mga asosasyon ng seguridad sa hub at tiyakin na nagbago ang address ng peer habang ang pagkakakilanlan ay hindi. Ang isang tunnel na gumagana lamang hanggang sa unang muling pagtatalaga ng carrier ay hindi pa nasubukan.

Pagkatapos suriin ang mga protektadong subnet nang hiwalay. Ang isang itinatag na SA ay nagsasabi na nagpapatotoo ang mga peer; hindi nito sinasabi na may ruta ang hub patungo sa LAN ng sangay o na tinatanggap ng sangay ang trapiko mula sa panig ng hub. Basahin ang routing table at ang patakaran ng firewall nang hiwalay, pagkatapos ay magpadala ng ping mula sa isang host sa halip na mula sa gateway, dahil ang gateway ang pinakamaliit na kumakatawan na device sa anumang network.

Ang matatag na pagkakakilanlan ay ginagawang bagay ng patakaran ang sangay na maaaring pangalanan ng hub. Hindi nito ginagawang maabot ang isang address ng NAT ng carrier, at hindi nito binibigyan ng sarili ang natitirang organisasyon ng access sa sangay.