Дадаць другую падсетку ў 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 паказвае перадачу па кожным баку, а рукапоціск з нулём атрыманых байтаў паказвае на белы спіс далёкага боку або яго зваротны маршрут.
Завяршыце, запісаўшы прэфікс, селектар або маршрут боку, рашэнне пра зваротны шлях і запіс фаервала разам з рэштай інвентара тунэля. Затым перазагрузіце адзін шлюз і праверце зноў: маршрут, дададзены ўручную, знікае, і наступнаму чалавеку не давядзецца адкрываць гэта нанова.