Два офіси на 192.168.0.0/24: з’єднати їх без перенумерації

October 15, 2025 • February 3, 2026 • Читання: 4 хв • Views: 7

Було корисно?

Нарешті отримали погодження на з’єднання Офісу A і Офісу B. Потім виявляєте, що обидві LAN — 192.168.0.0/24, бо звісно так і буде. Усі просять «просто VPN», але маршрутизація не творить дива: коли обидві сторони претендують на ті самі адреси, пакети не знають, де живе «192.168.0.50».

Це реальність, коли мережі малого офісу стикаються зі «дорослим» зв’язком. Добра новина: ви можете їх з’єднати без перенумерації. Погана новина: треба чітко визначити, що саме ви маєте на увазі під «без перенумерації», бо одні підходи — тимчасовий латок, а інші — правильне кріплення.

Що насправді ламається, коли підмережі перекриваються

Якщо обидва офіси використовують 192.168.0.0/24, у вас не «проблема маршрутизації», а проблема ідентичності. IP‑адреси мають ідентифікувати кінцеві точки. Коли дві кінцеві точки ділять ту саму ідентичність, усе швидко починає поводитися дивно.

Чому простий site-to-site VPN не працює

Класичні схеми site‑to‑site VPN припускають: «Трафік до підмережі X іде в тунель». При перекритті обидві сторони вважають себе підмережею X. Тому:

Хост в Офісі A надсилає на 192.168.0.50. Його ОС вирішує «це в моїй локальній мережі», робить ARP і ніколи не відправляє трафік у VPN.
Якщо змусити його піти в VPN (політична маршрутизація, правила фаєрвола), віддалена сторона отримає пакет із джерелом, що теж виглядає локальним, і відповіді будуть неправильно маршрутизовані.
Навіть якщо ви «якось» змусите це працювати, кожна служба, що використовує IP в ACL, логах або конфігурації, стане неоднозначною і болючою в обслуговуванні.

Жарт №1: Перекриті підмережі — як мати двох колег з іменем «Олексій» в одній і тій самій черзі on‑call. Можна якось обійти, але ваші алерти перетворяться на перформанс‑арт.

Три колізії, з якими ви зіштовхнетеся

Колізія рішення пересилання: хости трактують однакові підмережеві призначення як on‑link. Вони ARP, а не маршрутизують.
Колізія шляху назад: відповіді йдуть не туди, бо джерело/призначення виглядають локальними на обох кінцях.
Колізія стану: фаєрволи/NAT‑таблиці не можуть надійно розрізнити потоки з однаковими 5‑tuple між сайтами, якщо ви нічого не транслюєте.

Виправлення завжди включає зробити трафік однозначним. Це досягається шляхом трансляції адрес, ізоляції таблиць маршрутизації або підняття з’єднання на вищий рівень (оверлей/проксі).

Цікаві факти та історичний контекст

Трохи перспективи допомагає, бо цей безлад не новий — це передбачуваний результат приватної адресації і десятиліть «просто випустити». Ось кілька конкретних фактів, які пояснюють, чому перекриття підмереж таке поширене:

RFC 1918 (1996) популяризував приватний адресний простір (10/8, 172.16/12, 192.168/16), зробивши легкою незалежну вибірку однакових підмереж.
192.168.0.0/24 став «дефолтною LAN» здебільшого тому, що ранні споживчі маршрутизатори йшли з такою конфігурацією, і інерція — сильний наркотик.
NAT спочатку був практичним хаком для економії IPv4; згодом став плацебо безпеки та архітектурною залежністю.
IPsec створювався для захисту мереж‑з‑мереж, але не для колізій ідентичностей; NAT‑Traversal вирішував іншу проблему (NAT у шляху), а не перекриття LAN.
Ранні VPN‑пристрої часто налаштовували «policy‑based» тунелі (сфери шифрування). Ця модель руйнується при перекритті, якщо не додати трансляцію.
VRF (virtual routing and forwarding) прийшли з техніки операторів, щоб тримати маршрути клієнтів окремими на спільній інфраструктурі; зараз вони — найчистіший спосіб тримати перекриті мережі розділеними.
Split‑horizon DNS існує задовго до хмар і досі практичний інструмент, коли доступність по імені можна впорядкувати краще, ніж пряме IP‑достукання.
IPv6 мав покласти край цьому. Натомість багато організацій працюють у dual‑stack частково, зберігають IPv4‑LAN і все одно перекриваються.

Дерево рішень: що слід робити (і про що пожалкуєте)

«Без перенумерації» може означати різні речі. Будьте наполегливі до того, як ви торкаєтеся фаєрвола:

