Ang niruruta na kliyenteng VPN ay umaabot sa server pero hindi sa mga host ng LAN

Bumabangon ang tunnel, nagpi-ping ang kliyente sa server ng VPN, at ang shared folder sa isang makinang isang hakbang ang layo ay hindi kailanman sumasagot. Wala sa configuration ng kliyente ang nagpapaliwanag nito, dahil talagang umalis ang kahilingan sa kliyente at talagang dumating. Ang nabigo ay ang paglalakbay pabalik, at ang device na nabigo ay karaniwang ang gateway ng LAN at hindi ang host ng VPN. Ang pagsubaybay sa packet ng sagot ay nagpapaliwanag sa buong klase ng sintomas na ito.

Sundan ang Sagot, Hindi ang Kahilingan

Dini-decrypt ng server ng VPN ang packet ng kliyente at ipinapasa ito sa LAN habang ang address ng kliyente ay nasa source field pa rin. Sinasagot ng host ng destinasyon ang address na iyon, at ngayon ang sarili nitong routing table ang nagpapasya sa lahat. Walang alam ang default gateway nito tungkol sa pool ng tunnel, kaya lumalabas ang sagot patungo sa internet provider at itinatapon kung saan man sa landas na iyon.

Sa kliyente ang sintomas ay tahimik na timeout: walang pagtanggi, walang reset, wala lang. Nag-hang ang pag-browse ng shared folder, nag-uulat ang ping na walang sagot, at mukhang maayos ang mga log ng server dahil ginawa ng server ang trabaho nito.

Ilagay ang Ruta ng Pagbalik Kung Saan Tumingin ang mga Host

Bawat host ng LAN ay nagtatanong sa sarili nitong default gateway, kaya ang gateway ang tanging device na kailangang malaman kung nasaan ang pool ng tunnel. Magdagdag ng static na ruta doon at mamanahin ng bawat host ang tamang landas nang hindi hinahawakan.

Kung ipinamimigay ng gateway ang sarili nitong address bilang opsyon ng DHCP, ipamahagi ang ruta sa ganoong paraan upang awtomatikong kunin ito ng mga bagong makina. Kung hindi, nabubuhay ang ruta sa isang configuration file at nawawala sa susunod na muling pagbuo.

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

Bakit Mukhang Inaayos Ito ng Source NAT

Ang pag-mask ng pool ng kliyente sa likod ng address ng server ng VPN ay nag-aalis ng problema sa pamamagitan ng pag-alis ng address ng kliyente mula sa packet. Bumabalik tuloy ang mga sagot sa server, na alam na kung paano maabot ang tunnel, at gumagana ang lahat. Ang halaga ay hindi na makikita ng mga panloob na host kung sino ang kliyente, at ang bawat koneksyon ay mukhang nagmumula sa isang makina.

Ang palitang iyon ay minsang tama, halimbawa kapag hindi mabibigyan ng static na ruta ang isang device ng vendor. Huwag gawing mas malawak ang panuntunan kaysa sa kasalukuyang pool, dahil ang panuntunang isinulat para sa /24 ay tumitigil sa pagtugma sa araw na muling bilangin ang pool sa /16, at ang unang senyales ay isang pangkat ng mga bagong kliyenteng kumokonekta at walang naaabot.

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

Kailangan ng Landas sa Cloud ng Tatlong Setting

Sa isang VPC bumabalik ang parehong puwang sa ibang anyo, dahil wala talagang ruta ang subnet para sa saklaw ng kliyente. Kailangan ng routing table ng entry para sa pool ng tunnel na naka-target sa network interface ng instance, at ang interface ay dapat nakapatay ang source at destination check upang tanggapin ng platform ang mga packet na ang source ay hindi sariling address nito. Dapat ding payagan ng mga security group at network ACL ang pool sa dalawang direksyon.

Bawat pagliban ay gumagawa ng kakaibang bahagyang pagkabigo. Laktawan ang entry sa routing table at sasagot ang mga pribadong instance sa isang subnet na hindi kayang magdala ng sagot pabalik sa pool. Habang bukas pa ang check, itinatapon ng platform ang sagot pagkatapos na ito ay naipadala na ng instance. Kung walang panuntunan ng security group, hindi talaga dumarating ang kahilingan, at nakikita ng kliyente ang timeout nang isang layer nang mas maaga.

Patakbuhin ang mga Pagsusuri sa Ayos na Ito

Kumpirmahin ang pagpapasa at ang patakaran sa pag-filter bago sisihin ang routing, dahil ang host na hindi magpapasa ay nabibigo sa parehong tahimik na paraan. Pagkatapos basahin ang epektibong setting ng reverse path sa interface na nagdadala ng tunnel, dahil maaaring itapon ng mahigpit na filter ang mga sagot na dumarating mula sa hindi inaasahang direksyon.

Tapusin sa isang capture na kinuha sa host ng LAN habang pinipi-ping ito ng kliyente. Ang kahilingang dumarating na walang tugmang sagot ay nagpapatunay sa ruta ng pagbalik, at ang kahilingang hindi kailanman dumarating ay nagbabalik ng kasalanan sa server o sa tunnel.

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

Ang pagsusuri ng source at destination ay nakadokumento sa gabay ng elastic network interface. Itakda ito sa interface na talagang nagdadala ng trapik ng tunnel, hindi sa isang walang kaugnayang adapter na nakakabit sa parehong instance.