WireGuard партньор излиза през грешен WAN: пет проверки по ред

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

Изпълнете проверките по-долу по ред. Всяка има условие за спиране, а прескачането напред обикновено дава уверен грешен отговор.

Отделете ръкостискането от препратения поток

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

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

Четете правилото за политика, а не таблицата по подразбиране

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

ip rule show
ip route show table main
ip -4 route get 203.0.113.9 from 10.30.8.2

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

Проверете маркировката и транслацията заедно

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

nft list chain inet filter prerouting
conntrack -L -s 10.30.8.2 2>/dev/null | head
ip -s link show dev eth1

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

Следете кой интерфейс носи отговора

Снимайте и на двата външни канала, докато тече една заявка. Отбележете кой интерфейс носи заявката и кой — отговора. Асиметричните пътища се виждат много по-лесно, отколкото се предсказват.

Ако отговорът пристигне по грешния външен канал, проблемът се е преместил от WireGuard към проследяване на връзки или транслация. Никаква промяна в конфигурацията на партньора няма да го поправи.

Променете едно нещо с път за връщане

Пазете достъп през конзола или извън обхвата, преди да редактирате правила за политика на шлюз. Направете една промяна, тествайте същата разрешена дестинация, след това се свържете отново и потвърдете, че ръкостискането все още използва желания път до крайната точка. Добавете числов тест за второто семейство адреси, защото политика само за v4 оставя същата грешка налична.

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