Жорстка вимога: кінцеві пристрої зберігають свої IP і при цьому безпосередньо спілкуються по IP.
М’яка вимога: кінцеві пристрої зберігають IP, але вони можуть досягати віддалених сервісів через нові IP, DNS‑імена або проксі.
Тимчасова вимога: зберегти IP зараз, з’єднати сайти, а потім запланувати перенумерацію пізніше.

Моя однозначна порада:

Якщо потрібна широка L3 доступність між більшістю хостів обох боків: використовуйте NAT між сайтами (також netmap або NAT‑on‑a‑stick) або VRF, якщо маєте серйозні маршрутизатори.
Якщо потрібні лише кілька сервісів (файловий сервер, RDP‑гейтвей, додаток): використовуйте проксі на рівні застосунку або публікуйте сервіси через реверс‑проксі/бастіон.
Якщо підключаєте користувачів/пристрої, а не мережі: використовуйте оверлей з власним адресним простором і моделлю ідентичності.
Не розтягуйте L2 між офісами, щоби «зробити це однією LAN». Хіба ваша робота — писати постмортеми заради спорту.

І цитата, щоб тримати себе в тонусі. Парафраз ідеї, яку часто приписують Пітеру Друкеру: «Якщо ви не можете виміряти це, ви не можете його покращити.» У термінах мереж: якщо ви не можете спостерігати — ви не зможете налагодити.

Патерни рішень, що працюють у продакшні

Патерн 1: NAT / трансляція мережі (звичайний переможець)

Це робоча конячка. Ви залишаєте обидва офіси в 192.168.0.0/24, але вводите трансляційну підмережу для однієї сторони (або обох) при перетині міжсайтового каналу.

Як це виглядає

LAN Офіс A: 192.168.0.0/24
LAN Офіс B: 192.168.0.0/24
Трансляція для B з погляду A: 10.200.0.0/24 (приклад)

Коли хост з A хоче дістатися хоста з B, він цілиться в 10.200.0.x. Крайове міжсайтове пристрій транслює 10.200.0.x в 192.168.0.x через тунель і також транслює джерело, щоб повернення пройшло правильно.

Два варіанти: односпрямована vs двостороння трансляція

Односпрямована (переважно, коли можливо): лише Офіс A ініціює. A бачить B як 10.200.0.0/24. B може не знати про існування A.
Двостороння: A бачить B як 10.200.0.0/24, а B бачить A як 10.201.0.0/24. Це більше роботи, але симетрично і зрозуміліше для ACL.

Плюси

Працює з нормальною маршрутизацією; кінцеві пристрої не змінюються, якщо ви використовуєте DNS та/або доступ по порту.
Сумісний з IPsec route‑based, WireGuard, GRE тощо.
Обмежена зона ураження: трансляція застосовується лише між сайтами.

Мінуси

Деякі додатки ламаються, якщо вони вбудовують IP у payload (SIP, старі ліцензії, певні SMB‑випадки).
Операційна складність: налагодження NAT вимагає дисципліни та логів.
Команди безпеки інколи не люблять «приховування» адрес — хоча це не приховування, а просто переназначення.

Чого уникати: хаотичний SNAT «бо так працює». Використовуйте детермінований, документований мапінг (netmap або 1:1 там, де можливо). Випадковий портовий overload NAT через тунель — рецепт інцидент‑звіту в майбутньому.

Патерн 2: Проксі на рівні застосунків (нудно, ефективно, обмежено)

Якщо реальна мета — «користувачі Офісу A потребують доступу до облікової програми в Офісі B» і все, не створюйте злиття мереж. Опублікуйте додаток правильно.

Приклади:

Реверс‑проксі для HTTP(S) додатків (Nginx/HAProxy) у DMZ або сервісній мережі.
RDP‑gateway / бастіон для кількох Windows‑серверів.
Доступ до файлів через відокремлений сервіс (SFTP/HTTPS) замість повного SMB між сайтами.

Це повністю обходить проблему перекриття підмереж: клієнти підключаються до єдиної доступної IP/імені, а не до випадкових внутрішніх хостів.

Патерн 3: Оверлей‑мережі (WireGuard, «Zero Trust», mesh)

Оверлеї призначають власний адресний простір (часто 100.64.0.0/10 або виділені 10.x), і роутинг відбувається за ідентичністю та політикою, а не «чи на моїй LAN».

Підходить коли:

Потрібна зв’язність пристрій‑до‑пристрою, а не підмережа‑до‑підмережі.
Ви не контролюєте краєві маршрутизатори чисто (ISP CPE в управлінні, сторонні фаєрволи, політика).
Хочете поступове розгортання: додавати кінцеві пристрої з часом.

