Отговорите на Linux VPN изчезват? Проверете rp_filter и маршрута

Заявките напускат машината, партньорът по VPN отговаря, а отговорът така и не стига до сокета. Тунелът е вдигнат, журналите на партньора показват, че пакетът е изпратен, и нищо в приложението не обяснява тишината. В Linux един от обичайните заподозрени е филтрирането по обратен път: входящ пакет IPv4 може да бъде отхвърлен, когато проверката на източника не съвпада с маршрута, който ядрото очаква за този източник. Проследяването по ред ви казва дали това е причината, или съвпадение. То също ви пази да не изключите защитна мярка, за да поправите липсващ маршрут.

Какво решава проверката на източника

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

Важната дума е правдоподобен. Пакетът може да е напълно законен и пак да не премине проверката, защото не се проверява законност.

Четете ефективния режим, а не едно поле

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

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.<iface>.rp_filter
ip route get <source-of-the-reply>

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

Открийте несъответствието, преди да промените проверката

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

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

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

Селективна корекция, която можете да защитите

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

Включете случай, който трябва да остане отказан. Ако този случай сега минава, корекцията е отслабила повече от единствения път, който сте искали да поправите.

Дръжте IPv4 и IPv6 отделно

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

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