Magdagdag ng VPN ng site sa tabi ng router ng ISP nang hindi pinuputol ang mga tawag

Karamihan ng maliliit na site ay mayroon nang isang kahon na gumagawa ng internet, DHCP at voice line, at ang kahon na iyon ay hindi magpapatakbo ng tunnel ng site mo. Gumagana ang pagdaragdag ng pangalawang gateway para sa pribadong landas kung magpapasya ka kung kanino ang bawat ruta bago humawak ng cable. Ang tunay na panganib ay hindi ang tunnel; ito ay ang tahimik na pagpapalit ng device na nagpapanatili ng mga teleponong nakarehistro. Gawin ang limang pagsusuri nang sunod-sunod at huminto kung saan nabigo ang isa.

Isulat ang mga tungkuling gumagana na

Itala ang default na gateway, ang DHCP server, ang resolver at ang device na may rehistro ng boses ng provider. Sa halimbawang ito ang router ng ISP ay 10.50.0.1, ang bagong gateway ay 10.50.0.2 at ang malayong site ay 10.60.0.0/24. Wala sa planong iyon ang nagbabago sa unang tatlong tungkulin, at iyon mismo ang punto. Pagkatapos tiyakin na ang pangalawang kahon ay talagang makakapagtapos ng tunnel: tingnan ang protocol, ang inaasahang throughput at kung nakakatanggap ito ng firmware o package update. Ang device na may logo ng VPN at walang daan sa pag-update ay pasanin, hindi dagdag.

Kung hindi mo masabi kung kanino ang serbisyo ng boses, huminto. Ang pagpapalit ng router na may rehistro nang walang planong pagbabalik ay ginagawang pagkawala ng telepono ang proyektong VPN.

Bigyan ang bagong gateway ng isang address at isang gawain

Ireserba ang LAN address nito sa labas ng DHCP pool para hindi ito gumalaw pagkatapos ng reboot, at huwag bigyan ito ng sariling default na ruta maliban kung gusto mong maging daan ito ng internet. Ang gawain nito ay hawakan ang tunnel at sumagot para sa malalayong prefix. Sa mga host ng LAN na kailangang makarating sa malayong site, patunayan kung aling ruta ang tinatahak nila ngayon at alin ang gusto mo pagkatapos ng pagbabago; ang parehong dalawang utos bago at pagkatapos ang pinakamurang ebidensya.

ip route get 10.60.0.55
ip neigh show 10.50.0.2
traceroute -n 10.60.0.55

Kung ang paghahanap ay nagbabalik ng router ng ISP at namatay ang traceroute sa gilid ng internet, wala pang malayong ruta ang host, na inaasahan. Kung may hindi inaasahang bumalik, ayusin iyon muna, dahil ang bawat susunod na hakbang ay ipinapalagay ang baseng ito.

Piliin kung kanino ang ruta ng malayong prefix

Ang opsyon A ay ang router ng ISP: may hawak itong static na ruta para sa 10.60.0.0/24 patungo sa gateway, at ang bawat host ay sumusunod sa default na gateway nito gaya ng dati. Ang opsyon B ay kada host: tanging ang mga makinang nangangailangan ng malayong site ang tumatanggap ng malinaw na ruta sa 10.50.0.2, at ang lahat ng iba ay nananatiling hindi nagalaw. Ang A ay mas malinis sa maraming host, ngunit karaniwang nangangailangan na tanggapin ng router ng provider ang static na ruta, na hindi ginagawa ng ilan. Ang B ay hindi nangangailangan ng pakikipagtulungan ng provider ngunit iniiwan sa iyo ang pagpapanatili ng configuration ng mga host, kaya bagay ito sa maliit na apron na hanay ng makina.

Sa parehong kaso dapat mayroong direksyon ng pagbabalik. Kung ang malayong sagot ay dumating sa gateway at direktang ipinasa ng gateway sa isang host ng LAN, nilalampasan ng trapiko ang kalagayan ng firewall na hinawakan ng router ng ISP sa daan palabas. Kapag ang gateway ay hindi ang default na router ng LAN, ang asimetriyang iyon ay desisyon sa disenyo, hindi depektong maaaring balewalain.

ip route add 10.60.0.0/24 via 10.50.0.2 dev eth0
ip route get 10.60.0.55 from 10.50.0.77

Gawing permanente ang entry sa pamamagitan ng may-ari ng configuration ng host, hindi ng login script. Ang rutang umiiral lamang pagkatapos may mag-login ay mabibigo sa unang pagkakataon na mag-reboot ang makina dahil sa walang kaugnayang dahilan.

Maghanda ng maabot na inbound endpoint

Kailangan ng gateway ng address na maabot ng malayong site. Sa likod ng router ng ISP, nangangahulugan iyon ng port forwarding o entry sa DMZ, at pareho itong nakasalalay sa provider na talagang naghahatid ng trapiko. Ang lokal na forwarding ay hindi makakalampas sa carrier-grade NAT sa panig ng provider. Kung walang maabot na punto ang provider, baliktarin ang direksyon: hayaang magsimula ang dalawang site patungo sa hub na kontrolado mo. Iyon ay wastong disenyo, ngunit nagdadagdag ito ng pangatlong dependensya para sa forwarding, tiwala at availability, at hindi iyon pinapalitan ng dynamic na DNS.

Tiyakin ang forwarding sa pamamagitan ng capture sa gateway, hindi ng website na nag-scan ng port. Sinasabi ng mga scanner na sarado ang port hanggang mabuhol ang listener, at ang forwarding na hindi kailanman naghahatid ng trapiko ay mukhang saradong port mula sa labas.

Tanggapin ang pribadong serbisyo at ang voice line nang sabay

Subukan ang inaasahang operasyon mula sa isang host ng LAN, gamit ang pribadong DNS at sariling kredensyal ng application. Ang rutang tunnel ay hindi ginagawang parang lokal na segment ng Ethernet ang malayong pag-browse, kaya kailangan ng sariling kaayusan ang pagtuklas at pagresolba ng pangalan.

curl -sS -o /dev/null -w '%{http_code}\n' https://files.example.net
ping -c 3 10.60.0.55

Pagkatapos tiyakin na gumagana pa rin ang karaniwang access sa internet mula sa parehong host at nakarehistro pa rin ang mga telepono; nahuhuli ng dalawang pagsusuring iyon ang aksidenteng pagbabago ng default na ruta, ang pinakakaraniwang paraan na sinisira ng proyektong ito ang isang bagay na hindi nito gustong galawin. Tapusin sa isang nakasulat na tala ng pagbangon: aling device ang may aling tungkulin, ang mga nakareserbang address, at paano aalisin ang ruta ng malayong prefix sa isang hakbang. Ang pribadong landas na malinis na maaaring bawiin ay mas mahalaga kaysa sa gumagana lamang ngayon.