Але: оверлей не дасть автоматично «я хочу, щоб кожен принтер бачив кожен ноутбука». Він дає «конкретні кінцеві точки можуть досягати конкретних кінцевих точок», що зазвичай є тим, що вам насправді потрібно, якщо перестати просити «просто VPN».

Патерн 4: VRF та L3 сегментація (корпоративний рівень)

Якщо ваші маршрутизатори/комутатори підтримують VRF (або інстанси фаєрвола/VDOM), ви можете тримати обидві 192.168.0.0/24 мережі окремими, помістивши їх у різні таблиці маршрутизації. Потім ви селективно «витікаєте» маршрути або робите NAT між VRF у контрольованих точках.

Це найчистіша модель при інтеграції багатьох сайтів із колізіями (часто трапляється при поглинаннях). Але це також найбільш імовірно буде реалізоване неправильно, якщо ваша команда раніше не працювала з VRF у бою. Потрібні інструменти та спостережуваність: per‑VRF маршрути, per‑VRF політики фаєрвола та чіткі діаграми.

Патерн 5: Міст/Layer‑2 розтяг (секція «не робіть так»)

Хтось запропонує «просто зробити міст» — щоб отримати одну LAN. Це означає розширення широкомовних доменів (ARP, DHCP, multicast) через WAN‑лінк. Проблема перекриття не зникає; вона мутує в хаос.

Жарт №2: Розтягувати Layer 2 між офісами — це як підключити ваш дата‑центр до розетки від крамниці поруч. Технічно воно дає електрику.

WAN — це не LAN. Тримайте його маршрутизованим. Якщо вам справді треба L2 для нішевої спадщини, робіть це з явним обмеженням (EVPN/VXLAN, контроль штормів, DHCP‑guard) і планом відкату, який ви протестували при повній чашці кави.

Швидкий план діагностики

Коли зв’язок між перекритими підмережами не працює, люди витрачають години, дивлячись на статус тунелю. Не робіть так. Ваш вузький корок — зазвичай одне з трьох: (1) рішення маршруту на хості, (2) невідповідність політики трансляції, (3) шлях повернення/стан ACL. Ось порядок, що швидко знаходить істину.

1) Підтвердьте, що хост намагається робити (on‑link vs routed)

З клієнта в Офісі A перевірте маршрут до цільової IP (або імені), який він використовує.
Якщо він вважає призначення «link‑local» (той самий /24), він ARP і ніколи не дійде до шлюзу.

2) Підтвердьте, що крайовий пристрій бачить пакети і застосовує очікуваний NAT

Перевірте лічильники хітів фаєрвола/NAT.
Використовуйте захоплення пакетів на внутрішньому та тунельному інтерфейсах, щоб довести трансляцію.

3) Підтвердьте, що шлях повернення симетричний

Шукайте відповіді, що виходять не тим інтерфейсом.
Перевірте conntrack/таблиці стану та зворотню NAT.

4) Тільки тоді підозрюйте тунель чи MTU

Більшість випадків «VPN піднятий, але нічого не працює» — це політика/NAT/маршрути, а не криптографія.
Якщо бачите часткову доступність (ICMP працює, TCP зависає), тоді дивіться на MTU/MSS та фрагментацію.

Практичні завдання: команди, виводи, рішення (12+)

Наступні завдання демонструють Linux‑браузні шлюзи/хости, бо команди явні й легко інспектуються. Ті самі концепції застосовуються до фаєрволів та маршрутизаторів, але з іншим інтерфейсом.

Завдання 1: Визначити локальну підмережу та шлюз на клієнті

cr0x@server:~$ ip -4 addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 192.168.0.23/24 brd 192.168.0.255 scope global eth0
       valid_lft forever preferred_lft forever

Що це означає: хост в 192.168.0.0/24. Будь‑яке призначення 192.168.0.x ядро вважає «локальним».

Рішення: якщо потрібно, щоб цей хост діставав віддалений хост з таким самим 192.168.0.x, використайте іншу адресу призначення (трансляція/оверлей/проксі). Не намагайтеся маршрутизувати 192.168.0.0/24 через тунель з цього хоста; він ніколи не обере маршрут.

Завдання 2: Довести, що хост зробить ARP замість маршруту

cr0x@server:~$ ip route get 192.168.0.50
192.168.0.50 dev eth0 src 192.168.0.23 uid 1000
    cache

Що це означає: воно on‑link (dev eth0), не через шлюз.

Рішення: не використовуйте 192.168.0.50 як «віддалену» адресу з цієї LAN. Використовуйте трансляційний префікс, наприклад 10.200.0.50 (з NAT на межі), або DNS‑ім’я, що резолвиться в ту трансляційну адресу.

