Një rrjedhë që duhet të kalojë nëpër tunel zgjedh një hop tjetër të radhës, dhe dikush gjen një ridrejtim ICMP në një kapje. Kjo është hipotezë, jo diagnozë. Ridrejtimi është sugjerim i ruterit për një hop të radhës më të mirë, dhe nëse hosti vepron sipas tij varet nga cilësimet që ndryshojnë sipas platformës, ndërfaqes dhe familjes së adresave.

Ridrejtimi është sugjerim nga ruteri

Ridrejtimet ICMP IPv4 kanë llojin e tyre të mesazhit dhe një grup të ngushtë kushtesh: ruteri e dërgon paketën nga e njëjta ndërfaqe nga e cila mbërriti, dhe njeh në të njëjtën lidhje një hop të radhës më afër destinacionit. Pastaj i thotë dërguesit ta përdorë atë hop drejtpërdrejt. Mesazhi emërton portën e re dhe përfshin një pjesë të paketës origjinale, që dërguesi ta përputhë me një rrjedhë. Është mesazh mirësjelljeje për topologjinë lokale, dhe supozon se dërguesi ndan lidhjen me portën e sugjeruar.

Dërguesi është i lirë ta injorojë. Protokolli nuk kërkon që hosti të ndryshojë tabelën e tij, dhe një ridrejtim i kapur dëshmon vetëm se një ruter e dërgoi.

Pikërisht në këtë dallim gabojnë shumica e hetimeve të ridrejtimit.

IPv4 dhe IPv6 e dorëzojnë ndryshe

IPv6 ka një mekanizëm analog brenda zbulimit të fqinjëve dhe jo në ICMPv4, me formate mesazhesh dhe rregulla validimi të ndryshme. Konceptet rimojnë, paketat jo. Një filtër kapjeje i shkruar për llojin ICMP 5 nuk tregon asgjë në një rrjet IPv6, gjë që ndonjëherë lexohet si provë se nuk ka ndodhur asnjë ridrejtim.

Edhe parametrat e politikës janë të veçantë, kështu që një host mund të pranojë ridrejtimet IPv4 dhe të injorojë ato IPv6, ose anasjelltas.

Kontrolloni të dyja familjet nëse rrjedha në fjalë mund të përdorë cilën do prej tyre.

Pranimi është politikë e hostit, jo fakt i rrjetit

Në Linux pranimi i ridrejtimeve kontrollohet për çdo ndërfaqe dhe globalisht, dhe vlerat e parazgjedhura ndryshojnë mes rolit të hostit dhe atij të ruterit. Një ndërfaqe tuneli që pranon ridrejtime është projekt i çuditshëm, sepse brenda një tuneli pikë-për-pikë nuk ka hop alternativ të radhës me kuptim në të njëjtën lidhje. Prandaj ky cilësim meriton të lexohet dhe jo të supozohet.

Cilësimet e ridrejtimit të sigurt kufizojnë më tej se cilave porta mund t'u besohet.

Nëse po e shtrëngoni një host, këta janë parametrat për t'i rishikuar, dhe po ashtu janë arsyeja pse dy makina në të njëjtin rrjet mund të sillen ndryshe. Ndryshojini si politikë, jo si shkurtore për korrigjim.

Çfarë nuk mund të shpjegojë një ridrejtim

Rrugët specifike, rregullat e rutimit të bazuar në politikë dhe ndërfaqet lokale shpjegojnë shumicën e shtigjeve të papritura pa asnjë ridrejtim. Një prefiks më specifik, një rregull që përputhet me adresën e burimit, ose një rutë e dytë e parazgjedhur në një tabelë tjetër secili prej tyre anashkalon rrugën që prisnit. Kontrolloni ata të parët, sepse janë përcaktues dhe të dukshëm.

Kapja e vjetër është gracka tjetër, sepse një klient që ka ndryshuar rrjetin ka një portë lokale tjetër.

Një ridrejtim i vjetër nga lidhja e mëparshme nuk shpjegon asgjë për shtegun aktual, prandaj shënoni cila ndërfaqe e merr tani trafikun e kontrollit.

Kontrolloni rrugën përpara se të fajësoni tunelin

Pyetni kernelin cilën rrugë do të përdorte për destinacionin, pastaj krahasoni atë me tabelën që kishit në mendje. Nëse përgjigja përputhet me tabelën, asnjë ridrejtim nuk ka ndryshuar asgjë dhe hetimi i takon diku tjetër. Nëse nuk përputhet, përpara se të supozoni se tuneli është fajtori, kërkoni një ridrejtim të ruajtur në cache, një rregull politike ose një tabelë të dytë. Kërkimi i rrugës është e vërteta, dhe gjithçka tjetër është një tregim se si erdhi kështu.

Një ridrejtim nuk duhet të jetë kurrë arsyeja pse një shteg i mbrojtur kthehet në heshtje në një të pambrojtur, prandaj politika e pranimit i takon rishikimit të projektimit. Përkufizimi në RFC 792 mbetet referenca për atë që mesazhi IPv4 mund të thotë.

Shkruani së bashku rezultatin e kërkimit të rrugës dhe vulën kohore të kapjes, dhe personi tjetër mund ta riprodhojë përfundimin tuaj.

Artikuj të ngjashëm