ICMP пренасочувања и вашите VPN рути: што навистина се менува

Тек што треба да помине низ тунелот избира друг следен хоп, а некој во снимката наоѓа ICMP пренасочување. Тоа е хипотеза, а не дијагноза. Пренасочувањето е предлог од рутерот за подобар следен хоп, а дали домаќинот ќе постапи по него зависи од поставките што се разликуваат по платформа, по интерфејс и по адресно семејство.

Пренасочувањето е предлог од рутер

IPv4 ICMP пренасочувањата имаат сопствен тип на порака и тесен сет услови: рутерот го препраќа пакетот низ интерфејсот низ кој пристигнал и знае следен хоп на истиот линк што е поблиску до одредиштето. Потоа му кажува на испраќачот да го користи тој хоп директно. Пораката го именува новиот портал и вклучува дел од оригиналниот пакет, за да може испраќачот да го поврзе со тек. Тоа е љубезна порака за локалната топологија и претпоставува дека испраќачот е на истиот линк со предложениот портал.

Испраќачот може да го игнорира. Протоколот не бара од домаќинот да ја смени табелата, а снименото пренасочување докажува само дека рутерот го испратил.

Токму на оваа разлика грешат повеќето истражувања на пренасочувања.

IPv4 и IPv6 го доставуваат различно

IPv6 има аналоген механизам не во ICMPv4, туку во откривањето соседи, со различни формати на пораки и различни правила за проверка. Поимите се римуваат, пакетите не. Филтер напишан за ICMP тип 5 нема да покаже ништо на IPv6 мрежа, што понекогаш се чита како доказ дека немало пренасочување.

Поставките за политика се исто така одделни, па домаќинот може да прифаќа IPv4 пренасочувања и да ги игнорира IPv6, или обратно.

Проверете ги двете семејства ако тековниот тек може да користи било кое.

Прифаќањето е политика на домаќинот, а не факт за мрежата

На Linux прифаќањето пренасочувања се контролира по интерфејс и глобално, а стандардните вредности се разликуваат меѓу улогата на домаќин и на рутер. Интерфејс на тунел што прифаќа пренасочувања е чуден дизајн, бидејќи во точка-до-точка тунел нема значајна алтернатива на истиот линк за следен хоп. Затоа оваа поставка вреди да се прочита, а не да се претпостави.

Поставките за безбедно пренасочување дополнително ограничуваат на кои портали може да им се верува.

Ако го заострувате домаќинот, токму овие поставки треба да ги прегледате, и токму поради нив две машини на иста мрежа може да се однесуваат различно. Менувајте ги како политика, а не како кратенка за отстранување грешки.

Што не може да објасни пренасочувањето

Конкретните рути, правилата за политичко рутирање и локалните интерфејси го објаснуваат поголемиот дел од неочекуваните патеки без никакво пренасочување. Поопределен префикс, правило што се совпаѓа со изворната адреса, или втор стандарден портал во друга табела секој од нив ќе ја надмине рутата што ја очекувавте. Проверете ги прво, бидејќи се детерминирани и видливи.

Старата снимка е другата стапица, бидејќи клиентот што ја сменил мрежата има друг локален портал.

Старо пренасочување од претходното поврзување не објаснува ништо за тековната патека, затоа запишете кој интерфејс сега го прима контролниот сообраќај.

Проверете ја рутата пред да го обвините тунелот

Прашајте го јадрото која рута би ја користело за одредиштето, потоа споредете ја со табелата што сте ја имале намера. Ако одговорот се совпаѓа со табелата, пренасочувањето не сменило ништо и истрагата припаѓа на друго место. Ако не се совпаѓа, пред да претпоставите дека тунелот е виновен, побарајте кеширано пренасочување, правило за политика или втора табела. Проверката на рутата е вистината, а сѐ друго е приказна за тоа како стигнало таму.

Пренасочувањето не смее да биде причина заштитена патека тивко да стане незаштитена, затоа политиката за прифаќање сѐ уште припаѓа во прегледот на дизајнот. Дефиницијата во RFC 792 сѐ уште е референца за тоа што смее да каже IPv4 пораката.

Запишете го резултатот од проверката на рутата и времето на снимката заедно, и следниот човек ќе може да го повтори вашиот заклучок.