Bakit hindi maabot ang mga kliyente ng Access Server mula sa LAN

Kumokonekta ang laptop, aktibo ang tunnel, at nag-hang ang mga kahilingan sa isang panloob na serbisyo habang kumokonekta. Sa serbisyo mismo dumarating ang kahilingan mula sa isang address na tulad ng 10.90.0.25, lumalabas ang sagot patungo sa default na gateway, at walang bumabalik, dahil walang ideya ang gateway na iyon kung nasaan ang 10.90.0.25. Mula sa kabilang dulo, ang parehong sira ay mukhang panloob na host na hindi kayang mag-ping sa isang konektadong kliyente. Pareho silang isang nawawalang bagay: rutang pabalik sa pool ng mga kliyente ng VPN, na tanging pribadong network lang ang makakadagdag.

Basahin ang source address na nakikita ng serbisyo

Ang nag-iisang field na iyon ang nagpapasya sa lahat ng iba pa. Kung nakikita ng panloob na serbisyo ang address ng pool, nagre-ruta ang Access Server sa halip na itago ang trapiko ng mga kliyente, at bawat sagot ay dapat i-ruta pabalik sa pool. Kung sa halip ay nakikita nito ang sariling pribadong address ng server, nagma-masquerade ang server at gumagana na ang rutang pabalik, kapalit ng pagkawala ng anumang pagkakakilanlan ng bawat kliyente sa mga log at patakaran sa pag-access ng serbisyo.

Ihambing ang magkabilang dulo bago magbago ng kahit ano. Sa server, ilista ang mga interface ng tunnel at ang kanilang mga address; sa kliyente, tiyakin kung alin sa mga address na iyon ang tunay na hawak nito; sa panloob na host, tingnan ang aktibong koneksyon.

ip -br addr show
ss -tnp state established '( dport = :443 )'
ip route get 10.90.0.25

Ang huling utos ang nabibigo kapag sira ang kalagayan: sinasabi nitong hindi maabot ang prefix ng tunnel o, mas masahol pa, ibinabalik ang iyong default na gateway, at ganoon napupunta ang mga sagot sa internet.

Huwag ipalagay na isang pool lang. Ang isang server ay maaaring may dynamic na saklaw at mga static na mapping sa bawat gumagamit, at ang static na address ay maaaring nasa labas mismo ng dynamic na prefix. Kung ang ruta mo lang ay ang saklaw na natatandaan mo, nananatiling sira ang mga gumagamit na may nakapirming address at iniuulat ng lahat ng iba na lutas na ang problema.

Idagdag ang ruta sa lugar kung saan pinagpapasyahan ang sagot

Ang ruta ay pag-aari ng gateway na ginagamit na ng panloob na serbisyo, hindi ng serbisyo, maliban kung nagre-ruta ito ng sarili nitong trapiko. Ituro ito sa maaabot na pribadong address ng Access Server, na ibang halaga kaysa sa address ng tunnel na hawak ng kliyente.

ip route add 10.90.0.0/24 via 10.0.1.5
ip route get 10.90.0.25

Sa isang cloud network ang parehong pahayag ay nagiging entry sa routing table na ang target ay ang instance o interface ng network kung saan tumatakbo ang server, na naka-disable ang pagsusuri ng pinagmulan at destinasyon sa interface na iyon. Pansinin ang hindi ginagawa ng entry na iyon: ang ruta ay hindi pagbibigay ng access, kaya kailangan pa ring payagan ng security groups, network ACL at firewall ng host ang trapiko.

Gawin itong permanente at panatilihing tapat ang laki ng mga pool. Dalawang pool na hindi magkadikit ay nangangailangan ng dalawang ruta, at ang pool na lumalaki nang higit sa na-configure na prefix nito ay tahimik na gumagawa ng mga kliyenteng walang mapupuntahan ang mga sagot. Kung kontrolado mo ang mga saklaw ng pool, pumili ng buod na maaari mong i-ruta nang isang beses at iwanan.

Dapat magkatugma ang forwarding at filter sa ruta

Ang pag-ruta ay kalahati lamang ng daan. Kailangang payagan ang server na mag-forward sa pagitan ng tunnel at ng pribadong interface, na sa Linux ay nangangahulugang net.ipv4.ip_forward at isang forward chain na nagpapahintulot sa pares ng interface, at sa hardened na host ay karaniwang tahasang tuntunin sa bawat direksyon.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A5 forward

