Maaari bang i-host ng roaming VPN client ang isang serbisyo para sa opisina?

Ang laptop ng opisina mo ay makakapag-dial in mula sa bahay at makakapagbigay pa rin ng isang bagay na kailangan ng opisina, ngunit kapag tatlong magkakahiwalay na desisyon ang nagtugma lamang. Ang tunnel ay transportasyon, ang panloob na address ay destinasyon, at ang patakaran ang nagpapasya kung sino ang maaaring kumatok. Kapag itinuring ang alinman sa mga ito bilang buong sagot, lumilitaw ang pamilyar na reklamo: sumasagot ang host sa ping ngunit hindi kailanman kumokonekta ang application. Hindi pareho ang mga tungkulin, at ang pagkakaiba ay nasa eksaktong lugar kung saan naroon ang gawain sa disenyo.

Walang sinasabi ang direksyon ng dial in tungkol sa direksyon ng serbisyo

Kapag nagsimula ang isang client ng tunnel, binubuksan nito ang isang landas na magagamit ng dalawang direksyon kapag umiral na ito. Kung ang isang bagong koneksyon ay maaaring pumasok mula sa hub patungo sa client na iyon ay tanong ng patakaran ng gateway, hindi katangian ng nag-dial in. Halimbawa, sa isang naka-route na hub ng OpenVPN, kailangan ng server ang ruta patungo sa panloob na address ng client at pagpapasa na nagpapahintulot sa ugnayang peer.

Isipin ang isang sistema ng imbentaryo na nagsusuri ng ahente sa mga roaming laptop, o isang developer na nangangailangan ng test API mula sa isang workstation sa bahay. Pareho nilang gusto na ang panig ng opisina ang magsimula ng usapan, na kabaligtaran ng karaniwang pattern na client-to-server.

Nagkakaiba ang mga hosted remote-access na produkto sa puntong ito, at ang pagkakaiba ay hindi bug. Ang ilang managed service VPN ay sadyang hinaharangan ang mga hindi hinihinging koneksyon patungo sa mga nakakonektang client dahil ang modelo nila ay client-to-resource, hindi resource-to-client. Basahin ang dokumentadong arkitektura ng produkto bago mangako sa isang katrabaho na ang kanyang laptop ay maaaring maging server.

Sundin ang landas ng pagbabalik bago magbukas ng port

May tatlong bahagi ang landas: ruta sa gateway na tumuturo sa panloob na address ng client, patakarang nagpapahintulot sa partikular na tumatawag, at serbisyong nakikinig sa target. Iba-iba ang pagpalya ng bawat bahagi, kaya't ang «bukas ang VPN» ay halos walang sinasabi.

Ang mabuting balita ay hindi kailangan ng panloob na landas ang port forwarding sa home router ng client. Iyon ang diwa ng paglalathala ng serbisyo sa address ng tunnel sa halip na sa WAN address ng bahay, kung saan ang pagkakalantad at mga tuntunin ng NAT ay magiging lubos na naiiba. Maaari ring tumanggi ang home router na i-hairpin ang koneksyong nagmumula sa opisina, kaya't pumapalya ang WAN route dahil sa mga dahilang walang kaugnayan sa iyong VPN. Ang pagpapanatili ng trapiko sa loob ng tunnel ay umiiwas sa dalawang problema nang sabay.

Suriin din ang panig ng target. Ang serbisyong nakatali lamang sa 127.0.0.1 ay hindi makakatanggap ng koneksyong dumarating sa interface ng tunnel, gaano man katama ang mga ruta ng gateway. Ang panuntunan ng firewall ng host na nagpapahintulot sa port mula sa lokal na subnet lamang ay magtatapon din ng trapiko ng opisina, at ang panuntunang iyon ay independiyente sa patakaran ng VPN sa itaas nito.

Ang mga pangalan at address ay mga desisyon sa disenyo

Ang address sa loob ng tunnel ay hindi awtomatikong nagiging pangalan. Ang pribadong talaan ng DNS na kontrolado mo ay mas malinaw kaysa sa pag-asang tatawid ang protocol ng pagtuklas sa tunnel, dahil ang resolusyon ng pangalan sa pamamagitan ng link-local multicast ay nananatili sa lokal na segment at hindi nagiging DNS sa pagitan ng mga subnet.

Kasinghalaga rin ang katatagan ng address. Kung kumukuha ang mga VPN client mula sa pool na may maiikling lease, nagbabago ang panloob na address ng laptop sa pagitan ng mga session at bawat bookmark, saklaw ng firewall at pagsusuri ng monitoring na itinayo rito ay tahimik na nasisira. Gumamit ng reserbasyon o dokumentadong landas ng dynamic na pag-update.

Sumang-ayon sa pangalan kasama ng nagmamay-ari ng identidad ng VPN, upang ang talaan, pagtatalaga ng address at patakaran ng access ay magbago nang sabay kaysa sa tatlong hiwalay na ticket.

Subukan ang serbisyo, hindi ang pagiging miyembro

Mula sa target, tiyakin kung ano ang nakikinig at sa aling address, pagkatapos ay tiyakin ang pananaw ng gateway sa landas ng pagbabalik:

$ ss -ltnp | grep 8080
LISTEN 0 128 10.80.0.23:8080 0.0.0.0:*
$ ip -4 addr show tun0 | grep inet
inet 10.80.0.23/24 scope global tun0
$ ip route get 10.80.0.1
10.80.0.1 dev tun0 src 10.80.0.23

Ngayon subukan mula sa panig ng opisina gamit ang tunay na kahilingan sa halip na echo. Ang matagumpay na curl laban sa serbisyo ay nagpapatunay ng ruta, patakaran at nakikinig nang sabay, samantalang ang matagumpay na ping ay nagpapatunay lamang na pinapayagan ang ICMP. Kung mabigo ang kahilingan, bumalik sa tatlong bahagi sa halip na palawakin ang firewall at umasa.

Bahagi ng parehong usapan ang pagkakaroon. Natutulog ang laptop, naglalakbay sa pagitan ng mga network at nadidiskonekta sa katapusan ng araw. Ang serbisyong kailangang sumagot sa anumang oras ay nararapat sa host na laging bukas, samantalang ang best-effort na serbisyo ay maaaring manatili sa client kung nakasulat ang limitasyong iyon.

Ilathala ang resource nang sadyain, kasama ang pangalan, listahan ng pinapayagang tumatawag at may-ari, at ang remote device ay nagiging suportadong serbisyo sa halip na aksidenteng server.