Перекриття підмереж між офісами: 3 робочі рішення без перенумерації

Що насправді ламає «перекриття підмереж» (і чому)

Перекриття підмереж — це не абстрактна «проблема маршрутизації». Це проблема колізії імен з реальними наслідками. Якщо обидва офіси мають 10.10.0.0/16 і ви намагаєтесь маршрутизувати між ними, хост у Сайті A не може відрізнити «10.10.1.20 у Сайті A» від «10.10.1.20 у Сайті B». Ваші маршрутизатори теж не можуть — принаймні не в рамках класичної семантики IP-маршрутизації.

Що ви побачите в продакшн

• Асиметрична доступність: A іноді може дістатися сервера B; відповіді зникають, бо шлях назад вирішується на локальний «двійник».
• Брехня ARP та кешу сусідів: При L2-розширеннях (будь ласка, не робіть цього) з’являються MAC-flap та логи «duplicate IP», бо одна й та сама IP-адреса існує двічі.
• Невизначеність політик NAT/фаєрвола: «Allow 10.10.1.0/24» стає підкиданням монети, якщо ви не уточните, про який саме 10.10.1.0/24 йдеться.
• DNS погіршує ситуацію: Якщо обидва сайти публікують внутрішні імена в одній зоні, ви отримаєте «коректні» відповіді, що вказують на неправильний двійник.
• Моніторинг перетворюється на художню літературу: Ваш NMS пінгує 10.10.1.20 і вважає віддалену систему «вгору», бо він потрапив на локальний двійник.

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

Порада з позиції досвіду: Не намагайтеся «змусити маршрутизацію віддавати перевагу віддаленому сайту». Ви не вийдете з колізії імен, не додавши нової ідентичності простору імен (NAT, VRF або оверлей).

Швидка діагностика (перші/другі/треті перевірки)

Це найшвидший шлях ідентифікувати вузьке місце і вибрати найменш погане рішення. Якщо виконувати ці кроки в порядку, аргументи на основі відчуттів припиняться.

1) Підтвердьте, що перекриття реальне (а не просто блокування фаєрволом)

Виберіть одну «проблемну IP» і перевірте, чи вона існує в обох місцях. Перегляньте ARP-таблиці, оренди DHCP або локальну поведінку ping.

• Якщо хост пінгує «віддалений» 10.x.x.x навіть коли VPN вимкнений, ви не дістаєтеся до віддаленого сервісу. Ви потрапляєте на локальний двійник.
• Якщо traceroute ніколи не заходить у тунель і залишається всередині сайту, ви маршрутизуєте локально до мережі-двійника.

2) Визначте, що має спілкуватися між сайтами (а що можна ігнорувати)

Перелічіть потоки: AD, DNS, файлові сервіси, ERP, VoIP, підмережі принтерів, RDP/SSH, моніторинг, резервне копіювання. Потім відсортуйте за бізнес-важливістю і необхідною двосторонністю.

• Двосторонні протоколи (SMB, AD, Kerberos, VoIP) менш терпимі до тимчасових обхідних рішень.
• Односпрямований доступ (користувачі до веб-додатку) часто можна вирішити швидким NAT.

3) Перевірте, де можна застосувати політику: крайній фаєрвол, ядро маршрутизації чи хости

Найкраще рішення залежить від того, де ви можете контролювати простір імен та вибір маршруту.

• Якщо ви контролюєте обидва краю: NAT або VRF зазвичай найшвидші.
• Якщо контролюєте лише одну сторону (партнер, постачальник, придбаний сайт ще «незалежний»): NAT — ваш важіль.
• Якщо потрібна масштабована багатосайтна архітектура: оверлей дорожчий, але чистіший у довгостроковій перспективі.

Коли ви знаєте (a) обсяг перекриття, (b) необхідні потоки та (c) ваші точки контролю, можна вибрати рішення без перетворення VPN на будинок із привидами.

Три робочі рішення (без перенумерації)

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

Матриця рішень (що обирати і коли)

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

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

Рішення 1: NAT (тобто зробити інший сайт «іншим»)

NAT — грубий інструмент, що працює, бо змінює простір імен. Якщо у Сайту B 10.10.0.0/16 конфліктує з Сайтом A 10.10.0.0/16, ви можете змепити Сайт B на «віртуальний» діапазон — наприклад 172.20.10.0/24 або 100.64.10.0/24 — лише в межах тунелю. Для Сайту A Сайт B більше не буде 10.10.0.0/16. Маршрутизація вирішена, принаймні на рівні IP.

Два патерни NAT, що реально працюють

