Односторонній трафік після вимкнення SNAT підмережі Tailscale

Вимкніть вихідний NAT на маршрутизаторі підмережі Tailscale, і тунель продовжить працювати, а з'єднання через нього припиняться. Запити надходять до призначення з власною overlay-адресою віддаленого клієнта, що і є сенсом зміни, і відповідям тепер потрібен шлях, про який LAN ніколи не мала знати. Без цього шляху пакети приземляються, відповіді виходять через звичайний шлюз, і збій виглядає як проблема міжмережевого екрана, яку не пояснює жодне правило. Тунель здоровий; зворотне плече відсутнє.

Що приховував SNAT

Коли SNAT увімкнено, маршрутизатор переписує адресу джерела на власну LAN-адресу перед передачею до підмережі, тому призначення відповідає хосту, до якого вже вміє дістатися, і більше нічого не потрібно налаштовувати. Вимкнення зберігає початкове джерело, і призначення бачить адресу в діапазоні overlay, а не сусіда на власному дроті. Ця адреса реальна й маршрутизована по всьому tailnet, але з LAN через шлюз за замовчуванням вона недосяжна. Документований перемикач — --snat-subnet-routes=false, застосований до самого Linux-маршрутизатора підмережі.

Це постійне налаштування, а не перемикач для кожного пакета, тому зворотний шлях має існувати для кожної мережі призначення, яку обслуговує цей маршрутизатор. Саме тому зміна є рішенням про розгортання, а не прапорцем. Усе, що обслуговує цей маршрутизатор, успадковує вимогу в той самий момент.

Де може бути зворотний шлях

Три розміщення є звичними, і вони різняться охопленням, а не правильністю. Статичний маршрут на хості призначення найпряміший і найменш масштабований, оскільки кожному пристрою потрібна власна копія. Таблиця маршрутів у VPC або на маршрутизаторі майданчика охоплює всю мережу одразу, а опція DHCP з безкласовими статичними маршрутами доходить до клієнтів автоматично, але тихо відмовляє на пристроях, які її ігнорують.

ip route add 100.64.0.0/10 via 192.168.1.10
ip route get 100.64.0.5

Яке б розміщення ви не обрали, наступний стрибок — це LAN-адреса маршрутизатора і ніколи не його tailnet-адреса. Хост у LAN не досягне overlay, доки не матиме цього маршруту, тому наступний стрибок усередині overlay є циклічним і нікуди не надсилає пакет. Ця єдина помилка пояснює більшість конфігурацій, які виглядають правильно і все одно не працюють, і вона переживає будь-яку перевірку, що читає лише власну таблицю маршрутизатора. Запишіть, яке розміщення ви використали, інакше наступна людина перевірить неправильне.

Читання збою як одностороннього трафіку

Симптом легше розпізнати, ніж причину: служба відповідає на самому маршрутизаторі й мовчить із боку віддаленого клієнта. Запис на призначенні показує запити, що надходять, і відповіді, що виходять, що виглядає як успіх, доки не помітиш, куди ці відповіді прямують. Вони йдуть до шлюзу за замовчуванням, а отже, вхідне плече працювало, а зворотне — ні.

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

sudo tcpdump -ni any host 100.64.0.5
ip route get 100.64.0.5

Чи варта справжня адреса маршруту

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

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

Міжмережевий екран, журналювання й подвійна роль

Кожне правило, що збігалося з LAN-адресою маршрутизатора, тепер збігається з іншим джерелом, включно з правилами дозволу й будь-яким полем журналу, де маршрутизатор записувався як клієнт. Прочитайте ці правила до першого тесту, а не після першої відмови, бо правило, що дозволяє лише адресу маршрутизатора, повністю блокує нове джерело. Звузьте заміну до клієнтів і портів, яким вона потрібна, а потім переконайтеся, що вона тихо не пропускає весь tailnet.

sudo nft list ruleset | grep -n '100\.64'
sudo iptables-save | grep -n '100\.64'

Один вузол, що служить водночас вихідним вузлом і маршрутизатором підмережі, — документована комбінація, яка може втрачати висхідний трафік після вимкнення SNAT підмережі. Розділення цих ролей на різних вузлах знімає цю засторогу й дає кожному маршруту та політиці екрана одного власника. Якщо ролі мають залишатися разом, очікуйте такої поведінки й перевірте її, перш ніж звинувачувати клієнта. Тримайте маршрут, налаштування перемикача й розподіл ролей в одній нотатці, бо їх читають разом, коли наступне з'єднання не вдається.