Ipinapaliwanag ng stateful filtering ang sintomas na nagdadala sa mga tao sa maling daan. Ang sagot sa loob ng established na flow ay hindi kailangan ng bagong inbound rule, kaya ang koneksyong nag-hang pagkatapos ng SYN-ACK ay hindi hinaharangan ng kulang na accept rule; ito ay ibinabagsak o mali ang ruta. Panatilihin ang pagkakaibang iyon, dahil hinihiwalay nito ang pagbabago sa ruta sa pagbabago sa firewall.

Ang asymmetric na rutang pabalik ay ang mas tahimik na bersyon ng parehong problema. Kung dalawang ruta ang umabot sa pool at ang sagot ay kumuha ng lumalabas sa ibang interface kaysa sa pinasok ng kahilingan, itinatapon ito ng mahigpit na reverse-path filtering at nabibigo ang flow para sa ilang kliyente lang.

Naka-ruta o naka-maskara: pumili nang sinasadya

Pinapanatili ng routed mode ang pool address ng kliyente sa serbisyo, na nagpapahintulot ng logging at patakaran sa bawat kliyente, at kapalit nito ay kailangan ng bawat panloob na network na sasagot sa isang kliyente ang ruta ng pool. Tinatanggal ng masqueraded mode ang pangangailangang iyon dahil bumabalik ang mga sagot sa server, ngunit hindi na matukoy ng serbisyo ang isang kliyente mula sa iba at hindi na makapagsimula ng anuman patungo sa isang partikular na kliyente.

Ang pagbabago ng pag-uugaling iyon sa isang gumaganang server ay pumuputol ng mga umiiral na session, kaya subukan muna sa isang kliyente at isang flow. Kung ang pagbabago ang tamang sagot, ito ay desisyon sa configuration sa server, hindi isang bagay na iniiwasan sa pamamagitan ng pagdagdag ng mga rutang magiging hindi kailangan.

Ang subnet sa likod ng kliyente ay hiwalay na gawain

Maabot ang isang device sa sariling LAN ng laptop ay hindi pareho ng pag-abot sa tunnel address ng laptop. Kailangan nitong kumilos ang kliyente bilang gateway ng subnet: isang idineklarang network sa panig ng kliyente, naka-enable ang forwarding sa operating system ng kliyente, at isang ruta sa LAN na iyon pabalik sa kliyente. Ang pagdagdag ng ruta ng pribadong network para sa saklaw sa bahay ng laptop ay hindi ito ginagawa, at lumilikha ito ng mga salungatan kapag dalawang gumagamit ang may parehong saklaw sa bahay.

Ang direksyon ay isyu rin ng patakaran. Ang pahintulot sa isang kliyente na magbukas ng koneksyon sa isang panloob na serbisyo ay hindi awtomatikong nagpapahintulot sa isang panloob na host na magbukas ng koneksyon sa kliyenteng iyon. Suriin ang patakaran sa pag-access ng server at ang firewall ng host ng kliyente bago magpasya na sira ang daan.

Patunayan gamit ang isang flow at isang capture

Patunayan ang daan sa isang koneksyon sa halip na pangkalahatang pagsubok sa maabot. Obserbahan ang parehong flow sa magkabilang dulo: ang kahilingang dumarating sa serbisyo at ang sagot na lumalabas dito.

tcpdump -ni any host 10.90.0.25 and port 443

Bago ang pagwawasto, ipinapakita ng capture ang sagot na lumalabas patungo sa gateway na hindi ito iru-ruta. Pagkatapos ng pagwawasto, lumalabas ang sagot patungo sa server at nagiging kumpleto ang flow. Pagkatapos, tiyakin ang rutang gagamitin ng gateway para sa ikalawang address ng kliyente, upang lumitaw ngayon ang pool na hindi mo nasakop at hindi pagkalipas ng isang linggo.

Tapusin sa apat na pagsusuring nagsasara nito: tumutugma ang source address sa serbisyo sa mode na nilayon mo, may ruta ang gateway sa bawat pool na ginagamit, pinapayagan ng forwarding at filter ang dalawang direksyon, at nakukumpleto ang isang tunay na flow mula simula hanggang dulo. Ipinaliwanag ng Mga madalas itanong tungkol sa pag-ruta ng Access Server ang parehong prinsipyo para sa naka-install na release, na ang sinusuportahang configuration interface ay maaaring iba sa mga lumang gabay.