• Двосторонній статичний NAT (1:1 або багато:багато): Найкраще, коли сервери мають бути доступні з обох сторін зі стабільними адресами.
• Source NAT (SNAT) в одному напрямку: Підходить, коли лише одна сторона ініціює з’єднання і ви можете залишити віддалену сторону фактично неінформованою.

Де має бути NAT: на прикордонному пристрої, що бере участь у VPN (фаєрвол/маршрутизатор). Не розкидайте правила NAT по випадкових внутрішніх вузлах, якщо ви не фанат розслідування таблиць стану по кількох коробках.

Що NAT ламає (плануйте це)

• ACL та allowlist на основі IP: Віддалені системи бачать трансляовані адреси. Оновіть політики або використайте узгоджені мапінги.
• Протоколи, що вбудовують IP: Деякі старі додатки, SIP без відповідних хелперів, певні режими FTP. Сучасний стек кращий, але не слід припускати, що все пройде гладко.
• Кейси Kerberos/AD: AD може працювати через NAT, але потрібно обережно ставитися до розв’язання імен, SPN та топології сайтів. Якщо можна уникнути NAT посеред реплікації контролерів домену, краще уникати.

Жарт №1: NAT схожий на те, як одягають бейджики на ідентичних близнюків — корисно, поки хтось не вирішить поміняти сорочки для жарту.

Коли NAT — найкраща відповідь

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

Чого уникати: «Тимчасовий NAT», що стає постійним без документації. Якщо ви робите NAT, ставтеся до нього як до продукту: прозорі таблиці трансляцій, послідовні підмережі, логування і план відкату.

Рішення 2: VRF / сегментація (зберегти обидві «істини» окремо)

VRF (Virtual Routing and Forwarding) дають вам кілька таблиць маршрутизації на одному обладнанні. Це означає, що ви можете мати 10.10.0.0/16 у VRF-A і 10.10.0.0/16 у VRF-B, і вони не будуть колідувати, бо живуть у різних маршрутизувальних всесвітах.

VRF — це «доросле» рішення, коли у вас є контроль над маршрутизацією і ви хочете зберегти початкові IP-адреси скрізь. Воно також правильне, коли вам потрібно кілька накладних орендарів (поширено у MSSP, великих підприємствах або при поступових злиттях).

Два сценарії розгортання VRF

• VRF на краю (рекомендовано): Розмістіть віддалений сайт у власному VRF на VPN-маршрутизаторі/фаєрволі. Імпортуйте/експортуйте тільки потрібні маршрути.
• VRF у ядрі (більша зміна): Якщо перекриття трапляється всередині кампусного ядра, може знадобитися VRF ближче до distribution, щоб запобігти витоку.

VRF не вирішує все автоматично

VRF ізолює маршрутизацію, але не ідентичності. Якщо вам все ще потрібно, щоб додатки у VRF-A спілкувалися з хостами в VRF-B з однаковими адресами, потрібен механізм «моста»: route leaking з NAT, проксі або зміни на рівні додатків. VRF — це в першу чергу стратегія ізоляції, а вже потім — підхід до зв’язності.

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

Режими відмов, яких варто очікувати

• Помилки при «route leaking»: Один пролікований маршрут за замовчуванням — і ви отримали неочікуваний бекхол.
• Дрейф політик безпеки: Фаєрволи мають бути VRF-усвідомленими. Якщо ваші інструменти не розуміють VRF, аудиторам доведеться вивчити нові слова.
• Прогалини в операційних інструментах: NMS, flow-логи та packet-capture повинні бути VRF-специфічними, інакше ви будете шукати привидів у діагностиці.

Рішення 3: Оверлейні мережі (маршрутувати над безладом)

Оверлеї дають кінцевим точкам новий адресний простір (або нову ідентичність), незалежний від андерлею. Подумайте про VXLAN/EVPN, SD-WAN фабрику зі своєю адресацією, мережу на базі WireGuard з призначеними «оверлей-IP», або навіть L3-мережі для додатків. Ідея — мати послідовну ідентичність між сайтами, не зважаючи на підмережі андерлею.

Якщо NAT — це викрутка, а VRF — відсік для інструментів, то оверлей — це повністю новий верстат. Він не найшвидший варіант, але масштабується, коли додаєте більше сайтів, хмар і «тимчасових» винятків.

Оверлейні підходи, реалістичні без повної перенумерації

• Виділений оверлей-підмереж для міжсайтових сервісів: Ви не накриваєте оверлеєм усе — лише сервери, які мають бути доступні між сайтами. Кожен сервер отримує додаткову IP (або loopback) в оверлей-діапазоні.
• Шлюзи сервісів: Замість зміни кожної кінцевої точки, розгорніть шлюзи по сайтах, які рекламують оверлей-маршрути і проксірують/маршрутизують до локальних сервісів.
• SD-WAN з сегментацією: Багато SD-WAN продуктів підтримують перекриті андерлей-мережі, відображаючи їх у різні VPN/VRF-подібні сегменти і рекламують неперекривні «віртуальні» маршрути.