Завдання 3: Перевірити ARP‑таблицю після невдалого ping

cr0x@server:~$ ping -c 1 192.168.0.50
PING 192.168.0.50 (192.168.0.50) 56(84) bytes of data.

--- 192.168.0.50 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
cr0x@server:~$ ip neigh show to 192.168.0.50
192.168.0.50 dev eth0 INCOMPLETE

Що це означає: хост зробив ARP у локальній мережі, не отримав відповіді і ніколи не спробував тунельний шлюз.

Рішення: будь‑яке «виправлення», що фокусується на тунелі, передчасне. Ендпоінт не відправляє трафік у тунель.

Завдання 4: Підтвердити, що трансляційний префікс маршрутизований через шлюз

cr0x@server:~$ ip route get 10.200.0.50
10.200.0.50 via 192.168.0.1 dev eth0 src 192.168.0.23 uid 1000
    cache

Що це означає: трафік до 10.200.0.0/24 піде до шлюзу (192.168.0.1), який потім може NAT/tunnel це.

Рішення: продовжуйте з крайовим NAT і політикою тунелю для 10.200.0.0/24 як «віддалений B». Якщо цього маршруту немає, додайте його через DHCP option 121/classless static routes або анонсуйте через внутрішній routing protocol.

Завдання 5: На шлюзі підтвердити, що IP‑форвард включений

cr0x@server:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Що це означає: шлюз буде маршрутизувати пакети між інтерфейсами.

Рішення: якщо це 0, нічого іншого не має значення. Увімкніть і забезпечте персистентність. Якщо це 1, переходьте до маршрутів і правил NAT.

Завдання 6: Перевірити маршрути на шлюзі для трансляційної підмережі і тунелю

cr0x@server:~$ ip route show
default via 203.0.113.1 dev wan0
10.200.0.0/24 dev wg0 scope link
192.168.0.0/24 dev lan0 scope link src 192.168.0.1

Що це означає: шлюз вважає 10.200.0.0/24 досяжним через тунельний інтерфейс (wg0).

Рішення: якщо 10.200.0.0/24 відсутній або вказує не туди — виправте маршрути перш за все. NAT‑правила не врятують погану маршрутизацію.

Завдання 7: Перевірити AllowedIPs у WireGuard (поширена точка відмови)

cr0x@server:~$ wg show
interface: wg0
  public key: 6YcD...redacted...
  listening port: 51820

peer: p9nS...redacted...
  endpoint: 198.51.100.10:51820
  allowed ips: 10.200.0.0/24
  latest handshake: 41 seconds ago
  transfer: 120.33 KiB received, 98.11 KiB sent

Що це означає: peer піднятий і тунель прийматиме/маршруватиме 10.200.0.0/24.

Рішення: якщо AllowedIPs не включає ваш трансляційний префікс, ядро відкине або неправильно маршрутизуватиме трафік. Виправте AllowedIPs і повторіть тест.

Завдання 8: Інспектувати правила NAT (nftables) і підтвердити інкременти лічильників

cr0x@server:~$ sudo nft list ruleset
table ip nat {
  chain prerouting {
    type nat hook prerouting priority dstnat; policy accept;
    iifname "lan0" ip daddr 10.200.0.0/24 dnat to 192.168.0.0/24
  }
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    oifname "wg0" ip saddr 192.168.0.0/24 snat to 10.201.0.1
  }
}

Що це означає: вхідний трафік з LAN до 10.200.0.0/24 DNATиться в 192.168.0.0/24. Вихідний до тунелю SNATиться, щоб віддалена сторона могла повернути трафік до унікального джерела.

Рішення: якщо ви робите тільки DNAT без відповідного SNAT (або навпаки), відповіді, ймовірно, загубляться в неправильній LAN. Використовуйте симетричну трансляцію, якщо у вас немає доведеного асиметричного дизайну.

Завдання 9: Використати conntrack, щоб підтвердити стан і трансляцію

cr0x@server:~$ sudo conntrack -L | head
tcp      6 431999 ESTABLISHED src=192.168.0.23 dst=10.200.0.50 sport=51544 dport=445 src=192.168.0.50 dst=10.201.0.1 sport=445 dport=51544 [ASSURED] mark=0 use=1

Що це означає: conntrack показує оригінальний потік (192.168.0.23 -> 10.200.0.50) і трансльований кортеж у бік віддаленої сторони (... dst=10.201.0.1 як SNAT‑джерело).

