LAN sa likod ng isang session ng AWS Client VPN: ano ang ipinapasa

Kumokonekta ang laptop sa endpoint ng AWS Client VPN, nakakarating sa pribadong subnet, at mukhang malusog ang lahat. Ang desktop sa parehong LAN ay hindi nakakarating sa anuman, kahit may interface ng tulay din ang host na Linux at pareho ang mga makina sa isang kable. Walang mali sa pagkaka-configure sa tunnel; ang kulang na piraso ay ang routing, at ang tulay ay isang maling bakas.

Ang pagpapalawak ng session ng Client VPN sa isang LAN ay isang tungkulin ng gateway. Hindi ito isang segment ng Ethernet na hinila sa isang pinamamahalaang serbisyo.

Gumagana ang host at hindi ang LAN

Ang interface ng tunnel sa makina ng Linux ay may address sa loob ng CIDR ng kliyente ng Client VPN, at nagtulak ang endpoint ng mga ruta para sa mga saklaw ng VPC. Ang kahilingang ginawa sa makinang iyon ay trapikong nalikha nang lokal: pumipili ito ng ruta, lumalabas sa tunnel at nakakakuha ng tugon. Ang daang iyon ay hindi kailanman humahawak sa code ng pagpapasa, sa interface ng LAN o sa anumang tuntunin ng firewall na namamahala sa transit.

Ang trapiko mula sa ibang aparato sa LAN ay ibang daloy. Dumarating ito sa interface ng LAN, kailangan ng rutang tumuturo sa tunnel, kailangan ng bukas na pagpapasa, kailangan ng firewall na pumapayag dito, at kailangan na bumalik ang tugon sa parehong host. Apat na kundisyon, at wala sa kanila ang pinatutunayan ng gumaganang pagsubok sa laptop. Mula sa desktop kakaiba ang hitsura ng kabiguan: bukas ang tunnel, wasto ang mga kredensyal, at hindi kailanman sumasagot ang patutunguhan. Lokal ang depekto sa daan ng pagpapasa ng gateway, hindi sa serbisyo.

Hindi lahat ng kliyente ay maaaring maging gateway

Sinasabi ng AWS na hindi sinusuportahan ng desktop app ng Client VPN ang pagpapasa ng IP, at maaaring suportahan ito ng ibang kliyente. Ang paghihigpit na iyon ang nagpapasya sa arkitektura bago pa may mai-type na utos. Kung ang tanging available na kliyente ay ang opisyal na desktop app, ang gateway na Linux na nagpapasa para sa LAN ay hindi isang configuration na matatapos mo, at walang dami ng masquerading ang makakapagbago nito.

Dapat ding tumugma ang kapalit na kliyente sa paraan ng pagpapatotoo ng endpoint at sa patakarang nais mong ipatupad. Ang mga endpoint na nakabatay sa sertipiko, direktoryo at SAML ay hindi tumatanggap ng parehong configuration ng kliyente, at ang kliyente ng ikatlong partido na nagpapatotoo ngunit binabalewala ang mga itinulak na ruta ay hindi pagpapabuti.

Ituring ang pagpili ng kliyente bilang bahagi ng pagsusuri ng disenyo. Tinutukoy nito kung ang pattern ng pagpapasa sa LAN ay available, at tinutukoy kung anong pagkakakilanlan ang nakikita ng endpoint para sa bawat aparato sa likod ng gateway. Itala ang kliyente at ang configuration ng endpoint na ginamit sa pagsubok. Ang pagpapalit ng kliyente makalipas ang anim na buwan ay maaaring tahimik na mag-alis ng kakayahang inaasahan ng disenyo.

Ituro ang LAN sa tunnel at isalin ito

Kapag may suportadong kliyente, ang natitira ay ordinaryong gawain ng gateway. Kailangan ng mga aparato sa LAN ng ruta para sa saklaw ng VPC na tumuturo sa host na Linux, at kailangan ng host ng bukas na pagpapasa. Kung nais mong makita ng VPC ang trapiko bilang ang konektadong kliyente at hindi bilang arbitraryong address ng LAN, isalin ang pinagmulan sa paglabas.

LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16

iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADE

Limitahan ang tuntunin sa interface ng tunnel at sa saklaw ng VPC, tulad ng nasa itaas, sa halip na mag-masquerade ng lahat ng ipinapasa ng host. Ang mas makitid na tuntunin ay mas madaling isipin, at hindi nito tahimik na binabago ang trapikong dapat magpanatili ng orihinal na address ng pinagmulan.

Hayaang dumating nang awtomatiko ang ruta ng LAN kung kaya mo: isang opsyon ng DHCP, anunsyo ng router o static na rutang itinutulak ng namamahala sa LAN. Ang rutang umiiral lamang sa isang test machine ay magpapakita ng sirang disenyo sa sandaling subukan ito ng ibang tao.

Ang tugon ay nangangailangan din ng daan

Kapag naabot ng kahilingan ang VPC, dapat bumalik ang tugon sa parehong mga estado ng pagsasalin at hanapin ang ruta ng LAN sa gateway. Karaniwang gumagana ang bahaging iyon kapag naroon ang tuntunin ng masquerade, dahil nabubuhay ang pagmamapa sa host na gumawa nito. Nababali ito kapag may ruta sa panig ng VPC na nagpapadala ng tugon sa ibang lugar, at iyon ang dahilan kung bakit mahalaga kapwa ang ruta ng CIDR ng kliyente at ang pagkakaugnay ng subnet sa endpoint.

Tingnan ang mga counter, hindi lang ang ping. Ang tuntunin ng masquerade na walang packet ay nagsasabing hindi kailanman naabot ng kahilingan ang interface ng tunnel, na tumuturo pabalik sa ruta ng LAN o sa sariling routing table ng kliyente. Ang tuntuning may packet ngunit walang tugon ay tumuturo sa panig ng VPC, sa mga tuntunin ng awtorisasyon o sa security group na hindi tumatanggap ng isinaling pinagmulan. Basahin ang dalawang direksyon bago magbago ng anuman, dahil ang bilang na lumalaki sa isang panig lamang ay daang isang direksyon, hindi mabagal.

Tandaan na ang endpoint ay isang pinamamahalaang serbisyo. Walang file ng configuration ng server na i-edit at walang direktibang client-config na idadagdag, kaya ang mga tagubiling isinulat para sa self-managed na OpenVPN server na may custom na ruta ng subnet ng kliyente ay hindi naglilipat. Sa AWS ang mga lever ay ang pagkakaugnay ng subnet, mga tuntunin ng awtorisasyon at mga routing table ng VPC.

Ang pinagsasabing pagkakakilanlan ang bahaging dapat sagutin ng patakaran

Ginagamit ng bawat aparato sa likod ng gateway ang session ng VPN ng gateway. Ang mga tuntunin ng awtorisasyon ng endpoint ay nagbibigay ng access sa isang user o grupo, at mula sa pananaw ng serbisyo may eksaktong isang user sa session na iyon. Ang lokal na pagpapasa ay hindi nagpaparami ng pagkakakilanlang iyon tungo sa pagpapatotoo bawat aparato, at hindi nito pinalalawak ang mga pagsusuri ng postura ng aparato hanggang sa printer sa sulok.

Maaaring katanggap-tanggap iyon, o maaaring iyon ang dahilan kung bakit tinatanggihan ang disenyo. Depende ito sa kung ano ang ipinapalagay ng mga resource ng VPC tungkol sa kung sino ang tumatawag. Ang pinagsasabing pagkakakilanlan na umaayon sa modelo ng awtorisasyon ay maayos; ang isa na tahimik na nagpapalit ng isang awtentikadong session tungo sa access sa buong LAN ay isang natuklasang naghihintay na maisulat.

Kung ang pangangailangan ay talagang ikonekta ang buong site sa isang VPC, ihambing ang suportadong disenyong site-to-site bago palawakin ang kliyente ng remote access. Iba ang semantika, at ang session ng kliyente na may NAT ay mahinang kapalit ng link ng site kapag kailangan ng VPC na magsimula ng mga koneksyon papasok sa LAN.

Magpasya sa kliyente, ruta, pagsasalin at kuwento ng pagkakakilanlan sa ganoong pagkakasunod-sunod. Bawat isa ay naglilimita sa susunod, at ipinapaliwanag ng pagkakasunod-sunod kung bakit gumagana ang host habang hindi ang LAN.