Додавање втора подмрежа на 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.10

WireGuard оди понатаму. 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 го покажува следниот скок што домаќинот навистина ќе го користи. Ако одговорот не е крајната точка на тунелот, додајте таму статична рута за новиот префикс.

Изворниот NAT на локацијата што нема повратна рута е легитимна алтернатива и начин на кој многу hub-and-spoke поставувања избегнуваат допир на секој сервер. Применете го и на новиот префикс на портата на страната на дестинацијата:

iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADE

Цената е реална. Оддалечените дневници престануваат да прикажуваат поединечни изворни адреси, а правилата на огнениот ѕид врзани за оригиналната подмрежа се спојуваат во едно правило за портата. Изберете го тоа намерно, не затоа што недостигала рута.

Огнените ѕидови се другата половина од повратниот пат. Уредите засновани на зони не ја прошируваат зоната на постоечкиот тунелски интерфејс на нова подмрежа автоматски, а правило напишано за стариот префикс нема да се совпадне. Додајте ја новата подмрежа во зоната или во парот правила во обата правци пред да го обвините IPsec.

Одлучете со три прашања, потоа проверете со сообраќај

Кратката верзија: дали конфигурацијата на страната наведува префикси (заснована на политики) или сообраќајот се рутира во интерфејс (заснована на рути)? Дали двата краја го наведуваат новиот префикс? Дали има пат назад од новата подмрежа до оригиналниот изворен опсег?

Проверката е местото каде повеќето промени се затвораат прерано. Ping од портата докажува малку, бидејќи портата испраќа од себе и често се совпаѓа со друга политика од домаќинот. Пингнете од домаќин на новата подмрежа, потоа стартувајте ја апликацијата што ја предизвикала промената и гледајте бројачи, не икона за состојба.

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 прикажува пренос по страна, а ракување со нула примени бајти укажува на списокот на оддалечената страна или на нејзината повратна рута.

Завршете со запишување на префиксот, селекторот или рутата на страната, одлуката за повратниот пат и записот во огнениот ѕид заедно со остатокот од инвентарот на тунелот. Потоа рестартирајте една порта и тестирајте повторно: рачно додадена рута исчезнува и следната личност не треба повторно да го открива тоа.