Рішення: якщо стан ніколи не з’являється, трафік не доходить до шлюзу або блокується політикою до NAT. Якщо стан є, але немає відповіді — налагоджуйте віддалену маршрутизацію/NAT і політику тунелю.

Завдання 10: Захоплення пакетів на LAN та тунельних інтерфейсах, щоб довести поведінку NAT

cr0x@server:~$ sudo tcpdump -ni lan0 host 192.168.0.23 and host 10.200.0.50
IP 192.168.0.23.51544 > 10.200.0.50.445: Flags [S], seq 123456, win 64240, length 0
cr0x@server:~$ sudo tcpdump -ni wg0 host 192.168.0.50 and port 445
IP 10.201.0.1.51544 > 192.168.0.50.445: Flags [S], seq 123456, win 64240, length 0

Що це означає: бачите оригінальне призначення на LAN (10.200.0.50) і пост‑NAT пакет на тунелі (dst 192.168.0.50, src 10.201.0.1).

Рішення: якщо LAN‑захоплення показує трафік, але тунель‑захоплення — ні, NAT або маршрути на шлюзі неправильні. Якщо тунель показує вихідний, але немає вхідних відповідей, віддалена сторона не повертає (політика, маршрутизація або асиметричний NAT).

Завдання 11: Перевірити reverse path filtering (rp_filter) на Linux‑шлюзах

cr0x@server:~$ sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.wg0.rp_filter
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.wg0.rp_filter = 1

Що це означає: суворий reverse path filtering може відкидати пакети, які прибувають на інтерфейс, що не відповідає уявленню ядра про шлях повернення. NAT плюс тунелі плюс кілька інтерфейсів — саме там це боляче б’є.

Рішення: для шлюзів, що роблять NAT через тунелі, встановіть rp_filter в loose режим (2) або відключіть по інтерфейсу, але тільки з розумінням і компенсуючою політикою фаєрвола. Якщо бачите загадковий односпрямований трафік — це головний підозрюваний.

Завдання 12: Тест MTU/MSS (класика «VPN піднятий, але TCP стоїть»)

cr0x@server:~$ ping -M do -s 1380 -c 2 10.200.0.50
PING 10.200.0.50 (10.200.0.50) 1380(1408) bytes of data.
1388 bytes from 10.200.0.50: icmp_seq=1 ttl=63 time=22.1 ms
1388 bytes from 10.200.0.50: icmp_seq=2 ttl=63 time=21.7 ms

--- 10.200.0.50 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 21.7/21.9/22.1/0.2 ms

Що це означає: з DF встановленим, 1380‑байтовий payload проходить. Якщо це не вдається при успішних менших пінгах — у вас проблема MTU на шляху/тунелі.

Рішення: клamp TCP MSS на межі тунелю і/або зменшіть MTU тунелю. Не «вирішуйте» це відключенням PMTUD глобально; так ви створите нові проблеми.

Завдання 13: Переконатися, що DNS відповіді відповідають плану трансляції

cr0x@server:~$ dig +short fileserver.officeb.example
10.200.0.50

Що це означає: клієнти вказуються на трансляційну адресу, а не на неоднозначну реальну LAN‑адресу.

Рішення: якщо DNS повертає 192.168.0.50 для віддаленого сервісу, клієнти ARP і падають. Виправте DNS (split‑horizon або conditional forwarding), щоб імена резолвилися в трансляційні/оверлей‑адреси.

Завдання 14: Перевірити, що політика фаєрвола не мовчки відкидає трансльований трафік

cr0x@server:~$ sudo nft list chain inet filter forward
table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    ct state established,related accept
    iifname "lan0" oifname "wg0" ip daddr 192.168.0.0/24 tcp dport { 22, 445, 3389 } accept
  }
}

Що це означає: політика за замовчуванням drop, і лише конкретні порти дозволені з LAN у тунель до віддаленої LAN після DNAT.

Рішення: якщо ви мали на меті широкий доступ, а дозволили лише кілька портів — побачите вибіркові відмови. Налаштуйте політику відповідно до вимог. Також: тримайте правила вузькими. «Any‑any між сайтами» — шлях для внутрішнього шкідливого ПЗ стати частим мандрівником.

Три корпоративні міні‑історії

Міні‑історія 1: Інцидент через неправильне припущення

Середня компанія придбала меншу і потрібно було швидке з’єднання для фінансових систем. Обидва офіси були в 192.168.0.0/24, але ніхто не помітив, бо в тікеті було «налаштуйте site‑to‑site VPN, підмережі стандартні». Мережева команда налаштувала IPsec policy‑based тунель з локальними та віддаленими доменами шифру обома встановленими на 192.168.0.0/24. Тунель піднявся. Дашборд зелений. Усі пішли додому.

