Lumalabas ang sagot sa LAN, hindi sa tunnel: bakit at paano

Ang serbisyong inilathala sa pamamagitan ng gateway ay gumagana mula sa karamihan ng internet at nabibigo mula sa isang opisina. May sumusuri sa tunnel, nakikitang dumarating ang kahilingan at naghihinuha na ang sagot ay dapat bumalik sa parehong daan. Hindi ganoon gumagana ang Linux, at walang pagsusuri sa tunnel ang makakapagpabago sa sagot. Ang sagot ay iruruta ayon sa destinasyon, at ang nag-iisang nabibigong tumatawag ay nasa subnet na direktang naaabot na ng host.

Ano ang tunay na nagpapasya sa papalabas na packet

Hinahanap ng kernel ang ruta para sa destinasyon ng packet, sinusuri ang mga tuntunin ng patakaran ayon sa pagkakasunod-sunod ng priyoridad at pagkatapos ang talahanayang pinipili ng tumutugmang tuntunin. Ang interface na pinagmulan ng packet ay walang papel, maliban kung may nakasulat na tuntunin o marka upang gawin itong mahalaga. Ito ay katotohanan ng rutang ito ng host, hindi depekto ng tunnel.

Kaya ang kahilingang natanggap sa tunnel ay maaaring gumawa ng sagot na lumalabas sa pisikal na interface, at nagiging isang-daan ang daloy nang walang anumang device na nag-uulat ng error. Suriin ang dalawang direksyon bago magpasya tungkol sa tunnel. Ang sagot na lumalabas sa maling direksyon ay nawawala sa mga counter ng tunnel, kaya hindi nagkakasundo ang dalawang dulo kung may naipadala. Pansinin kung aling counter ang gumalaw bago hawakan ang isang tuntunin.

Bakit nananalo ang lokal na subnet

Ang host na may address sa lokal na network ay may konektadong ruta para sa prefix na iyon sa pangunahing talahanayan, at ang konektadong ruta ay direktang tugma. Kapag ang tumatawag ay galing sa parehong subnet, nakikita ng paghahanap ang lokal na link bago pa isaalang-alang ang tunnel.

Ang kawalan ng simetrya ang nagpapagulo sa diagnosis. Gumagana ang mga tumatawag mula sa mas malawak na internet dahil wala silang katugmang lokal na ruta, samantalang ang nag-iisang tumatawag na nagbabahagi ng prefix ng opisina ay nabibigo, at iyon mismo ang tumatawag na ginagamit ng isang tao sa pagsubok.

Ang saklaw ng peer ay hindi kapareho ng mga naka-install na ruta

Sa panig ng tunnel, inilalarawan ng pinapayagang saklaw ng peer kung ano ang maaaring ipadala sa tunnel at aling mga pinagmulan ang tinatanggap mula rito. Wala silang sinasabi tungkol sa kung saan ipapadala ng lokal na talahanayan ng ruta ang packet.

Kung ang tool ng tunnel ay maglalagay ng default na ruta sa host, maaari nitong hilahin ang walang kaugnayang trapiko sa tunnel bilang collateral damage. Kung saan dapat ang tuntunin ng patakaran ang may hawak ng desisyon, umiiral ang opsyon ng paglalagay ng ruta ng tool para pigilan iyon, at ang mga address, key at setting ng endpoint ay mananatiling eksaktong gaya ng dati. Ang default na rutang idinagdag para sa kaginhawahan ay karaniwang paraan ng pagkawala ng host ng sarili nitong lokal na network.

Piliin ang talahanayan ayon sa address ng pinagmulan

Ang tuntuning nakabatay sa pinagmulan ay nagpapadala ng mga sagot mula sa address ng serbisyo patungo sa pribadong talahanayan na ang default ay ang tunnel, habang ang lahat ng iba ay patuloy na gumagamit ng pangunahing talahanayan. Pumili ng mga numero ng talahanayan at priyoridad na hindi ginagamit lokal, at basahin ang mga umiiral na tuntunin bago maglagay ng anuman. Basahin ang mga buhay na tuntunin sa halip na ang naka-save na file, dahil maaaring magkaiba ang dalawa pagkatapos ng reboot.

ip -6 route add default dev wg0 table 200
ip -6 rule add priority 32000 from 2001:db8:aa::20/128 lookup 200
ip -6 rule add priority 32001 from 2001:db8:aa::20/128 unreachable

Ginagawa ng huling linya na mabigo nang nakikita ang nawawalang ruta sa halip na bumalik sa lokal na link. Dapat talagang nakatalaga sa host ang pinagmulan, at ang karaniwang lokal at pangunahing paghahanap ay dapat manatili sa dating posisyon. Pinipili ng tuntunin ang talahanayan ayon sa pinagmulan; hindi nito inihahambing ang haba ng prefix sa pagitan ng mga talahanayan.

Kumpirmahin ang daan, pagkatapos ang serbisyo

Tanungin ang kernel kung ano ang gagawin nito sa halip na maghinuha mula sa capture, gamit ang address ng serbisyo bilang tagapili ng pinagmulan. Ang tamang sagot dito ay nakakatipid ng buong pagsubaybay ng packet.

ip -6 route get 2001:db8:bb::30 from 2001:db8:aa::20

Dapat pangalanan ng output ang tunnel. Pagkatapos subukan ang pinagmulang hindi mo hinawakan at kumpirmahing ginagamit pa rin nito ang lokal na link, upang manatiling limitado sa isang address ang pagbabago. Ang mas malawak na tagapili ay walang mapapatunayan tungkol sa orihinal na reklamo.

Ano ang hindi naayos nito

Iwanan ang forwarding, mga tuntunin ng firewall at pag-uugali ng ICMPv6 sa gateway gaya ng dati, dahil walang pinapalitan ang rutang batay sa pinagmulan sa mga ito. Ang nawawalang mensahe ng Packet Too Big ay sumisira pa rin sa malalaking sagot, alinmang talahanayan ang nanalo sa paghahanap. Ayusin iyon bago magdagdag ng mga tuntunin ng ruta, kung hindi ay mananatili ang sintomas pagkatapos ng pagbabago.

Kumpirmahin ang modelo ng paglalathala bago ilapat ang alinman sa mga ito. Ang reverse proxy na nagbubukas ng sarili nitong backend connection ay nagpapakita ng sariling pinagmulan at hindi pinapanatili ang tumatawag, kaya hindi maaaring mangyari ang depektong ito sa ganoong disenyo. Ang paglalapat ng tuntunin doon ay magdadagdag ng eksepsyon sa ruta na walang nalulutas at nagtatago ng tunay na dahilan.

Sa huli, isulat ang mga numero ng tuntunin at ang talahanayan sa pamamahala ng configuration ng host. Ang tuntuning idinagdag sa kamay ay nawawala sa susunod na muling pagbuo, at babalik ang tumatawag mula sa opisina na may parehong reklamo.