Що ви платите за оверлеї

• Операційна складність: Контрольна площина, шифрування, MTU, накладні витрати на інкапсуляцію та телеметрію. Ви додаєте рухомі частини.
• Крихкість MTU: Інкапсуляція зменшує ефективний MTU. Якщо ви не протестуєте PMTUD, щось «випаде» випадково.
• Потреба в навичках: Команді потрібно вміти читати таблиці маршрутів, EVPN-оголошення або статус mesh-пірів — не лише «тунель вгору».

Жарт №2: Оверлеї чудові, поки хтось не скаже «це ж просто мережі» і не змінить MTU в одному місці.

Чому оверлеї часто найкращий довгостроковий вибір

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

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

1) Інцидент через хибне припущення: «10.50.0.0/16 унікальний. Звісно.»

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

У понеділок служба підтримки отримала скарги від фінансистів, що вони не дістались звітного сервера. Сервер «вгору», логи фаєрвола показували дозволи, а команда додатків наполягала, що сервіс не змінювався. Мережники запустили traceroute з робочої станції. Він ніколи не попав в VPN. Трасування залишилося локальним і закінчилося на SVI комутатора. Класичний ознака: маршрут до 10.50.12.40 був внутрішнім, а не віддаленим.

Виявилось, що обидва сайти використовували 10.50.0.0/16. Звітний сервер був у Сайті B, але у Сайті A був принтер на тій самій IP у забутому VLAN. Принтер навіть не був зламаний; він просто відповідав на ICMP як веселий ошуканець. Тест «пінгує» виявився марним.

Виправлення не було героїчним. Вони додали NAT-мапінг для кількох критичних серверів у Сайті B у діапазон 172.20.50.0/24, оновили DNS для цих сервісів і перестали намагатися напряму маршрутизувати перекриття. Висновок: припущення про унікальність IP псуються з часом, особливо після придбань.

2) Оптимізація, що повернула бумеранг: стиснення маршрутів і «спрощення» політик

Інша компанія вирішила бути хитрою. Вони мали перекриття 192.168.1.0/24 та 192.168.2.0/24 у різних філіях. Замість акуратних трансляцій по підмережах вони узагальнили політики і маршрути до «просто дозволити 192.168.0.0/16 через тунель». Продуктивність VPN трохи покращилась. Їхнє change request схвалили рекордно швидко — це мав бути ще один натяк.

За кілька годин з’явилися дивні явища: RDP-сеанси підключалися до неправильних машин. Сканери активів «знаходили» пристрої, яких не існувало. Гірше — філія тепер могла дістатися адміністративних інтерфейсів іншої філії, бо грубі правила це дозволили. Нічого не вибухнуло відразу, а тому проблеми безпеки часто входять тихо.

Проблема не в тому, що узагальнення завжди погане. Проблема в тому, що узагальнення через перекриті простори знімає останню специфіку, яка у вас була. Вони обміняли коректність на зручність. Коли є перекриття, специфічність — ваш пасок безпеки.

Вони відкотили зміни, потім відбудували рішення з явними NAT-пулами по філіях і явними фаєрвол-об’єктами для перекладених підмереж. Це зайняло довше. Але припинило «телепортацію RDP», що не є бажаною функцією.

3) Нудна, але правильна практика, що врятувала день: детермінований трансляційний підхід + тестовий каркас

У великому підприємстві план злиття був реалістичним: «Ми не будемо перенумеровувати жодну компанію принаймні 18 місяців». Вони впровадили детерміновану схему NAT: кожному сайту виділявся транслюваний /16 з 100.64.0.0/10 (CGNAT-простір), виведений з ID сайту. Все документували як продукт: таблиці мапінгів, правила DNS, імена об’єктів у фаєрволі та невеликий CI-job, що перевіряв, щоб жодні два сайти не отримали перетинаючі трансляційні діапазони.

Потім вони виконали нудну, але важливу роботу: тестовий каркас. Кілька Linux-хостів у кожному сайті запускали заплановані пінги, TCP-handshake та DNS-запити до списку трансльованих IP сервісів. Результати йшли на дашборд з латентністю, втратою пакетів і «часом першого збою». Ніякої магії. Просто інструментація.

Через шість місяців зміна у провайдера спричинила регресію MTU, що ледь не зламала SMB через тунель (ICMP все ще працював, бо звісно ж). Каркас спіймав проблему за хвилини. Команда налаштувала MSS-clamping на краю VPN і уникнула повного дня простою файлових сервісів.

