Ang peer ng VPN ay nagpi-ping sa ibang interface dahil lokal ang mga ito

Kumokonekta ang isang kliyente ng WireGuard at nagpi-ping sa isang address sa ganap na ibang interface, at dumarating ang tugon. Ipinapakita ng mga capture na nasa tunnel lamang ang kahilingan. Walang sira, at ang maingat na i-disable na setting ng forwarding ay walang kaugnayan. Ito ay paghahambing ng dalawang landas na magkamukha sa diagram at ganap na magkaiba sa kernel.

Ang isang landas ay nagpapasa ng packet para sa iba; ang isa ay naghahatid nito sa host mismo.

Ang packet na nakadirekta sa host ay nananatili sa host

Ang malayong kliyente ay nagpapadala ng IP packet sa isang address na pag-aari ng host. Ang routing ay nagtatanong ng isang bagay tungkol sa packet na iyon: lokal ba ang destinasyong ito? Bawat address na hawak ng host ay lumilitaw sa lokal na routing table, at ang table na iyon ay sinasangguni bago ang pangunahing table, kaya ang packet ay pumupunta sa sariling stack ng host sa halip na lumabas sa ibang interface. Ang tugon ay nalilikha nang lokal, at ito ay bumabalik sa tunnel dahil doon nagmula ang query.

Iyan ang buong mekanismo. Walang forwarding na nangyayari, walang pagbabago ng estado ng interface na kasangkot, at ang address na pinag-uusapan ay hindi kailangang maabot mula sa ibang lugar.

Bakit hindi nalalapat ang ip_forward

Ang forwarding ay namamahala sa mga packet na kailangang lumabas sa ibang interface kaysa sa pinasukan nila. Ang ping sa host mismo ay hindi kailanman tumatahak sa landas na iyon: ang packet ay natutupok nang lokal at ang tugon ay nalilikha nang lokal. Kaya ang pagtatakda ng net.ipv4.ip_forward=0 ay walang binabago dito, at ang isang tuntunin sa forward chain ay hindi kailanman nakikita ang trapikong iyon. Ang tamang kontrol ay nasa input path, na limitado ng papasok na interface o pinagmulan.

Iyon ang dahilan kung bakit ang pag-disable ng forwarding at pag-akala na ang host ay isolated ay gumagawa ng maling pakiramdam ng seguridad.

Basahin ang lokal na table na nagpasya

ip rule show ay karaniwang nag-uulat ng tuntunin na may priyoridad na sero na nagpapadala ng lahat ng paghahanap sa lokal na table muna, at ang ip route show table local ay naglilista ng sariling address ng host na may lokal na saklaw. Kasama sa table na iyon ang mga address sa mga interface na administratibong patay ngunit naka-configure pa rin. Ang mga address na IPv4 na itinalaga nang statiko ay karaniwang nakakaligtas sa pagkawala ng link, at iyon ang dahilan kung bakit ang ping sa isang tulay na patay ay maaari pa ring magtagumpay at magulat sa operator.

Hindi sumasang-ayon ang IPv6 sa eksaktong puntong ito. Ang mga address nito ay karaniwang binabawi kapag bumagsak ang link, maliban kung nakatakda ang keep_addr_on_down. Ihambing ang mga pamilya sa halip na ipalagay na sakop ng isang tuntunin ang dalawa.

Ano ang aktwal na naaabot ng peer

Ang tugon mula sa sariling address ng router sa isang segment ay walang sinasabi tungkol sa mga makina sa likod ng segment na iyon. Hindi maaabot ng peer ang isang host sa likod ng kabilang interface sa landas na ito; naaabot lamang nito ang mga address na pag-aari ng router mismo. Ang pagsubok ng serbisyo sa isang hiwalay na LAN host, sa halip na pag-ping sa address ng router, ang nagtatatag kung pinapayagan man ang forwarding.

Ang paghihigpit ng peer sa mga serbisyong nakatali sa address ng tunnel ay isang usapin ng patakaran sa input. Payagan ang gustong serbisyo sa interface ng tunnel at limitahan ang mga pinagmulan na maaaring gumamit nito, dahil tunay na dumarating ang packet doon.

Suriin din ang mga address na balak mong alisin. Ang pag-alis ng address mula sa isang interface ay mas maaasahan kaysa sa pagpapatong ng mga tuntunin ng firewall sa isang lumang address.