Додавання другої підмережі до VPN між майданчиками: два шляхи
Тунелі на основі політик потребують узгоджених селекторів з обох боків; тунелі на основі маршрутів потребують маршруту. Виберіть правильний шлях і спершу виправте зворотний маршрут.
Додавання другої підмережі до робочого тунелю між майданчиками займає п’ять хвилин в одній схемі й майже цілий день в іншій. Коли тунель встановлює маршрути для названих префіксів, ви додаєте маршрут, і трафік іде ним. Коли він узгоджує одну фіксовану пару селекторів, новий префікс лишається незахищеним, доки обидві сторони не домовляться про відповідну пару. Вирішують три речі: що насправді описує конфігурація кожної сторони, чи звужується узгоджений трафік до найменшої відповідної пари і кому належить зворотний маршрут для нового діапазону.
Читайте ядро, а не етикетку стану
Тунель, що повідомляє про з’єднання, встановив принаймні одну дочірню асоціацію, але не обов’язково ту, про яку ви думаєте. У Linux ядро показує, що застосовується: ip xfrm policy перелічує пари селекторів, а swanctl --list-sas (або старіший ipsec statusall) показує, про що домовилися сторони, включно з селекторами трафіку в кожному напрямку. Якщо нового префікса немає ні там, ні там, він незахищений, що б не казав файл конфігурації.
Порівняйте з таблицею маршрутів. У схемі на основі маршрутів пристрій тунелю є наступним кроком для захищених префіксів. Схема на основі політик часто не має окремого маршруту до віддаленої підмережі, лише маршрут за замовчуванням, бо трафік вибирає політика, а не таблиця.
На основі політик: обидві сторони мають назвати новий префікс
У термінах strongSwan селектор живе в local_ts і remote_ts дочірньої конфігурації, наступниках leftsubnet і rightsubnet. Новий префікс має з’явитися з обох боків дзеркально: те, що майданчик A називає локальним, майданчик B називає віддаленим. Розбіжність рідко дає чисту помилку. Сторони звужуються до перетину, старий префікс працює далі, а новий тихо відмовляє.
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policyУ pfSense або OPNsense це другий запис Phase 2, що спаровує нову локальну підмережу з новою віддаленою, а потім застосування. Збережіть старий запис; заміна переміщує початкову підмережу замість додавання. Якщо наявний Phase 2 уже покриває супермережу на кшталт 0.0.0.0/0 або зведений діапазон, не додавайте поруч вужчий запис: перекривані селектори встановлюють конкуруючі політики, і порядок оцінювання вирішує переможця.
IKEv1 робить кожну пару підмереж окремим Phase 2, а сторона, що приймає одну пару за обмін, відкидає решту. IKEv2 може нести кілька пар селекторів в одній дочірній асоціації, але лише якщо обидві реалізації їх приймають. Список із swanctl --list-sas — це істина; те, що ви ввели, — запит.
На основі маршрутів: маршрут і є політика
Інтерфейс XFRM або пристрій VTI несе трафік згідно з таблицею маршрутів. Ви спрямовуєте новий префікс на пристрій на обох майданчиках, і застосовується стан, прив’язаний до трансформації інтерфейсу. Пари селекторів для синхронізації немає, тому ця схема краще масштабується зі зростанням кількості підмереж. Посібник strongSwan із пересилання докладно розглядає бік ядра.
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10WireGuard іде далі. AllowedIPs — це водночас криптографічний білий список і, через wg-quick, запис у таблиці маршрутів. Додайте префікс лише з одного боку — отримаєте рукостискання, вихідні пакети й тишу, бо віддалена сторона відкидає пакети, чиє джерело не в її списку. Форма wg set замінює весь список, тому перелічіть заново префікси, що вже працювали, інакше відріжете їх:
wg set wg0 peer <PUBKEY> allowed-ips 192.168.10.0/24,192.168.60.0/24
ip route add 192.168.60.0/24 dev wg0Друга команда не є необов’язковою, якщо ви використали wg set замість wg-quick. Ядро одразу приймає новий список, але ніщо не додає для нього маршрут, тому локально створений трафік і далі виходить через шлюз за замовчуванням. Це найчастіша причина, чому нова підмережа WireGuard працює з хоста тунелю, а не з ноутбука.
Зворотний шлях відмовляє частіше, ніж тунель
Хости в новій віддаленій підмережі мають надсилати відповіді назад через шлюз VPN. Коли цей шлюз не є їхнім маршрутизатором за замовчуванням, відповідь іде до маршрутизатора LAN, який або відкидає її, або пересилає в інтернет із приватною адресою джерела. Перевіряйте з хоста на дальньому боці, а не зі шлюзу: ip route get 10.30.20.15 у Linux або Find-NetRoute -RemoteIPAddress 10.30.20.15 у PowerShell покаже наступний крок, який хост справді використає. Якщо відповідь не є кінцевою точкою тунелю, додайте там статичний маршрут для нового префікса.
Source NAT на майданчику без зворотного маршруту — законна альтернатива й спосіб, у який багато розгортань hub-and-spoke уникають дотику до кожного сервера. Застосуйте його й до нового префікса на шлюзі боку призначення:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADEЦіна реальна. Віддалені журнали перестають показувати окремі адреси джерел, а правила фаєрвола, прив’язані до початкової підмережі, зливаються в одне правило для шлюзу. Виберіть це свідомо, а не тому що бракувало маршруту.
Фаєрволи — друга половина зворотного шляху. Пристрої на основі зон не розширюють зону наявного інтерфейсу тунелю на нову підмережу автоматично, а правило, написане для старого префікса, не збіжиться. Додайте нову підмережу до зони або до пари правил в обох напрямках, перш ніж звинувачувати IPsec.
Вирішіть трьома питаннями, потім перевірте трафіком
Коротка версія: конфігурація боку називає префікси (на основі політик) чи трафік маршрутизується в інтерфейс (на основі маршрутів)? Чи обидва кінці перелічують новий префікс? Чи є шлях назад із нової підмережі до початкового діапазону джерел?
| Tunnel style | Where the prefix goes | What breaks if you skip it |
|---|---|---|
| Policy-based IPsec | Selector pair on both peers | Old subnets work, the new one fails with no clear error |
| Route-based XFRM or VTI | Route into the device on both sites | Packets routed but not transformed, or the state never matches |
| WireGuard | AllowedIPs on both peers plus a route | Handshake succeeds, replies are dropped |
| Overlapping supernet | Adjust the existing entry instead | A shadowed policy wins or loses by evaluation order |
Перевірка — це місце, де більшість змін закривають зарано. Пінг зі шлюзу доводить мало, бо шлюз надсилає від себе і часто відповідає іншій політиці, ніж хост. Пінгніть з хоста в новій підмережі, потім запустіть застосунок, що спричинив зміну, і дивіться на лічильники, а не на значок стану.
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg showУ тунелі на основі політик лічильники ip xfrm state мають зростати в обох напрямках; пласкі лічильники означають, що пакет маршрутизовано, але не вибрано. У WireGuard wg show показує передачу за сторонами, а рукостискання з нулем отриманих байтів указує на список дальньої сторони або її зворотний маршрут.
Завершіть, записавши префікс, селектор або маршрут боку, рішення про зворотний шлях і запис фаєрвола разом із рештою опису тунелю. Потім перезавантажте один шлюз і перевірте знову: маршрут, доданий вручну, зникає, і наступній людині не доведеться відкривати це заново.