Ніхто не отримав трофея за це. Але вони не проводили вихідні у воєнній кімнаті — а це краще за будь-яку нагороду.

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

Ви не можете виправити те, чого не можете довести. Нижче — реальні завдання, які можна виконати з Linux-хостів і типових мережевих систем. Кожне містить: команду, що означає її вивід і рішення, яке приймаєте на основі цього.

Завдання 1: Доведіть, що «віддалена IP» фактично локальна (перевірка ARP)

cr0x@server:~$ ip neigh show 10.10.1.20
10.10.1.20 dev eth0 lladdr 3c:52:82:aa:bb:cc REACHABLE

Значення: Ваш хост вважає, що 10.10.1.20 знаходиться в локальному L2 сегменті (має MAC на eth0). Це не може бути віддалений маршрутизований хост через VPN.

Рішення: Припиніть дебаг тунелю. У вас перекриття (або неправильний proxy ARP). Плануйте NAT/VRF/оверлей.

Завдання 2: Підтвердіть, який маршрут перемагає для перекритого призначення

cr0x@server:~$ ip route get 10.10.1.20
10.10.1.20 dev eth0 src 10.10.1.100 uid 1000
    cache

Значення: Ядро відправляє 10.10.1.20 через eth0 локально.

Рішення: Якщо ви очікували VPN, вам потрібна нова межа простору імен; ви не зможете «policy route» вирішити ситуацію, коли призначення існує локально.

Завдання 3: Traceroute, щоб побачити, чи трафік потрапляє в тунель

cr0x@server:~$ traceroute -n 10.10.1.20
traceroute to 10.10.1.20 (10.10.1.20), 30 hops max, 60 byte packets
 1  10.10.1.1  0.412 ms  0.381 ms  0.372 ms
 2  10.10.1.20  0.663 ms  0.631 ms  0.612 ms

Значення: Два хопи, повністю локально. Трафік не переходить у тунель.

Рішення: Не змінюйте селектори VPN ще. Спочатку вирішіть проблему перекриття.

Завдання 4: Перевірте, що VPN-інтерфейс існує і піднятий (перевірка на санітарність, не перемога)

cr0x@server:~$ ip link show dev wg0
6: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none

Значення: Інтерфейс піднятий. Це нічого не говорить про коректну маршрутизацію для перекритих призначень.

Рішення: Продовжуйте перевірки маршрутизації/NAT/VRF; не оголошуйте успіх.

Завдання 5: Перевірте стан peer-ів WireGuard (приклад оверлей/mesh)

cr0x@server:~$ sudo wg show
interface: wg0
  public key: qXn2mB3lP9z2gJw8v7m9Zk1a2b3c4d5e6f7g8h9i=
  listening port: 51820

peer: lH8k1m2n3b4v5c6x7z8a9s0d1f2g3h4j5k6l7p8o9=
  endpoint: 203.0.113.10:51820
  allowed ips: 100.64.10.0/24
  latest handshake: 32 seconds ago
  transfer: 1.24 MiB received, 2.88 MiB sent

Значення: Peer живий, allowed IPs визначають діапазон оверлей-маршрутів.

Рішення: Якщо перекриття зберігається, переконайтесь, що ви маршрутизуєте до оверлей-IP, а не до однорідних адрес андерлею.

Завдання 6: Переконайтесь, що DNS вказує на трансльовані/оверлей-адреси, а не на конфліктний андерлей

cr0x@server:~$ dig +short reports.internal.example A
172.20.50.40

Значення: Ім’я резолвиться у нет-перекритий трансльований IP (добрий знак для інтеграції на базі NAT).

Рішення: Якщо повертає 10.50.12.40 і це перекривається, виправте split-horizon DNS або створіть інтеграційні записи.

Завдання 7: Перевірте, що NAT відбувається (перегляд conntrack)

cr0x@server:~$ sudo conntrack -L -p tcp --dport 443 | head
tcp      6 431999 ESTABLISHED src=10.10.1.100 dst=172.20.50.40 sport=51922 dport=443 src=10.10.1.100 dst=10.50.12.40 sport=51922 dport=443 [ASSURED] mark=0 use=1

Значення: Початкове призначення — 172.20.50.40, але воно DNAT-иться до 10.50.12.40 на дальній стороні (або навпаки залежно від розміщення). Триплет показує трансляцію.

Рішення: Якщо під час тесту немає записів conntrack, правило NAT не відповідає або трафік не досягає транслятора.

Завдання 8: Підтвердіть, що правила iptables NAT відповідають вашим очікуванням

cr0x@server:~$ sudo iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A PREROUTING -i wg0 -d 172.20.50.40/32 -p tcp -m tcp --dport 443 -j DNAT --to-destination 10.50.12.40:443
-A POSTROUTING -o wg0 -s 10.50.12.40/32 -p tcp -m tcp --sport 443 -j SNAT --to-source 172.20.50.40

