Ang pagbukas ng VPN port ay hindi nagpapapasok sa mga kliyente sa LAN

Bumangon ang tunnel, nagpatunay ang kliyente, ngunit nananatiling di-nakikita ang LAN sa likod ng gateway. Ang rule na dapat magtuwid nito ay nagpapapasok sa VPN port at gumagana nang eksakto ayon sa nakasulat, dahil ang rule na iyon ang humahawak sa mga packet na naka-address sa gateway mismo. Ang trapiko ng kliyente patungo sa host sa likod ng gateway ay may ibang destinasyon at ibang chain. Ang matagumpay na pag-login ay hindi nagbabago kung alin sa dalawang chain ang tinitingnan ng kernel.

Dalawang chain, dalawang magkaibang destinasyon

Ang kapalaran ng packet ay pinagpapasyahan ng kung saan ito pupunta, hindi ng kung paano ito dumating. Ang trapikong naka-address sa isang address sa gateway ay inihahatid nang lokal at sinusuri ng mga input rule. Ang trapikong ipinapasa ng gateway ay sinusuri ng mga forwarding rule. Ang parehong tunnel interface ay makakagawa ng dalawang uri ng packet, kaya hindi kayang sakupin ng isang rule ang dalawang gawain.

Ang buong alamat sa isang pangungusap: ang pagpayag sa listener ay walang sinasabi tungkol sa pagpayag sa network sa likod nito. Dalawang magkaibang desisyon ito na may magkaibang ebidensya, at ang pangalan ng interface sa pareho ay hindi nag-iisa sa kanila.

Ano ba talaga ang pinapayagan ng listener rule

Ang mga packet ng listener ay nagtatapos sa proseso ng VPN, at iyon ang nagpapahintulot na maitayo ang tunnel. Ang administration page ng gateway at isang lokal na diagnostic na sagot ay gumagamit din ng sariling input path ng host, kaya pumapasa ang test patungo sa gateway habang bumabagsak ang lahat sa likod nito. Pareho ang tama ng dalawang resulta at wala sa kanila ang tungkol sa LAN.

Kapag dinecapsulate ng proseso ang trapiko ng kliyente para sa ibang destinasyon, pumapasok ang packet sa forwarding path at kailangan ng pahintulot doon. Ang matagumpay na pagpapatunay ang nagtatakda kung sino ang kliyente; hindi nito itinatakda kung saan ito makakapunta. Magkaiba ang may-ari, log at mensahe ng error ng dalawang tanong.

Subukan mula sa kliyente, hindi kailanman mula sa gateway

Ang test na ginawa sa gateway ay sumusunod sa sariling output path ng host at maaaring pumasa habang sarado ang forwarding path. Simulan ang test mula sa kliyente at tingnan ang dalawang dulo ng daloy.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

Kung lumitaw ang kahilingan sa tun0 at walang nakarating sa destinasyon, itinatapon ang packet pagkatapos makarating, na tumuturo sa mga forwarding rule o sa sariling pag-filter ng destinasyon. Kung wala talagang lumitaw sa tun0, hindi man lang ito ipinapadala ng kliyente sa tunnel, at ang problema ay routing sa kliyente at hindi patakaran sa gateway. Ihambing ito sa kahilingang lumalabas nang tama at walang ibinabalik, na siyang kaso ng daan pabalik.

Ang forwarding ay nangangailangan ng tatlong bagay, hindi isa

Dapat naka-enable ang forwarding sa kernel, dapat tanggapin ng filter rule ang daloy, at dapat maabot ang destinasyon na may daan para makabalik ang sagot. Kung kulang ang isa sa tatlo, pareho ang katahimikan mula sa pananaw ng kliyente.

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

Basahin ang tatlong output nang magkasama. Ang zero sa una ay nagpapawalang-bisa sa dalawa pa, at ang default-drop na patakaran sa pangalawa ay nagtatapon ng mga packet ng kliyente habang patuloy na gumagana ang sariling trapiko ng gateway. Ipinapakita ng pangatlong output kung bakit hindi kailanman naging problema ang listener rule.

Panatilihing hiwalay ang dalawang set ng rule sa dokumentasyon

Isulat ang listener rule at ang rule ng forwarded service sa magkahiwalay na linya, na may magkahiwalay na may-ari at dahilan. Kapag nagbago ang VPN port o may na-publish na bagong serbisyo, pinipigilan ng paghihiwalay na iyon na palawakin nang tahimik ng isang pagbabago ang isa.

Sa halip na ituring ang bawat authenticated peer na pinagkakatiwalaang miyembro ng LAN, gumamit ng makikitid na rule para sa mga saklaw ng kliyente at serbisyong nangangailangan nito. Inilalarawan ng mga tala sa forwarding ng StrongSwan ang panig ng return route at pagsasalin ng parehong hangganan, na ikatlong desisyon na naman.

Panghuli, panatilihing tuwid ang mga layer kapag tinanggihan ang isang user. Kung nakarating ang kahilingan sa host at tinanggihan ng application ang account, ayusin ang pahintulot ng application sa layer na iyon; ang pagpapalawak ng forwarding ay hindi makapagbibigay ng kredensyal sa file sharing at papalawakin ang access para sa lahat ng iba pang kumokonekta nang matagumpay.