Що фіксувати для міжсайтового VPN: селектори й охоплення

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

Налаштований селектор — не узгоджений

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

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

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

Тунелі на основі маршрутів вибирають інакше

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

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

Трансляція належить до тієї самої таблиці

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

Ось та деталь, яка ламає робочий тунель після зміни NAT: селектор досі збігається з початковим префіксом, друга сторона тепер отримує трансльований, а її зворотний маршрут указує на адресу, якої більше немає. Ніщо не пише помилку в момент, коли вони перестають збігатися.

Приватний DNS належить туди ж. Ім’я, яке розв’язується в адресу, непридатну з відповідного сайту, — це помилка в документації з доданим тікетом до підтримки, і винним буде тунель.

Додайте вимогу до сервісу

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

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

Перетворіть запис на план тестування

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

swanctl --list-sas

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

sites: office <-> dc1
configured selector: 10.10.0.0/16 <-> 10.20.0.0/16
negotiated selector: 10.10.4.0/22 <-> 10.20.0.0/16
translated range: 172.16.4.0/22 -> 10.10.4.0/22
service and owner: erp:443 / finance-netops

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