Значення: Детермінований двосторонній NAT для одного сервісу (443). DNAT вхідний, SNAT вихідний.

Рішення: Тримайте NAT симетричним для стано-орієнтованих протоколів. Якщо ви DNAT-ите лише в один бік, зворотний трафік може маршрутизуватися до локального двійника і загинути.

Завдання 9: Перевірте проблеми MTU/MSS, які маскуються під «проблеми перекриття»

cr0x@server:~$ ping -M do -s 1372 172.20.50.40 -c 3
PING 172.20.50.40 (172.20.50.40) 1372(1400) bytes of data.
1372 bytes from 172.20.50.40: icmp_seq=1 ttl=61 time=18.4 ms
1372 bytes from 172.20.50.40: icmp_seq=2 ttl=61 time=18.1 ms
1372 bytes from 172.20.50.40: icmp_seq=3 ttl=61 time=18.3 ms

--- 172.20.50.40 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

Значення: 1400-байтні пакети проходять без фрагментації. Добре для багатьох VPN/оверлей-налаштувань.

Рішення: Якщо це падає, але маленькі pings працюють, налаштуйте MSS-clamping на краю і встановіть коректний MTU тунелю перед тим, як звинувачувати NAT/VRF.

Завдання 10: Підтвердіть, з якого інтерфейсу пакет виходить (корисно при policy routing/VRF)

cr0x@server:~$ ip rule show
0:      from all lookup local
1000:   from 10.10.1.0/24 lookup 100
32766:  from all lookup main
32767:  from all lookup default

Значення: Діє source-based routing для 10.10.1.0/24 через таблицю 100.

Рішення: Якщо перекриття змушує вас застосовувати хитрощі policy routing, перевірте, що джерела мереж унікальні. Policy routing не вирішує ідентичних призначень в одному хост-сегменті.

Завдання 11: Перегляньте альтернативну таблицю маршрутів для VRF/політичного домену

cr0x@server:~$ ip route show table 100
default via 100.64.10.1 dev wg0
100.64.10.0/24 dev wg0 proto kernel scope link src 100.64.10.2

Значення: Таблиця 100 відправляє трафік в оверлей через wg0.

Рішення: Якщо сервіси мають використовувати оверлей-IP, переконайтесь, що правильні джерела потрапляють у правильну таблицю; інакше вони витечуть у main і потраплять на локальні двійники.

Завдання 12: Виявлення дублікатів IP у логах (коли користувачі клянуться, що це «випадково»)

cr0x@server:~$ sudo journalctl -k | grep -i duplicate | tail -n 5
Dec 28 09:11:02 edge kernel: IPv4: martian source 10.10.1.20 from 10.10.1.1, on dev eth0
Dec 28 09:12:44 edge kernel: arp: 10.10.1.20 moved from 3c:52:82:aa:bb:cc to 00:11:22:33:44:55 on eth0

Значення: Та сама IP бачиться з різними MAC. Це або легітимний рух (міграція VM) або — більш імовірно в цьому контексті — дублікати IP/перекриття/витік L2.

Рішення: Якщо бачите переміщення MAC між сайтами — зупиняйтесь. Можливо, ви випадково мостили L2 через WAN або розширили VLAN. Це інша аварія.

Завдання 13: Перевірте вибір шляху фаєрволом за допомогою пакетного захоплення (доведіть, куди йде трафік)

cr0x@server:~$ sudo tcpdump -ni wg0 host 172.20.50.40 and tcp port 443 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
09:21:11.102334 IP 10.10.1.100.51922 > 172.20.50.40.443: Flags [S], seq 39184422, win 64240, options [mss 1360,sackOK,TS val 123 ecr 0], length 0
09:21:11.120118 IP 172.20.50.40.443 > 10.10.1.100.51922: Flags [S.], seq 91233110, ack 39184423, win 65160, options [mss 1360,sackOK,TS val 456 ecr 123], length 0

Значення: SYN/SYN-ACK видно на тунельному інтерфейсі; трафік правильно заходить в оверлей/VPN для трансльованої IP.

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

Завдання 14: Переконайтесь, що «інтеграційні підмережі» не перекриваються ні з чим іншим

cr0x@server:~$ ipcalc 172.20.50.0/24
Address:   172.20.50.0         10101100.00010100.00110010. 00000000
Netmask:   255.255.255.0 = 24  11111111.11111111.11111111. 00000000
Network:   172.20.50.0/24      10101100.00010100.00110010. 00000000
Broadcast: 172.20.50.255       10101100.00010100.00110010. 11111111
HostMin:   172.20.50.1         10101100.00010100.00110010. 00000001
HostMax:   172.20.50.254       10101100.00010100.00110010. 11111110
Hosts/Net: 254

