Рекурзивно рутирање: кога тунелот ги фаќа сопствените пакети

Тунелот се крева, дневникот покажува завршено ракување, а една секунда подоцна истата сесија умира и повторно се поврзува во циклус. Овој образец има определена причина: рутата до серверот сега покажува внатре во тунелот, затоа пакетите што го носат тунелот се праќаат низ тунелот. Во автентикацијата ништо не се промени, затоа повторното внесување на податоците за најава не менува ништо. Споредете ја надворешната патека пред и по промената на рутата и рекурзијата станува видлива.

Прво проверете ја надворешната патека

Во игра се два пакети, а не еден. Внатрешниот пакет и припаѓа на апликацијата и треба да биде шифриран, додека надворешниот пакет е адресиран на серверот и мора да стигне до него по пат што не зависи од тунелот.

ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints

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

Зошто сесијата издржува еден миг

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

Овој редослед објаснува зошто тунелот може да работи на преносен сметач, а да не успее на рутер, и зошто дефектот често почнува кога ќе почне сообраќајот, а не при поврзувањето. Го објаснува и циклусот: секое повторно стартување ја воспоставува сесијата пред рутата да го направи тоа невозможно.

Откријте чиј е исклучокот за крајната точка

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

Кај IPsec заснован на рути, проверете ги селекторите на политика што одлучуваат кои пакети влегуваат во тунелот и потврдете дека адресата на партнерот е исклучена од нив. Кај WireGuard, ознаката на заштитниот ѕид на интерфејсот и неговите правила на политика ги држат транспортните пакети надвор од тунелот, затоа рачно додадена стандардна рута може да го расипе тој распоред. Втор VPN профил или административна скрипта што ја препишува стандардната рута е чест виновник. Широките правила за обиколување додадени едно по едно се вообичаениот резултат и тие ја претвораат грешката во рутирањето во табела што никој не може да ја одржува.

Проверете повторно по промена на мрежата

Рута до домаќин низ Wi-Fi порта е точна додека машината не премине на друга мрежа. Тогаш истиот симптом се враќа без никаква промена во конфигурацијата.

Запишете ја адресата на крајната точка, рутата пред и по поврзувањето и интерфејсот што го користел секој од нив. Овие три факти обично ја одделуваат грешката на клиентот од прегазувањето и остануваат и по лицето што ги собрало.

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