Home VPN server kumpara sa cloud server: alin ang nakakaabot sa NAS mo?

Bumangon ang tunnel, nagpapakita ang client ng berdeng tuldok, at ssh 192.168.1.20 nakabitin pa rin hanggang maubos ang oras. Naranasan ko mismo ito matapos umupa ng maliit na cloud instance at maglagay ng WireGuard doon: maayos ang handshake, maayos ang DNS, at ang NAS sa aking mesa ay kasing hirap abutin na parang nasa buwan. Wala namang mali sa tunnel. Ang endpoint ay nakalagay sa isang network na walang ruta patungo sa bahay ko. Ang lokasyon ng endpoint ang nagtatakda kung aling mga network ang kalapit, kaya piliin ito ayon sa resource na una mong kailangang abutin at ihambing ang hosting pagkatapos.

Ang tunnel ay nakakaabot lamang sa mga network na kayang i-route ng endpoint

Binibigyan ng VPN ang client mo ng address sa loob ng sariling routing domain ng endpoint. Kapag nagpadala ang client ng packet sa 192.168.1.20, kailangang malaman ng endpoint kung saan ito pupunta. Alam ng talahanayan ng cloud VM ang mga subnet ng VPC ng provider; tungkol sa LAN mo ay wala itong narinig. Ang konektado at maabot ay dalawang magkaibang katotohanan, at karamihan ng kalituhan sa bahay kumpara sa cloud ay nagmumula sa pagkuha sa una bilang patunay ng pangalawa.

Isang utos ang nagtatakda. Sa endpoint, ip route get 192.168.1.20 alinman ay pinapangalanan ang isang LAN interface o itinuturo ang default na ruta. Sa makina sa bahay ang sagot ay ang panig ng LAN. Sa cloud instance lumalabas ang packet patungo sa internet at namamatay. Ang pag-on ng net.ipv4.ip_forward=1 at pagdagdag ng MASQUERADE rule ay hindi nagbabago nito, dahil walang mapagpapadalhan hanggang may isang bagay sa panig ng bahay na magtapos ng link papunta sa cloud.

Ang kaso sa bahay ay may ikalawang kalahati: ang daan pabalik. Ang mga packet na lumalabas sa LAN sa pamamagitan ng tunnel box ay dumadaan sa NAT, o kailangan ng LAN ng static na ruta pabalik sa subnet ng tunnel. Kapag isang direksyon lang ang gumagana, tingnan ang sysctl net.ipv4.conf.all.rp_filter. Ang mahigpit na reverse-path filtering ay nagtatapon ng mga sagot na dumarating sa ibang interface kaysa sa hinuhulaan ng ruta, at ang sintomas ay mukhang eksaktong firewall rule.

Basahin ang sintomas bago hawakan ang configuration

Hindi nabubuo ang tunnel: mga key, address ng endpoint o naka-block na UDP port. Nakabangon ang tunnel pero patay ang mga host sa LAN: placement at routing. Nakabangon ang tunnel pero patay ang browsing: forwarding, NAT o DNS. Tatlong layer iyon at tatlong magkaibang pagsusuri, at ang muling pagsulat ng configuration na tama na ay sayang na gabi.

Ang papasok na maabot mula sa bahay ay karapat-dapat sa sariling pagsusuri, dahil ito ang nagtatakda kung posible ang hosting sa bahay. Ihambing ang WAN address na iniuulat ng router mo sa address na nakikita ng panlabas na host. Kung nahuhulog ito sa 100.64.0.0/10, o hindi tugma ang dalawa, nasa likod ka ng carrier-grade NAT at walang port forwarding ang gagana kailanman. Ang tunay na opsyon ay relay, cloud link na tumatawag palabas mula sa bahay, o ilipat ang endpoint.

Ano ang binibili ng hosting sa bahay, at ano ang halaga

Ang bahay ang tanging placement na nasa loob ng LAN bilang default, at iyon ang buong dahilan para maglagay ng server doon. Gumagana nang walang karagdagang routing ang mga device na sumasagot lamang sa lokal na segment, gaya ng mga printer at admin page ng NAS na tumatanggi sa di-lokal na subnet. Ikaw din ang nagpapatakbo ng makina, router at uplink.