Значення: Ви визначаєте чистий сегмент для трансляції/оверлею.

Рішення: Помістіть ці діапазони під change control. Якщо інша команда пізніше використає 172.20.50.0/24 локально, ви знову отримаєте перекриття — вже з іншими числами.

Завдання 15: Швидкий тест на рівні додатка, що уникає «брехні ping»

cr0x@server:~$ curl -skI https://172.20.50.40/ | head -n 5
HTTP/1.1 200 OK
Server: nginx
Date: Sun, 28 Dec 2025 09:25:02 GMT
Content-Type: text/html
Connection: keep-alive

Значення: Сервіс доступний за трансльованою/оверлей-IP. Це значущіше за ICMP.

Рішення: Якщо curl працює, але додаток усе ще падає — зосередьтеся на DNS-іменах, сертифікатах, SSO/ідентифікації або L7-політиках фаєрвола, а не на «VPN».

Завдання 16: Перевірте, чи локальна мережа вже використовує пропонований діапазон трансляції (чек «не будьте хитрі»)

cr0x@server:~$ ip route show | egrep '172\.20\.50\.0/24|100\.64\.0\.0/10' || echo "no local routes found"
no local routes found

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

Рішення: Повторіть перевірки на ядрових маршрутизаторах і джерелах DHCP/IPAM. Якщо діапазон вже використовується десь, виберіть інший зараз, а не після релізу.

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

1) «Тунель вгору, але нічого не працює»

Симптом: VPN показує підключення; пінги до «віддалених» IP іноді вдаються; traceroute залишається локальним.

Корінь: Перекриття підмереж призводить до того, що локальний маршрут/ARP перемагає; ви потрапляєте на локальних двійників.

Виправлення: Введіть неперекривний простір імен (NAT/оверлей) і використайте DNS, щоб направити клієнтів на трансльовані адреси.

2) «Деякі додатки працюють, SMB/VoIP — ні»

Симптом: Веб-додатки в порядку; файлові шари зависають; великі трансфери зависають; VoIP — односторонній звук.

Корінь: Проблеми MTU/MSS через інкапсуляцію VPN, часто виявляються після додавання оверлеїв.

Виправлення: Встановіть правильний MTU тунелю і застосуйте MSS-clamping на краях; перевірте за допомогою ping з DO-NOT-FRAGMENT та реальних тестів додатків.

3) «Ми зробили NAT і тепер віддалий підрозділ не може нас білити»

Симптом: Політики безпеки віддалого боку відхиляють трафік; логи показують несподівані source IP.

Корінь: SNAT змінює ідентичність клієнта; віддалі allowlist були побудовані під початкові діапазони.

Виправлення: Використовуйте детерміновані NAT-діапазони для кожного сайту, документуйте їх і надайте стабільний source-CIDR для білого списку.

4) «DNS вірний, але користувачі все ще потрапляють не туди»

Симптом: Ім’я резолвиться у трансльований/оверлей IP; але з’єднання потрапляє на несподівану хост-машину.

Корінь: Розбіжність split-horizon DNS, застарілі кеші або записи у hosts; іноді проксі налаштування обходять ваш план.

Виправлення: Очистіть кеші за потреби, перевірте DHCP-налаштування DNS, приберіть hosts-override і валідуюйте з клієнтських підмереж за допомогою dig/nslookup.

5) «VRF-розгортання зламало моніторинг і логи»

Симптом: NMS не може досягти деяких пристроїв; syslog зупинився; NetFlow відсутній для сегменту.

Корінь: Трафік інструментів менеджмент-плану живе в неправильному VRF, або колектори недоступні через відсутність route leaking.

Виправлення: Явно сплануйте маршрути менеджмент-плану: або пролийте маршрути для менеджмент-сервісів, або розгорніть колектори per VRF/segment.

6) «Ми узагальнили маршрути для спрощення, і з’явились дивні доступи»

Симптом: Користувачі дістаються адміністративних інтерфейсів в інших філіях; сегментація порушена.

Корінь: Занадто широкі узагальнення маршрутів і політик через перекриті діапазони зняли необхідну специфіку.

Виправлення: Поверніть специфіку: трансляцію per-site, об’єкти фаєрвола по підмережах та політики найменших привілеїв на основі трансльованих/оверлей-ідентичностей.

7) «Пакети приходять, але відповіді зникають»

Симптом: SYN видно, але немає SYN-ACK; або запит доходить до віддалого, а відповідь повертається на локальну мережу-двійник.

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

