Ръкостискането на WireGuard успява, но отговор не се връща

Скорошно ръкостискане доказва, че ключовете работят. Проследете един вътрешен адрес и прочетете броячите на преноса, преди да обвинявате тунела, фърмуера или ключовете.

Скорошните ръкостискания са добра новина и много по-малко твърдение от изречението, което хората искат да напишат. Страните размениха удостоверени съобщения за ръкостискане. Пакетът на приложението все още трябва да стигне до вътрешната си дестинация и да се върне.

Тази пропаст между здрава контролна равнина и безмълвна равнина на данните е цялата тема тук. Две отчитания на едни и същи броячи ви казват от коя страна на пропастта сте.

Ръкостискането доказва ключове, не доставка

Ръкостискането на WireGuard е съгласуване на ключове с удостоверяване. То успява веднага щом страните могат да се достигнат и имат валидни ключове. Маршрутизирането, политиката на защитната стена и самата дестинация са въпроси, които ръкостискането никога не задава.

Така че тунелът може да е напълно установен, докато всеки пакет вътре в него се изхвърля. Неправилно маршрутизиран вътрешен пакет и отговор, който поема друг път, изглеждат еднакво от клиента.

Един вътрешен адрес е целият тест

Изберете една дестинация и се придържайте към нея. Собственият тунелен адрес на отсрещната страна е най-лесният случай, а хост зад нея добавя точно един преход. Редуването между тях без отбелязване на промяната дава резултати, които никой не може да сравни.

След това погледнете маршрута, който клиентът избира. По-конкретен локален маршрут може да изпрати пакета другаде, преди WireGuard изобщо да бъде потърсен, а това се случва винаги когато домашната LAN се застъпва с отдалечения диапазон.

ip route get 10.30.8.10
ip -4 addr show wg0
ip route show table all | grep -w wg0

Адрес, който се разрешава до физическия интерфейс, вече е отговорил на въпроса. Тунелът не изхвърля нищо. Пакетът никога не е влизал в него.

Броячите са доказателство, не присъда

wg show отчита байтове, изпратени и получени за всяка страна, и двете числа се движат независимо. Направете отчитане, изпълнете една разрешена заявка, после направете ново отчитане в същата минута.

wg show wg0 transfer
wg show wg0 latest-handshakes
ping -c 4 10.30.8.10
wg show wg0 transfer

Растящо изпращане при непроменено получаване е подписът на заявка без отговор. То не казва дали заявката е филтрирана, дали дестинацията е била спряна или дали отговорът е тръгнал по друг маршрут. Това са три разследвания с един симптом. Разделете ги, преди да промените каквато и да е настройка.

Фиксиран брой байтове също не е праг за успех. Стойностите на броячите следват трафика и третирането на едно число като доказателство за здраве дава уверени глупости.

Отсрещната страна сама проверява върнатия пакет

Далечната страна приема вътрешен пакет само когато източникът попада в allowedips на тази страна. Маршрут, който съществува при изпращача, не е достатъчен. Липсващ запис за източника при получателя тихо изхвърля върнатия трафик.

Защитните стени на хоста стоят зад тази проверка. Правило за препращане, което разрешава тунелния интерфейс, но не вътрешната подмрежа, приема ръкостискането и отхвърля пакета. От страна на клиента това изглежда точно като мъртва отсрещна страна. Хост с два интерфейса също може да отговори от грешен източник и тогава страната изхвърля отговора, който никога не е очаквала.

Пазете експеримента честен

Тестването на профил за отдалечен достъп от същата домашна мрежа, която той трябва да достигне, упражнява различен път от предвидения. Преминете към външната мрежа и запишете локалния ѝ префикс, за да могат двата пуска да се сравнят.

Малък успешен обмен също не изключва всички проблеми с пътя. По-големи пакети могат да се провалят там, където малките минават, а филтър, който съвпада по размер или протокол, може да се държи различно под натоварване.

Запазете ръкостискането като известен работещ етап и продължете напред от него. Следващото полезно доказателство е къде спира една вътрешна заявка, а не нов набор ключове и още един кръг догадки.

Подобни статии