Наступного ранку бухгалтерія нічого не могла дістати. Перше припущення: «VPN впав». Ні. Друге: «проблема DNS». Теж ні. Справжня проблема була банальною: клієнти в Офісі A намагалися достукатися до сервера в Офісі B по IP (192.168.0.40), і кожен з них ARPив локально. Хелпдеск повідомляв «no route to host» на Linux і «request timed out» на Windows. Інженери дивилися на IPsec SA і таймери два години.

Прорив стався після захоплення пакету на порті клієнта: ARP‑запити до 192.168.0.40 повторювалися, як метроном. Жодного участі дефолт‑шлюзу. Тунель був невинний.

Виправили це розгортанням NAT на краю: Офіс B став 10.200.0.0/24 з погляду Офісу A, і DNS‑імена B сервісів резолвилися в ці трансляційні IP. Інцидент завершився тихо. Постмортем не був «IPsec складний». Це було «ми припустили унікальність, не перевіривши її».

Міні‑історія 2: Оптимізація, що відкотилася

Інша організація з’єднала два перекриті сайти з трансляцією і все в основному працювало. Потім хтось вирішив «оптимізувати затримку», додавши другий тунель через дешевшого ISP і ввімкнувши ECMP між тунелями. Мета — балансування навантаження. Реальність — conntrack і NAT‑стани розбризкуються по двох шляхах без координації.

Деякі потоки опинялися на тунелі A, NATились, а відповіді поверталися тунелем B. Залежно від фаєрвола ці відповіді або відкидалися як invalid, або приймалися і потім неправильно зворотно транслювалися. Користувачі бачили випадкові симптоми: копіювання файлів падало на 37%, RDP‑сесії зависали, веб‑додатки «викидали» під час кліку.

Команда спочатку звинувачувала дешевшого ISP у втраті пакетів. Часткова втрата була, але корінь проблеми — станова трансляція через асиметричні шляхи. Тунелі були здорові; архітектура — ні.

Виправлення не драматичне: закріпити потоки (policy‑based routing або connection marks), щоб обидві сторони з’єднання трималися на одному тунелі, або зробити active/standby замість ECMP для станового NAT‑трафіку. «Оптимізація» стала «регресією стабільності», бо ніхто не спитав, чи може система бути безстанною. Ні — вона не могла.

Міні‑історія 3: Нудна, але правильна практика, що врятувала ситуацію

Глобальна компанія мала звичку: перед будь‑якою зміною міжсайтового зв’язку вони складали односторінковий «Аркуш ідентичностей адрес». Там були переліки підмереж, діапазонів трансляцій, поведінки DNS і відповідальні особи. Це було нудно. Але це запобігло купі збоїв.

Під час переїзду офісу підрядник перепрописав гілку маршрутизатора і випадково змінив DHCP‑пул з 192.168.1.0/24 на 192.168.0.0/24, бо «ми завжди це використовуємо». За ніч принтери й кілька робочих станцій отримали нові оренди. Дизайн трансляції тепер перекрився з локальною реальністю, і перший тікет був «віддалений файловий сервер недоступний».

Інженер на чергуванні відкрив Аркуш ідентичностей адрес, побачив, що 192.168.0.0/24 зарезервовано для трансляцій в тому регіоні, і одразу запідозрив дрейф локальної підмережі. П’ятихвилинна перевірка DHCP‑логів підтвердила це. Вони відкотили DHCP‑скоуп, скинули кілька оренд, і «VPN‑відмова» зникла.

Ніяких героїчних дій. Жодних дзвінків до вендора. Просто нудний документ і дисципліна тримати його в актуальному стані. В операціях нудне часто є найскладнішою практикою.

Поширені помилки: симптом → корінь → виправлення

1) Симптом: «VPN піднятий, але не пінгується віддалений 192.168.0.x»

Корінь: клієнт трактує 192.168.0.x як on‑link і робить ARP локально; трафік ніколи не потрапляє в тунель.

Виправлення: не цільтесь напряму в перекриту віддалену підмережу. Використайте трансляційний префікс (наприклад 10.200.0.0/24), оверлей‑IP або проксі. Відрегулюйте DNS відповідно.

2) Симптом: «Працює лише в один бік» (A може достукатися до B, B не може до A)

Корінь: асиметрична трансляція або відсутність SNAT/DNAT пари; шлях повернення маршрутизований локально на віддаленій стороні.

Виправлення: реалізуйте симетричне відображення або переконайтеся, що віддалена сторона має маршрут назад до трансляційного джерела. Перевірте conntrack і захоплення по обох сторонах.

3) Симптом: «Деякі порти працюють, SMB ламається, RDP скидає»