Виправлення: Забезпечте симетричний NAT (DNAT+SNAT пара) або вимагайте повернення трафіку через той самий тунель (policy-based VPN селектори або route-based VPN з коректними маршрутами).

Контрольні списки / покроковий план

Контрольний список A: Оберіть рішення за 30 хвилин

1. Перелічіть потрібні міжсайтові потоки (джерело підмережі → сервіс призначення → порти → чи двосторонній?).
2. Підтвердіть обсяг перекриття: точні префікси, що колідують (10.10.0.0/16 vs 10.10.0.0/16 тощо).
3. Визначте точки контролю: ви керуєте обома краями? Чи можете змінити DNS? Чи можна додати шлюзи?
4. Оберіть найменший молоток:
   • Потрібен доступ до конкретних сервісів швидко → NAT
   • Потрібна ізоляція та спільні сервіси без повного злиття → VRF
   • Потрібна масштабована мульти-сайтна фабрика або інтеграція хмари → оверлей
5. Виберіть неперекривний інтеграційний діапазон і зарезервуйте його (не «позичайте» випадковий /24).

Контрольний список B: План розгортання NAT, що не перетвориться на кримінальну сцену

1. Проєктуйте детерміновані мапінги (трансляційні блоки per-site; уникайте одноразових «сніжинок»).
2. Визначте напрямок:
   • Клієнти → сервіси: SNAT може бути достатнім.
   • Двосторонні сервіси: використовуйте симетричний статичний NAT.
3. Оновіть DNS, щоб клієнти використовували трансльовані IP для міжсайтових імен.
4. Оновіть правила фаєрвола, щоб дозволяти тільки трансльовані діапазони (принцип найменших привілеїв, а не «any any»).
5. Перевірте MTU/MSS на шляху тунелю для найбільших очікуваних пакетів.
6. Інструментуйте: packet capture на VPN-інтерфейсі; базові TCP-проби; логування попадань у NAT.
7. Документуйте мапінги в одному авторитетному місці і вводьте зміни через рев’ю.
8. План відкату: одна кнопка/коміт для відкату на прикордонному пристрої та планування TTL DNS.

Контрольний список C: План розгортання VRF для ізоляції та спільних сервісів

1. Визначте межі VRF: які VLAN/підмережі належать до якого VRF (локальні vs придбані/віддалені).
2. Підключіть WAN/VPN до VRF для маршрутизувальної доменної області віддаленого сайту.
3. Сплануйте доступ до «спільних сервісів» (DNS, AD, логування, патчинг) через контрольоване route leaking або проксі.
4. Оновіть політики безпеки, щоб вони були VRF-усвідомленими; перевірте доступ менеджмент-плану.
5. Протестуйте в лабораторії або пілотному сайті з репрезентативними додатками (SMB, Kerberos, VoIP, якщо релевантно).
6. Операціоналізуйте: перевірки моніторингу по VRF, runbook-и та процедури packet-capture.

Контрольний список D: План розгортання оверлею, коли ви готові позбутися винятків

1. Виберіть схему ідентичності оверлею (per-site /24, per-service /32 або призначення per-host).
2. Визначте стратегію кінцевих точок:
   • Додайте оверлей на критичні сервери (найшвидше для обмеженого обсягу).
   • Розгорніть шлюзи по сайтах (менше змін на кінцевих точках).
3. Перевірте MTU end-to-end і налаштуйте MSS-clamping там, де потрібно.
4. Визначте маршрутизацію: які префікси де рекламуються; уникайте реклами андерлей-перекриттів в оверлей.
5. Безпека: ставтеся до оверлею як до продакшн-мережі — логування, ACL, ротація ключів, сегментація.
6. Міграція: переносіть один сервіс за раз; оновлюйте DNS; вимірюйте; і лише потім рухайтесь далі.

Цитата про надійність, щоб тримати себе в реальності

Сподівання — не стратегія. — генерал Гордон Р. Салліван

Факти та історичний контекст (варто знати)

• RFC1918 (1996) створив приватні адресні діапазони явно для зменшення витрат IPv4 — перекриття було прийнятим побічним ефектом, а не багом.
• NAT набув поширення в середині 1990-х як практична відповідь на брак IPv4; це також нормалізувало ідею «переписувати адреси» в транзиті.
• CGNAT (Carrier-Grade NAT) популяризував використання 100.64.0.0/10 як спільного простору; підприємства тепер часто позичають його внутрішньо для трансляції, бо він менш ймовірно конфліктує з домашніми роутерами.
• Концепції VRF дозріли разом із MPLS VPN; та сама механіка, що ізолює клієнтів у провайдерів, ізолює перекриваючихся орендарів у підприємствах.
• Route-based VPN (інтерфейси + маршрути) стали домінувати над policy-based VPN, бо краще масштабуются, але перекриття все одно вимагає виправлення простору імен.
• EVPN/VXLAN оверлеї з’явилися, щоб вирішити проблеми масштабування мульти-орендарних дата-центрів; ті самі підходи зараз застосовуються в кампусах і філіях.
• Split-horizon DNS десятиліттями був стандартним трюком в корпоративних мережах, але стає обов’язковим, коли трансльовані/оверлей-адреси відрізняються по сайтах.
• Великі підприємства регулярно оперують кількома IP «реальностями» під час злиттів: початковий адресний простір, трансляційний інтеграційний простір і майбутній перенумерований стан — часто одночасно.

