Відповіді 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 своя поведінка і свої налаштування, і машина може бути суворою в одному сімействі та поблажливою в іншому, поки ніхто не помітить, доки не відмовить конкретне призначення. Перевірте обидва, якщо навантаження використовує обидва.

Запишіть режим, інтерфейс, вивід пошуку маршруту і причину зміни в одному місці. Наступна людина знайде налаштування і жодного пояснення, і або видалить його, або скопіює туди, де йому не місце.