Отговорът излиза през LAN, а не през тунела: защо и как

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

Какво всъщност решава изходящия пакет

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

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

Защо локалната подмрежа печели

Хост с адрес в локална мрежа има свързан маршрут за този префикс в основната таблица, а свързаният маршрут е директно съвпадение. Когато клиентът идва от същата подмрежа, търсенето намира локалната връзка, преди тунелът изобщо да бъде разгледан.

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

Покритието на партньорите не е същото като инсталираните маршрути

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

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

Изберете таблицата по адреса на източника

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

ip -6 route add default dev wg0 table 200
ip -6 rule add priority 32000 from 2001:db8:aa::20/128 lookup 200
ip -6 rule add priority 32001 from 2001:db8:aa::20/128 unreachable

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

Потвърдете пътя, после услугата

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

ip -6 route get 2001:db8:bb::30 from 2001:db8:aa::20

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

Какво това не поправя

Оставете препращането, правилата на защитната стена и поведението на ICMPv6 на шлюза както са били, защото маршрутът по източник не заменя нито едно от тях. Липсващото съобщение Packet Too Big все още чупи големите отговори, независимо коя таблица е спечелила търсенето. Поправете това, преди да добавяте правила за маршрутизация, иначе симптомът ще преживее промяната.

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

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