VPN client sa isang LAN server: bakit lumalabas ang mga sagot sa maling daan

Ang mga sintomas ay sumusunod sa isang hugis: gumagana ang isang host, pagkatapos kumokonekta ito sa VPN bilang client, at ngayon naaabot ito ng mga LAN client habang nawawala ang mga sagot nito. Ipinapakita ng capture sa host na lumalabas ang mga sagot sa device ng tunnel sa halip na sa interface ng LAN. Walang sira sa tunnel, at ang ayos ay isang ruta, hindi muling pagkonekta. Gawin ang apat na pagsusuri sa ibaba nang sunod-sunod at huminto sa unang nabigo.

Ang sagot ay bagong packet, hindi pagbalik sa daan

Nakatutulong na iwanan ang ideya na bumabalik ang sagot sa daang tinahak ng kahilingan. Ang routing ay pinagpapasyahan kada packet, kada direksyon, sa host na nagpapadala. Ang kahilingang dumating mula sa 10.64.0.23 sa loob ng tunnel ay hindi gumagawa ng rutang pabalik; kapag sumagot ang host, ang sagot ay ihinahambing sa table bilang bagong packet at lumalabas sa rutang nanalo.

Iyon ang dahilan kung bakit ang full-tunnel client sa isang makina na nagsisilbi rin ng LAN ay gumagawa ng ganito kalitong kabiguan. Naglalagay ang client ng default na ruta, o ng dalawang kalahating default na ruta na ginusto ng ilang client, at tumutugma na ngayon ang sagot sa isang LAN client sa tunnel. Pumupunta ito sa provider, na walang dahilan para ipasa ito, at nakikita ng LAN client ang timeout kahit buhay ang host at sumasagot nang lokal. Ginagawa itong halata ng capture, at ipinapaliwanag ito ng routing table.

Tandaan ang dalawang subnet habang binabasa ang natitira. Ang isa ay ang pool ng address ng VPN na pinanggagalingan ng malalayong client, sa halimbawang ito 10.64.0.0/24. Ang isa naman ay ang LAN na dapat magpatuloy sa paggana, 172.16.24.0/24 kasama ang router nito sa 172.16.24.1. Ang bug ay ang trapiko sa pagitan nila ay pinagpapasyahan ng default na ruta.

Patunayan ito sa capture at lookup

Bago baguhin ang anuman, tiyakin kung aling device ang gagamitin ng sagot. Ang lookup ay mas mabilis kaysa capture at sinasagot ang eksaktong tanong na sasagutin ng kernel kapag binubuo ang packet.

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

Basahin ang sagot sa dalawang bahagi. Kung ito ay nagngangalan ng dev tun0, ie-encapsulate ng host ang sagot at ibibigay sa provider, at hindi ito makikita ng LAN client. Kung nagngangalan ito ng dev eth0 ngunit nag-timeout pa rin ang client, tama na ang ruta at itinatapon ang packet mamaya, na ibang problema at ibang ayos.

Ang capture sa parehong hakbang ay nagtatakda ng pagdududa na hindi kayang ayusin ng ping. Ang echo reply na umabot sa LAN client ay nagpapatunay na may gumaganang daan, hindi kung aling interface ang nagdala nito, kaya gawin ang capture sa host mismo at tingnan kung saan lumalabas ang mga frame. Ang printer sa parehong subnet ay patuloy na sumasagot, dahil ang direktang ruta nito ay mas espesipiko kaysa default ng tunnel. Ang forwarded port ay nabibigo tulad ng anumang ibang flow, dahil ang table ang pumipili ng interface, hindi ang koneksyon.

I-install ang pinakanipis na rutang lumalampas sa tunnel

Ang haba ng prefix ang nagpapasya, hindi ang metric, kaya ang ruta para sa pool ng client sa pamamagitan ng LAN router ay nananalo sa anumang default na inilalagay ng VPN client. Hindi kailangan ang operasyon sa metric, at ang default ay maaaring manatili kung saan ito inilagay ng client.

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

Gamitin ang replace sa halip na add, dahil ang client na muling kumokonekta ay nakapaglagay na ng sariling entry at ang ikalawang add ay nabibigo sa error na may rutang umiiral na binabasa na parang problema sa pahintulot. Sa host ng Windows ang katumbas ay route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, kung saan ang -p ay nagpapanatili ng entry sa mga restart, dahil maaaring buuin muli ng client ang table kapag bumalik ang tunnel. Sa makabagong host ng Windows ang sinusuportahang katumbas ay New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, habang ang lumang utos na route ay pinananatili bilang lumang anyo.

Isang detalye ang nagpapasya kung ito ay tama o kapani-paniwala lamang: ang susunod na hop ay dapat ang router na tunay na nagmamay-ari ng daang pabalik sa mga client. Ang pagturo ng ruta sa address na naaabot mismo sa pamamagitan ng tunnel ay gumagawa ng loop na lumilitaw bilang paminsan-minsang pagkawala sa halip na malinis na kabiguan. Tiyakin na ang susunod na hop ay nasa subnet ng LAN bago kumpirmahin ang linya.

Panatilihin ang sagot pagkatapos ng muling pagkonekta

Ang rutang idinagdag sa kamay ay tumatagal nang pinakamabuti hanggang sa susunod na muling pagkonekta. Kung ang pool ng client ay dynamic, i-pin ito sa configuration ng server upang ang prefix na ni-route mo ay manatiling prefix na natatanggap ng mga client; kung hindi, ang entry ay tumuturo sa walang laman na saklaw at bumabalik ang sintomas pagkalipas ng mga linggo nang walang malinaw na dahilan. Ang pagsulat ng ruta sa sariling up-script ng client ay ang isa pang maaasahang opsyon, dahil tumatakbo ito pagkatapos isulat muli ng client ang table.

Ang stateful firewall ay maaari pa ring talunin ang tamang ruta. Kung ang capture ngayon ay nagpapakita na ang sagot ay lumalabas sa eth0 at nag-timeout pa rin ang client, tingnan kung itinatapon ng host ang packet bago ito ipadala. Ang mahigpit na pag-filter ng reverse path at net.ipv4.conf.all.rp_filter na nakatakda sa 1 ay nagtatapon ng mga packet na ang pinagmulan ay hindi iru-route pabalik sa interface kung saan sila dumating, at iyon mismo ang asymmetric na kaso na ginawa mo ngayon at pagkatapos ay inayos, at ang conntrack state ay nagsasabi ng parehong kuwento para sa mga forwarded port.

Ang huling pagsusuri ay ang hinahayaan ng mga tao: ulitin ang lookup pagkatapos bumaba at muling umangat ang tunnel. Apat na halaga ang dapat tumugma sa isinulat mo: ang destinasyon, ang susunod na hop, ang device at ang piniling pinagmulan. Kung may gumalaw sa mga ito, isinulat muli ng client ang table at ang ayos ay nasa mga hook nito, hindi sa kasaysayan ng shell.