Добавяне на втора подмрежа към 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 показва преноса по страни, а ръкостискане с нула получени байта сочи към списъка на далечната страна или нейния обратен маршрут.
Завършете, като запишете префикса, селектора или маршрута от страната, решението за обратния път и записа в защитната стена заедно с останалия инвентар на тунела. После рестартирайте един шлюз и тествайте отново: добавен на ръка маршрут изчезва и следващият човек не бива да го открива наново.