Корінь: невідповідність політики фаєрвола, допоміжні модулі, або проблеми MTU/MSS; іноді NAT несподівано шпигує за потоками.

Виправлення: підтвердьте дозволені порти в forward‑політиці, протестуйте PMTUD DF‑пінгами, закламіть MSS на межі тунелю і уникайте надмірно хитрих ALGs, якщо вони не потрібні.

4) Симптом: «Працює кілька хвилин, потім зупиняється до перезапуску тунелю»

Корінь: таймаут стану NAT, асиметрична маршрутизація або ECMP через станові пристрої; іноді перегенерація ключів змінює шлях.

Виправлення: забезпечте симетричну маршрутизацію, збільшіть релевантні таймаути якщо виправдано, і уникайте балансування навантаження без синхронізації стану.

5) Симптом: «Лише кілька хостів можуть підключитись; інші не можуть»

Корінь: перекриття на локальному рівні (статичні маршрути на деяких клієнтах, кілька VLAN), дубльовані IP або конфлікти DHCP‑пулів.

Виправлення: інвентаризація адресації. Перевірте клієнтські маршрути і ARP‑поведінку. Заблокуйте DHCP‑scope і переконайтеся, що трансляційні префікси ніде локально не використовуються.

6) Симптом: «DNS резолвить, але з’єднання йдуть до не тієї машини»

Корінь: misconfigured split‑horizon DNS; внутрішнє ім’я резолвиться в локальний 192.168.0.x замість трансляційного/оверлей IP.

Виправлення: реалізуйте conditional forwarding або views, щоб кожен офіс отримував правильну відповідь. Для спільних сервісів віддавайте перевагу іменам, що резолвляться в однозначні адреси.

Чеклісти / покроковий план

Покроковий план: з’єднати дві перекриті /24 з NAT через тунель

Виберіть префікси трансляції, що ніде більше не використовуються. Не обирайте ще один «миленький» дефолт на кшталт 192.168.1.0/24. Використайте щось явно «віртуальне», наприклад 10.200.0.0/24 для Офісу B і 10.201.0.0/24 для Офісу A (з погляду B).
Розв’яжіть, чи потрібна ініціація в один або два боки. Якщо лише кілька сервісів в B мають бути доступні з A — може вистачити односпрямованого режиму.
Виберіть субстрат зв’язності: route‑based IPsec, WireGuard, GRE over IPsec тощо. Route‑based простіше для розуміння NAT.
Додайте маршрути: на шлюзі Офісу A прокладіть 10.200.0.0/24 в тунель. На шлюзі B прокладіть 10.201.0.0/24 в тунель (якщо двосторонньо).
Реалізуйте детермінований NAT:
- DNAT 10.200.0.x → 192.168.0.x на краю Офісу B (або на краю A залежно від дизайну).
- SNAT джерел на трансляційний адрес, щоб віддалена сторона могла повернути без неоднозначностей.
Оновіть DNS: віддалені сервіси мають резолвитись в трансляційні IP. Використовуйте split‑horizon, якщо те саме ім’я має різні відповіді в різних офісах.
Обмежте доступ політикою фаєрвола: дозволяйте лише потрібні порти. Почніть з обмежень, потім розширюйте з розумом.
Валідуйте через захоплення пакетів у трьох точках: клієнтська LAN, локальна сторона шлюзу LAN, та тунельний бік шлюзу.
Заготуйте MTU/MSS до скарг користувачів. Закламіть MSS на межі тунелю, якщо можете.
Запишіть відповідність у місці, де її знайдуть (тікети + ранбуки). Трансляція — це архітектурне рішення, а не секрет.
Моніторинг: додайте перевірки стану тунелю, лічильники хітів NAT і синтетичні транзакції (наприклад, TCP connect до віддаленого сервісу IP/port).
План відкату: будьте готові чисто відключити NAT‑правила і маршрути. Не імпровізуйте під тиском.

Операційний чекліст: перед тим як оголосити «готово»

Кожен крос‑сайт сервіс має ім’я, яке резолвиться в однозначну адресу з кожного офісу.
NAT‑мапінги детерміновані і документовані (який трансляційний діапазон мапиться на яку реальну підмережу).
Повернення трафіку доведено через захоплення пакетів; не вірте припущенням.
Політики фаєрвола принципу найменшої привілеї, з явними allow‑правилами і логуванням drop‑ів під час розгортання.
MTU/MSS протестовані DF‑пінгами і реальним TCP‑передаванням.
Ви можете пояснити дизайн втомленому інженеру о 3:00 ранку за однією діаграмою.

Часті питання (FAQ)