Питання й відповіді

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

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

2) Чи завжди NAT — найшвидше виправлення?

Зазвичай так — особливо для обмеженого набору сервісів. Але «швидко» не означає «безкоштовно». NAT додає стан трансляції, складність політик і ускладнює діагностику. Якщо ви плануєте глибоку інтеграцію (AD, багато east-west), подумайте про VRF/оверлей якомога раніше.

3) Який діапазон трансляції слід використовувати?

Виберіть діапазон, який малоймовірно зустрічається в жодній компанії і зарезервуйте його централізовано. Багато команд використовують 100.64.0.0/10 для трансляції/оверлею, бо він менш поширений у локальних LAN, ніж 10/8. Ключ — управління: зарезервуйте, документуйте і тримайте його поза DHCP-діапазонами.

4) Чи потрібен двосторонній NAT?

Якщо обидві сторони ініціюють з’єднання до одного й того ж сервісу — так, плануйте симетричний DNAT/SNAT, щоб шляхи повернення були консистентними. Для односпрямованого «клієнт→сервер» SNAT може бути достатнім, але треба гарантувати, що відповіді повертаються через транслятор.

5) Чи VRF може вирішити перекриття без NAT?

VRF перешкоджає колізіям, ізолюючи домени маршрутизації, але не дозволяє двом однаковим адресам напряму спілкуватись. Якщо VRF-A має дістатися хоста в VRF-B, який має ту ж IP, що й хтось у VRF-A, вам все одно потрібна трансляція або проксі.

6) Який найбільший ризик з оверлеями?

MTU та операційна складність. Інкапсуляція зменшує ефективний MTU; якщо PMTUD ламається, додатки падають дивно. Також оверлеї додають контрольну площину, яку потрібно моніторити й розуміти.

7) Як утримати DNS у консистентному стані під час цього?

Визначте, які імена мають резолвитись у трансльовані/оверлей-адреси, і застосуйте split-horizon DNS. Тримайте короткі TTL під час міграції. А також проведіть аудит на наявність жорстко прописаних IP — вони будуть.

8) Якщо лише кілька користувачів потребують доступу між сайтами — що робити?

Використайте jump host або application proxy у нейтральному, неперекривному сегменті (або оверлеї). Це обмежить площу ураження і зменшить кількість трансльованих потоків. Не відкривайте весь адресний простір «бо так простіше».

9) Чи це вплине на бекапи та реплікацію?

Так, і іноді несподівано. Інструменти реплікації можуть прив’язуватись до IP, накладати allowlist-джерела або працювати некоректно під NAT, якщо вони вбудовують адреси. Тестуйте з реальними розмірами передач і вимірюйте пропускну здатність та помилки перед тим, як оголосити перемогу.

10) Чи варто все одно планувати перенумерацію у майбутньому?

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

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

Перекриття підмереж не рідкість; це типовий результат децентралізованого IT, RFC1918 та часу. Важливо те, як ви на це реагуєте. Якщо ви вдаєте, що це «лише проблема маршрутизації», ви витратите дні на доведення тієї ж помилки різними способами.

Зробіть це далі:

1. Запустіть швидку діагностику: ARP/route/traceroute, щоб довести перекриття та визначити важливі потоки.
2. Обирайте рішення свідомо:
   • NAT — для швидкого доступу до сервісів.
   • VRF — для ізоляції та контрольованого доступу до спільних сервісів.
   • Оверлей — для масштабованої, довгострокової інтеграції.
3. Зарезервуйте інтеграційний адресний простір (для трансляції/оверлею), документуйте його і захистіть від випадкового повторного використання.
4. Інструментуйте з першого дня: не лише «тунель вгору», а й проби додатків, перевірки MTU і packet-capture, які ви можете відтворити.
5. Напишіть runbook, поки біль свіжий. Майбутній ви буде втомленим і байдужим.

Якщо потрібно обрати один підхід для більшості реальних корпоративних злиттів: почніть з детермінованого NAT для критичних сервісів, а потім переходьте на VRF/оверлей по мірі того, як ви розумієте, що означає «інтеграція» у вашому середовищі.