Сайттар ортосундагы 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 policypfSense же 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-quick ордуна wg set колдонсоңуз милдеттүү. Ядро жаңы тизмени дароо кабыл алат, бирок ага эч ким маршрут кошпойт, ошондуктан жергиликтүү жаралган трафик дагы эле демейки шлюз аркылуу чыгат. Жаңы WireGuard субнети туннелдин хостунан иштеп, ноутбуктан иштебей калышынын эң кеңири таралган себеби ушул.
Кайтаруу жолу туннелден көп жолу бузулат
Жаңы алыскы субнеттеги хосттор жоопторду VPN шлюзу аркылуу кайтарышы керек. Ошол шлюз алардын демейки маршрутизатору болбосо, жооп LAN маршрутизаторуна кетет, ал аны таштайт же жеке баштапкы дарек менен интернетке жөнөтөт. Шлюзден эмес, алыскы тараптагы хосттон сынаңыз: Linux та ip route get 10.30.20.15 же PowerShell да Find-NetRoute -RemoteIPAddress 10.30.20.15 хост чындыгында колдоно турган кийинки хопту көрсөтөт. Жооп туннелдин акыркы чекити болбосо, ошол жерде жаңы префикс үчүн статикалык маршрут кошуңуз.
Кайтаруу маршруту жок сайтта баштапкы 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 |
Текшерүү — көптөгөн өзгөртүүлөр эрте жабылган жер. Шлюзден ping аз далилдейт, анткени шлюз өзүнөн чыгат жана хосттон башка саясатка көп туура келет. Жаңы субнеттеги хосттон 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 ар тараптын өткөрүүсүн көрсөтөт, ал эми нөл кабыл алынган байт менен кол алышуу алыскы тараптын тизмесине же анын кайтаруу маршрутуна ишарат кылат.
Префиксти, тараптын селекторун же маршрутун, кайтаруу жолу боюнча чечимди жана брандмауэр жазуусун туннелдин калган тизмеси менен кошо жазып бүтүрүңүз. Анан бир шлюзду кайра жүктөп, дагы сынаңыз: кол менен кошулган маршрут жоголот, кийинки адам аны кайра ачпашы керек.