1) Чи можу я вирішити перекриття підмереж лише статичними маршрутами?

Ні. Якщо хост вважає призначення on‑link (така сама підмережа), він ARPить і ніколи не дивиться на ваш хитрий статичний маршрут. Потрібно змінити ідентичність призначення (трансляція/оверлей/проксі) або змінити маску підмережі на хості (що є перенумерацією у багатьох випадках).

2) А якщо змінити один офіс на /23 або /25, щоб «відокремити» їх?

Це часткова перенумерація і зазвичай викличе більше побічних проблем, ніж очікують: DHCP‑скоупи, ACL, налаштування принтерів і жорстко закодовані припущення. Це може бути проміжним кроком, але не обіцяйте, що це безболісно.

3) Чи погана практика NAT між сайтами?

Це компроміс, а не гріх. Для перекритих мереж NAT часто найменш ризикований шлях до зв’язності без торкання кінцевих пристроїв. Погана практика — це недокументований, непослідовний NAT, що перетворює налагодження на археологію.

4) Який трансляційний діапазон обрати?

Вибирайте щось малоймовірне для колізій з існуючими або майбутніми мережами. Багато організацій резервують блок на кшталт 10.200.0.0/16 для трансляцій. Конкретний вибір менш важливий за те, аби він був глобально унікальний у вашому середовищі і записаний.

5) Чи працюватимуть SMB/файлові шейри через NAT?

Зазвичай так, якщо MTU/MSS поряд і станові фаєрволи не псуватимуть пакети. Але SMB чутливий до затримок і втрат, і любить довго живі з’єднання. Тестуйте реальні передачі, а не лише пінги.

6) Чи потрібно транслювати і джерело, і призначення?

В більшості випадків перекриття підмереж вимагає так, принаймні для напрямку ініціації. Тільки DNAT часто не спрацьовує, бо віддалена сторона буде маршрутизувати відповіді локально (бо джерело виглядає як її власна LAN). Симетрична трансляція робить шляхи повернення однозначними.

7) Чи можуть оверлеї (наприклад WireGuard) уникнути NAT повністю?

Часто так. Якщо кожна кінцева точка отримує оверлей‑IP у унікальному діапазоні, пристрої спілкуються через оверлей‑адреси, а не через перекриті LAN‑адреси. Але якщо вам потрібно, щоб «кожен хост в A міг дістатися кожного хоста в B за існуючими IP», оверлей сам по собі цього не забезпечить без додаткової трансляції або проксі.

8) Якщо мені потрібен доступ лише до кількох серверів в іншому офісі?

Використовуйте проксі або публікуйте ті сервіси через невелику сервісну мережу з унікальною адресацією. Це менше рухомих частин, ніж повний мережевий NAT, і легше захистити.

9) Як хмарні VPN вирішують перекриті CIDR (ситуації AWS/Azure)?

Зазвичай вони не «вирішують» це магічно; вони вимагають від вас робити NAT/трансляцію на краю або призначати унікальні адресні простори для кожного мережевого підключення. Перекриття — це топологічна проблема, не чекбокс у вендора.

10) Яке найчистіше довготривале рішення?

Перенумерація в унікальні підмережі та реальний IP‑план. NAT — цілком прийнятний міст (іноді на роки), але найчистіша модель ідентичності довготривало — унікальна адресація плюс добрий routing.

Висновок: наступні кроки, які можна реально виконати

Якщо ви з’єднуєте два офіси, які обидва живуть на 192.168.0.0/24, ви не боретесь із шифруванням. Ви боретесь з неоднозначністю. Ваше завдання — змусити пакети відповісти на одне питання: «Який саме 192.168.0.50 ви маєте на увазі?»

Практичні наступні кроки:

Виберіть трансляційний префікс для одного офісу (10.200.0.0/24 як приклад) і зарезервуйте його, щоб ніхто пізніше не використав локально.
Визначте модель доступу: повна L3 доступність (NAT/VRF) vs доступ до сервісів (проксі) vs доступ до пристроїв (оверлей).
Реалізуйте route‑based зв’язність (WireGuard або route‑based IPsec), а потім додайте детермінований NAT з логами і лічильниками.
Виправте DNS, щоб люди користувалися іменами, а імена резолвилися в однозначні адреси з кожного сайту.
Програйте швидкий план діагностики під час розгортання навмисно, щоб ви могли робити це швидше під час неминучого сюрпризу о 2:00 ночі.

Найпрофесійніший результат — не «ми змусили це працювати». Це «ми зробили це передбачуваним, спостережуваним і пояснюваним». Ось як з’єднати перекриті мережі, не перетворюючи наступне чергування на полювання за головами.