Ang isang daloy na dapat dumaan sa tunnel ay pumipili ng ibang susunod na hop, at may nakakahanap ng ICMP redirect sa isang capture. Iyon ay hipotesis, hindi diagnosis. Ang redirect ay suhestiyon ng router tungkol sa mas mabuting susunod na hop, at kung gagawa ng aksyon ang host ay depende sa mga setting na naiiba ayon sa platform, interface at pamilya ng address.

Ang redirect ay suhestiyon mula sa router

Ang mga ICMP redirect ng IPv4 ay may sariling uri ng mensahe at makitid na hanay ng kondisyon: ipinapasa ng router ang packet sa interface kung saan ito dumating, at alam nito sa parehong link ang susunod na hop na mas malapit sa destinasyon. Pagkatapos ay sinasabi nito sa nagpadala na gamitin ang hop na iyon nang direkta. Pinangalanan ng mensahe ang bagong gateway at may kasamang bahagi ng orihinal na packet upang maituon ito ng nagpadala sa isang daloy. Ito ay magalang na mensahe tungkol sa lokal na topolohiya, at ipinapalagay na ang nagpadala ay kabahagi ng link ng iminungkahing gateway.

Malayang balewalain ito ng nagpadala. Walang bahagi ng protocol ang nag-uutos sa host na baguhin ang talahanayan nito, at ang nahuling redirect ay nagpapatunay lamang na may router na nagpadala nito.

Dito nagkakamali ang karamihan ng pagsisiyasat sa redirect.

Iba ang paghahatid nito ng IPv4 at IPv6

May kahalintulad na mekanismo ang IPv6 sa loob ng pagtuklas ng kapitbahay at hindi sa ICMPv4, na may ibang format ng mensahe at ibang tuntunin sa pagpapatunay. Nagtutugma ang mga konsepto, hindi ang mga packet. Ang filter ng capture na isinulat para sa ICMP type 5 ay walang ipapakita sa isang network na IPv6, na kung minsan ay binabasa bilang patunay na walang redirect na nangyari.

Hiwalay din ang mga setting ng patakaran, kaya maaaring tanggapin ng host ang mga redirect ng IPv4 at balewalain ang IPv6, o kabaliktaran.

Suriin ang dalawang pamilya kung ang daloy na pinag-uusapan ay maaaring gumamit ng alinman.

Ang pagtanggap ay patakaran ng host, hindi katotohanan ng network

Sa Linux, ang pagtanggap ng redirect ay kinokontrol sa bawat interface at sa pangkalahatan, at naiiba ang mga default sa papel ng host at ng router. Ang interface ng tunnel na tumatanggap ng redirect ay kakaibang disenyo, dahil sa loob ng point-to-point na tunnel ay walang makabuluhang alternatibong susunod na hop sa parehong link. Kaya sulit basahin ang setting na ito kaysa ipagpalagay.

Higit pang pinaghihigpitan ng mga setting ng secure redirect kung aling gateway ang mapagkakatiwalaan.

Kung pinapahigpit mo ang isang host, ito ang mga setting na dapat suriin, at ito rin ang dahilan kung bakit maaaring mag-iba ang ugali ng dalawang makina sa isang network. Baguhin ang mga ito bilang patakaran, hindi bilang shortcut sa pag-debug.

Ano ang hindi kayang ipaliwanag ng redirect

Ang mga partikular na ruta, tuntunin ng policy routing at lokal na interface ay nagpapaliwanag sa karamihan ng hindi inaasahang landas nang walang anumang redirect. Ang isang mas partikular na prefix, isang tuntunin na tumutugma sa source address, o isang pangalawang default sa ibang talahanayan bawat isa sa kanila ay nangingibabaw sa rutang inaasahan mo. Suriin muna ang mga iyon, dahil deterministiko at nakikita ang mga ito.

Ang lumang capture ay ang isa pang patibong, dahil ang client na nagpalit ng network ay may ibang lokal na gateway.

Walang naipapaliwanag ang lumang redirect mula sa dating koneksyon tungkol sa kasalukuyang landas, kaya itala kung aling interface ang tumatanggap ng control traffic ngayon.

Suriin ang ruta bago sisihin ang tunnel

Tanungin ang kernel kung aling ruta ang gagamitin para sa destinasyon, pagkatapos ay ihambing ito sa talahanayang inilaan mo. Kung tugma ang sagot sa talahanayan, walang binago ang anumang redirect at sa ibang lugar kabilang ang pagsisiyasat. Kung hindi tugma, bago ipalagay na ang tunnel ang may kasalanan, maghanap ng naka-cache na redirect, tuntunin ng patakaran o pangalawang talahanayan. Ang paghahanap ng ruta ang katotohanan, at ang lahat ng iba ay kuwento kung paano ito naging ganoon.

Hindi dapat maging dahilan ang redirect upang tahimik na maging hindi protektado ang isang protektadong landas, kaya kabilang ang patakaran ng pagtanggap sa pagsusuri ng disenyo. Kahulugan sa RFC 792 ang nananatiling sanggunian sa kung ano ang masasabi ng mensaheng IPv4.

Isulat nang magkasama ang resulta ng paghahanap ng ruta at ang timestamp ng capture, at magagawa ng susunod na tao na ulitin ang iyong konklusyon.

Kaugnay na mga artikulo