Ang mga gastos ay pisikal. Ang upload sa bahay ang kisame para sa lahat ng client nang sabay, kaya nag-aagawan ang video call at backup sa iisang tubo. Kuryente, pagkasira ng disk, patch, dynamic na address na kailangan ng DDNS, router na dapat mag-forward ng UDP papasok, at posibleng double NAT ay lahat bumabagsak sa iyo. Ang madalas laktawan ay recovery: kung mamatay ang box habang wala ka, mamamatay rin ang tanging daan mo papasok sa bahay. Magtabi ng pangalawang device na may parehong key, o at least isang plan para sa pisikal na access.

Kung gusto mo ng LAN access nang walang box sa bahay, magtayo ng link kaysa magpanggap. Ang cloud endpoint ay nagiging router: isang tunnel mula sa panig ng bahay na may AllowedIPs = 192.168.1.0/24 sa cloud peer, kasama ang forwarding at NAT sa cloud box. Ang forwarding guide ng strongSwan ay dumadaan sa kalahating pabalik ng setup na iyon, at doon nabibigo ang karamihan ng mga pagtatangkang ito. Kailangan nang buhay ang home peer para gumana ang kahit ano, kaya pinalitan mo ang isang dependency ng iba at dapat mong isulat iyon.

Para saan talaga ang cloud endpoint

Binabago ng cloud endpoint ang pampublikong labasan mo. Lumalabas ang traffic mula sa address range ng provider, at nakikita ng mga site ang address na iyon kaysa sa address mo sa bahay. Iyon ang halaga, at iyon din ang dahilan kung bakit hindi ibinibigay ng cloud VPN ang NAS: inilipat mo ang labasan, hindi ang LAN.

Pinapatakbo mo pa rin ang guest system, ang VPN service at ang mga credential nito habang ang provider ang nagpapatakbo ng hypervisor at pisikal na network, at mahalaga ang paghahati kapag may nasira sa 2 madaling-araw. Ang pampublikong endpoint ay patuloy na ini-scan, kaya isara ang management port, payagan lamang ang VPN port, at mag-patch ayon sa iskedyul. Dapat pahintulutan ng security group at firewall ng provider ang port na iyon, at may mga cloud na nagtatapon ng forwarded traffic maliban kung aayusin mo ang source at destination check sa instance.

Ang maliit na instance ay sumasaklaw sa ilang client, pero trabaho ng CPU ang encryption, at ang burstable instance na naubos ang credit ay hindi pantay ang kilos sa tuloy-tuloy na load. Tingnan ang rutang talagang ginagamit mo, hindi ang spec sheet.

Desisyong maisusulat mo

Ang gawain ang nagtatakda ng placement, hindi ang label sa box. Kung kailangan mo ng device sa LAN mo sa bahay, ang pinakamurang tamang sagot ay endpoint sa bahay; gagana lang ang cloud box pagkatapos mong itayo ang pabalik na link. Kung kailangan mo ng ibang pampublikong labasan, cloud ang sagot at hindi lumilitaw ang tanong tungkol sa LAN. Nais ang pareho ay lehitimo, pero nangangahulugan ito ng dalawang endpoint, dalawang set ng key at dalawang dokumentadong ruta.

I-verify mula sa client sa pagkakasunod: handshake, peer address, isang host sa LAN, pagkatapos ang exit IP. curl -s https://ifconfig.me ipinapakita ang nakikita ng internet, at ip route get 192.168.1.20 ipinapakita ang pinaniniwalaan ng endpoint. Kapag pumasa ang exit check at nakabitin ang NAS check, may sagot ka na tungkol sa placement; ang pagsasaayos ng AllowedIPs sa client ay hindi gagawa ng ruta. Ang hatirang linya gaya ng 10.8.0.0/24, 192.168.1.0/24 ay nagtatago ng LAN traffic sa loob ng tunnel kapag talagang umiiral ang rutang iyon.