Маршрутизація за джерелом для двох пулів VPN: що пропускає ваше правило

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

Пошук відбувається раніше, ніж джерело перезаписується

Для пакета, що пересилається від клієнта VPN, ядро виконує фіксовану послідовність. Він приходить на інтерфейс тунелю, проходить prerouting, де живуть conntrack і DNAT, далі ухвалюється рішення про маршрутизацію, далі пересилання, далі postrouting, де SNAT застосовується останнім. Правило вигляду from розглядається під час цього рішення про маршрутизацію, тобто бачить початкову адресу клієнта, а не трансльовану.

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

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

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

Тест зі шлюзу — не тест пулу

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

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

ip route get 198.51.100.9 from 172.31.7.42 iif tun0
ip route get 198.51.100.9 from 172.31.8.42 iif tun0
ip route show table 201

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

Пріоритет, а не місце у файлі

Правила оцінюються в порядку зростання пріоритету, і значення має число, а не порядок, у якому ви їх набрали. Таблиця local розташована на пріоритеті 0, таблиця main — на 32766, а правило за замовчуванням — на 32767, тому правило, додане з пріоритетом за замовчуванням, опиняється ближче до кінця списку і програє майже всьому.

ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201

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

Відповідне правило, що вказує на неповну таблицю, — інша пастка. Якщо таблиця 201 містить маршрут за замовчуванням, але не маршрут до призначення, пакет відкидається або надсилається не туди, а правило в ізоляції виглядає цілком правильним. Читайте таблицю, а не лише правило. Правило — це вказівник, а порожня таблиця — вказівник у нікуди.

Зворотний шлях усе одно має існувати

Політика джерела обирає вихід. Вона не створює зворотного шляху. Якщо другий пул виходить через партнерський тунель, партнер має знати, як дістатися до 172.31.8.0/24, — або маршрутом назад до шлюзу, або отримуючи трансльовані адреси, які він уже знає.

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

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

Не ловіть власний тунель шлюзу в політиці

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

Обмежте кожне правило настільки вузько, наскільки дозволяє проєкт: префікс джерела, вхідний інтерфейс і, де це підтримується, мітка, яку несуть лише пакети клієнта. Потім перевіряйте власну зв'язність шлюзу після кожної зміни правил, бо збій є самореферентним і не проявляється в тесті з клієнта.

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