Правила VPN на маршрутизаторі: узгодьте джерело й призначення

Сторінки купівлі маршрутизаторів показують VPN-маршрутизацію як один прапорець, і ця фраза приховує три різні питання. Правило збігається з пристроєм, який надсилає трафік, із сервером, який його приймає, чи з обома? Що відбувається з трафіком, який не збігається з жодним? І коли два правила перекриваються, яке перемагає? Якщо записати відповідь як пару джерела й призначення, розпливчастий список функцій перетворюється на перевірюваний дизайн.

Назва функції приховує два кінці

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

Запишіть вимогу як пару до порівняння продуктів. Саме цю пару ви перевірите пізніше.

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

Побудуйте правило як перетин

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

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

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

Перекриття вирішує пріоритет

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

Прочитайте в посібнику про порядок і про випадок без збігу, потім перевірте обидва на трафіку, який можна спостерігати:

ip rule show
ip route get 203.0.113.10

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

Іменам потрібна політика оновлення

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

Копіювання одного результату пошуку в правило IP — це знімок, а не політика домену.

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

Визначте стан недоступності

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

Вирішіть, яке потрібне вимозі, потім перевірте це, зупинивши тунель і спостерігаючи за потоком:

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://service.example/
ping -c 2 203.0.113.10

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