VPN між офісами і DHCP: як уникнути конфліктів IP і хаосу

Ментальна модель: що насправді ламається, коли ви з’єднуєте офіси

Site-to-site VPN — це не магія. Це трубопровід. Трубопроводи не узгоджують семантику; вони пересилають пакети. Хаос починається,
коли в тих пакетах є припущення, які здавалися нормальними в ізоляції:

• Припущення №1: «192.168.1.0/24 означає мій офіс.» Після VPN воно може означати «обидва офіси». Це не значення — це колізія.
• Припущення №2: DHCP — «локальний і нешкідливий». Ні. DHCP — це контрольна площина для ідентичності (IP), маршрутизації (дефолтний шлюз) і розв’язування імен (DNS).
• Припущення №3: широкомовні механізми виявлення працюватимуть між офісами. Ні, якщо ви навмисно не містите L2, а мостити — це імпорт усіх L2‑проблем у ваш L3‑світ.
• Припущення №4: «VPN повільний», коли маршрут неправильний, DNS дає подвійні відповіді, або MTU тихо пожирає ваші пакети.

VPN змінює домен відмов. Тепер опечатка в одному офісі ламає обидва. Неправильний DHCP‑сервер в одному офісі отримує більшу площу полювання
(залежно від мостування/релєїв). А налагодження ускладнюється, бо симптоми проявляються далеко від причин.

Якщо потрібна одна фраза для керівництва дизайном, використайте цю:
Тримайте кожен офіс як незалежний L3‑домен, з’єднуйте їх маршрутизацією і центризуйте лише те, що ви можете моніторити й обмежувати.

Цитата, яку варто приклеїти для роботи з VPN і DHCP: Надія — не стратегія. — Gene Kranz.
Так, це з центру керування місіями, а не з мереж; суть лишається.

Жарт №1: Site-to-site VPN як шлюб: він не вирішує проблеми комунікації, він просто робить їх голоснішими.

Цікавинки та історичний контекст (бо історія повторюється)

1. RFC 1918 (1996) дав нам приватні IPv4‑діапазони (10/8, 172.16/12, 192.168/16). Це вирішило нестачу адрес і породило сучасний спорт — накладання підмереж.
2. DHCP став стандартом на початку 1990‑х (як еволюція BOOTP). Його проєктували для LAN з використанням широкомовлення; «через WAN» історія з’явилася пізніше через релєї.
3. Широкомовні домени завжди були межею масштабування. Ранні кампуси швидко зрозуміли, що L2‑спролл перетворює «один поганий пристрій» в «таємницю по всій компанії».
4. IPsec (кінець 1990‑х) мав на меті захищати IP на рівні L3. Багато впроваджень випадково будують над ним L2‑поведінку і потім платять за це.
5. NAT не призначався бути вічним. Це був практичний хак для виснаження IPv4. Він досі тут і досі порушує припущення end‑to‑end та ускладнює налагодження.
6. Split DNS виник через те, що реальність неоднорідна. Ідея різних відповідей залежно від точки запиту старша за багато «cloud‑native» команд.
7. «VPN повільний» став тропом через проблеми з MTU. Історія PMTUD‑чорних ям довга і повна втрат пакетів.
8. Набори опцій DHCP стали де‑факто системою конфігурації. Телефони, PXE‑запуск, принтери та контролери Wi‑Fi чекають специфічних опцій, тож помилки DHCP викликають дивні специфічні збої.
9. BGP поверх IPsec тепер поширений для динамічної маршрутизації між сайтами, але він працює добре лише коли ваш план адресації спочатку має сенс.

Стратегія IP‑адресації: частина, яку потрібно вирішити наперед

Правило 1: ніколи не допускайте перекриття підмереж між сайтами

Якщо Офіс A і Офіс B обидва використовують 192.168.1.0/24, у вас не «проблема VPN». У вас проблема ідентичності.
Таблиця маршрутизації не може відрізнити «192.168.1.50 в Офісі A» від «192.168.1.50 в Офісі B». Ви побачите:
асиметричну маршрутизацію, дивні ARP‑поведінки при мостуванні і переривчасту доступність, якщо хтось додасть NAT як пластир.

Моя категорична думка: перенумеруйте один сайт, якщо у вас немає короткотермінової бізнес‑потреби використовувати NAT як тимчасовий міст.
NAT іноді необхідний, але ніколи не є чистим кінцевим станом.

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

Оберіть приватний діапазон, достатній для зростання, потім розрізайте по сайту й функції. Один простий шаблон:

• 10.64.0.0/10 зарезервовано для корпоративних внутрішніх мереж.
• Кожному офісу давайте /16: Офіс A = 10.64.0.0/16, Офіс B = 10.65.0.0/16 тощо.
• В середині /16 виділіть /24: користувачі, сервери, голос, принтери, Wi‑Fi, гостьова, management.

Чому /16 на сайт? Бо перенумерація дорога, і люди недооцінюють зростання та «тимчасові» мережі.
Це також робить маршрути простими та підсумовуваними.

Правило 3: вирішіть, де знаходиться дефолтний шлюз для кожного VLAN

Якщо у вас є маршрутизатор/фаєрвол на кожному сайті, тримайте дефолтні шлюзи локальними. Віддалений дефолтний шлюз через VPN перетворює кожен
пакет на WAN‑трафік. Користувачі це помітять. Ваш інцидентний список помітить більше.

Правило 4: документуйте авторитетне джерело правди

Потрібен мінімальний підхід IPAM, навіть якщо це «Git‑репо з YAML». Важливо, щоб існувало одне місце,
де записані підмережі, DHCP‑діапазони, резервації та ключові статичні адреси і де це переглядають.

Моделі DHCP через VPN (і чому більшість — погані)

Модель A: DHCP залишається локальним у кожному офісі (рекомендовано)

Кожен сайт запускає власний DHCP‑сервер (або HA‑пару) для своїх локальних підмереж. VPN лише несе маршрутизований трафік.
Це найпростіший домен відмов: якщо DHCP‑сервер Сайту B помре, Сайт A не постраждає.

Централізуйте DNS, якщо хочете. Централізуйте автентифікацію, якщо потрібно. Але тримайте DHCP поруч із клієнтами, якщо немає сильних операційних причин інакше.

Модель B: центральний DHCP‑сервер із DHCP‑релє на кожному сайті (працює, але вимагає дисципліни)

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

Якщо обираєте це, встановіть довші часи оренди для віддалених сайтів і переконайтеся, що Relay Agent Information (Option 82)
або використовується навмисно, або послідовно відключений. Несумісність опцій робить налагодження моторошним.

Модель C: містити L2 через VPN (не робіть цього, якщо не любите болю)

Мостування означає, що DHCP‑широкомовлення проходить VPN, ARP проходить VPN, і кожне «хто має» стає крос‑сайтовою розмовою. Це погіршує
безпеку і стабільність. Воно може виправдатися для нішових випадків (легасі‑протоколи, дуже малі мережі, короткі міграції), але має мати
чіткий план виходу.

Модель D: NAT, щоб сховати перекриття (прийнятно як тимчасовий вихід)

Коли підмережі перекриваються і ви не можете одразу перенумерувати, можна NAT‑ити одну сторону, щоб інша бачила транслітований діапазон.
Воно «працює» у сенсі пересилки пакетів. Воно провалюється у сенсі ідентичності: логи брешуть, ACL стають незручними, і все, що вбудовує IPи
(деякі VoIP, ліцензійні системи, старий SMB), може зламатися.

Жарт №2: NAT — як підмітати бруд під килим — вражає, поки ви не спіткнетеся об килим.

Проєктування діапазонів DHCP: уникайте прихованих пасток

• Зарезервуйте діапазони для статичних адрес (мережеве обладнання, сервери, гіпервізори). Не «просто візьми щось поза пулом» без документації.
• Використовуйте DHCP‑резервації для принтерів та спеціальних кінцевих пристроїв. Випадкові IP‑адреси принтера — як квитки в нескінченну чергу.
• Стандартизуйте набори опцій (сервери DNS, пошукові домени, NTP). Якщо кілька DHCP‑серверів — синхронізуйте опції через конфігураційний менеджмент.
• Тримайте час оренд розумним: 8–24 години для користувацьких мереж, довше для стабільних пристроїв. Дуже короткі оренди створюють зайвий рух під час WAN‑нестабільності.

Маршрутизація, NAT і чому «просто зробіть NAT» — пастка

Статичні маршрути проти динамічної маршрутизації

Для двох офісів з кількома підмережами статичні маршрути підходять. Додайте третій сайт, або багато VLAN на сайті,
й статичні маршрути перетворюються на податок за зміну. Тоді варто розглянути:

• OSPF для внутрішньої маршрутизації, якщо ви контролюєте обидва кінці і хочете швидку конвергенцію.
• BGP якщо потрібен явний контроль маршрутів і чисте підсумовування через тунелі.

Динамічна маршрутизація — не «показник ентерпрайзу». Це спосіб не забути маршрут під час стресової міграції.

Split tunneling проти повної сітки

Не направляйте інтернет‑трафік через VPN «через безпеку», якщо ви не готові платити за це продуктивністю.
Це політичний вибір з витратами на продуктивність. Якщо робите так, робіть свідомо: вміруйте канали, налаштуйте MTU, моніторте,
і прийміть, що голос/відео будуть скаржитися першими.

MTU: тихий саботажник

IPsec додає оверхед. GRE додає оверхед. WireGuard додає оверхед. Якщо не підганяти MTU або не обмежити MSS, отримаєте
фрагментацію і PMTUD‑проблеми. Класичний симптом: малі ping‑и працюють, великі передачі зависають, і HTTPS іноді таймаутиться випадково.

Межі безпеки

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

Три короткі історії з корпоративного життя

Коротка історія 1: інцидент через хибне припущення

Середня компанія придбала меншу фірму і поспішила «з’єднати офіси», щоб фінанси могли дістатися ERP.
Мережеві діаграми виглядали чисто. VPN піднявся з першого разу. Усі подякували команді і повернулися до календарів.

Через кілька годин служба підтримки отримала тікети: принтери в придбаному офісі були «онлайн», потім «офлайн», знову «онлайн».
VoIP‑телефони перезавантажувалися випадково. Деякі ноутбуки могли дістатися внутрішніх систем; інші — ні. VPN звинуватили.

Хибне припущення було простим: обидві сторони використовували 192.168.0.0/24 для основної LAN, бо так завжди робили.
Маршрутні таблиці на обох фаєрволах мали однакові connected‑мережі. Тому кожна сторона вірила, що 192.168.0.50 — це локально.
Пакети навіть не потрапляли в тунель. Люди пробували додавати статичні маршрути (що не допомагало) і крутити IPsec‑таймінги (що теж не допомагало).

Виправлення було не гламурним: перенумерувати придбаний офіс на унікальну підмережу, потім оновити DHCP‑скопи, конфігурації принтерів
і кілька статичних пристроїв. Під час переходу використовували тимчасовий NAT для критичних систем.
Коли перенумерація завершилась, «нестабільність VPN» зникла за одну ніч.

Урок: тунель — не ваш шар ідентичності. IP‑адресація — це ваша ідентичність. Ставтеся до неї відповідально.

Коротка історія 2: оптимізація, що відвернулася боком

Інша організація захотіла «спростити управління» через централізацію DHCP у головному дата‑центрі. Віддалений офіс мав лише релє.
Здавалося чистим рішенням: одна конфігурація скопу, одне місце для аудиту опцій, один процес змін.

Потім WAN‑провайдер мав важкий тиждень. Короткі провали — 30 секунд тут, дві хвилини там. Нічого, щоб оголошувати повний аутпейдж.
Але достатньо, щоб усе дратувало.

Не те, що постраждали вже існуючі клієнти; постраждав рух. Телефони перезавантажувалися після стробів електроживлення, ноутбуки перемикалися між SSID,
Wi‑Fi‑клієнти намагалися оновити оренду. Релє не могли дістатися центрального DHCP під час провалів. Клієнти падали на APIPA або тримали старі оренди,
що не відповідали DNS. Людям здавалося, що «Wi‑Fi нестабільний», бо так це відчувалося.

Вони «оптимізували» ще більше, скоротивши час оренди для ефективності повторного використання IP. Це збільшило частоту оновлень,
що підвищило залежність від нестабільного WAN. Команда створила високочастотну машину відмов і потім дивувалася.

Виправлення: повернути DHCP на місце (або додати локальний failover), збільшити час оренди і ставитися до централізації як до інструмента,
що вимагає надійності. Централізуйте, коли канал стабільний як електропостачання. Інакше — тримайте DHCP локально.

Коротка історія 3: нудна, але правильна практика, що врятувала день

Регульована компанія мала політику, яка здавалась бюрократичною: кожне виділення підмережі потрапляло в IPAM‑таблицю, підкріплену Git‑репо,
і переглядалося двома людьми. Зміни DHCP вимагали короткого тикету і чек‑ліста валідації до/після. Ніхто це не любив. Усі виконували через аудит.

Під час поспішного переселення підрядник встановив «тимчасовий» маршрутизатор з увімкненим DHCP на лабораторному столі. У багатьох місцях це
перетворилося б на дво‑денний аутпейдж. Тут це було 20‑хвилинне незручність.

Інженер на виклику дотримався чек‑ліста: перевірив DHCP‑offers, визначив IP сервера, знайшов порт комутатора через MAC‑таблицю,
відключив порт, потім перевірив оновлення на тестовому клієнті. IPAM‑запис показав, які скопи легітимні, а які ні. Історія змін показала плановану зміну,
яка ще не була застосована, що уникнуло другої помилки.

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

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

Коли «VPN + DHCP» йде не так, можна витратити години на здогадки. Не робіть цього. Тріажуйте як слід.
Ваша мета — швидко знайти клас вузького місця: перекриття адрес, маршрутизація, авторитет DHCP, DNS або MTU.

Перше: підтвердіть, чи є перекриття мереж

• Порівняйте локальні LAN сайту з віддаленими LAN. Якщо є перекриття — зупиніться й плануйте виправлення або NAT.
• Перевірте маршрути: якщо той самий префікс існує як «connected» на обох кінцях, у вас дизайнерський конфлікт.

Друге: підтвердіть симетрію маршрутів і політику фаєрволу

• Чи може Сайт A дістатися інтерфейсу маршрутизатора Сайту B? Чи може Сайт B дістатися інтерфейсу Сайту A?
• Чи існують шляхи повернення? Чи дозволяє політика трафік в обох напрямках?
• Перевірте на асиметричні NAT‑правила, що змінюють лише один напрямок.

Третє: вирішіть, чи це DHCP, DNS чи MTU

• Проблема DHCP, якщо клієнти отримують неправильний шлюз/DNS, попередження про дубльовані IP або APIPA‑адреси.
• Проблема DNS, якщо пінг по IP працює, але імена не працюють, або внутрішні імена резолвляться в публічні/невірні цілі.
• Проблема MTU, якщо малі пінги працюють, великі пакети падають, і HTTPS/SMB поводяться нестабільно.

Четверте: захопіть пакети у потрібному місці

Захоплення на клієнті добре. Захоплення на інтерфейсі маршрутизатора, що виходить в LAN, краще.
Захоплення на тунельному інтерфейсі — найкраще, коли потрібно довести, що пройшло через VPN.

Практичні завдання з командами (що запускати, що це означає, що вирішувати)

Ці завдання наведені для прикладу на Linux‑маршрутизаторах/серверах. Ідеї прямо переносяться на pfSense/OPNsense, Windows DHCP
і керовані фаєрволи; суть — що ви перевіряєте і навіщо.

Завдання 1: покажіть локальні інтерфейси і підмережі (знайдіть очевидні перекриття)

cr0x@server:~$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             10.64.10.2/24
eth1             UP             10.64.20.1/24

Що це означає: хост прямо підключений до 10.64.10.0/24 і 10.64.20.0/24.
Рішення: порівняйте ці префікси з префіксами віддаленого офісу. Якщо є перекриття — ви в режимі ремедіації, а не налаштування.

Завдання 2: перевірте таблицю маршрутів (доведіть, куди підуть пакети)

cr0x@server:~$ ip route
default via 10.64.10.1 dev eth0
10.64.10.0/24 dev eth0 proto kernel scope link src 10.64.10.2
10.64.20.0/24 dev eth1 proto kernel scope link src 10.64.20.1
10.65.0.0/16 via 10.64.10.254 dev eth0

Що це означає: трафік до 10.65.0.0/16 (віддалений офіс) йде через 10.64.10.254 (ймовірно VPN‑маршрутизатор).
Рішення: якщо віддалені мережі відсутні тут, додайте маршрути (статичні або динамічні). Якщо ви бачите більш специфічний маршрут, що вказує кудись іще, вирішіть цей конфлікт спочатку.

Завдання 3: перевірте стан тунелю (не налагоджуйте DHCP через вимкнений тунель)

cr0x@server:~$ sudo wg show
interface: wg0
  public key: 2lQf...redacted...
  listening port: 51820

peer: 3mHf...redacted...
  endpoint: 203.0.113.10:51820
  allowed ips: 10.65.0.0/16
  latest handshake: 42 seconds ago
  transfer: 1.23 GiB received, 980 MiB sent

Що це означає: WireGuard піднятий і обмінюється трафіком нещодавно.
Рішення: якщо handshakes застарілі, виправте тунель спочатку (ключі, фаєрвол, NAT, досяжність). Ніяка логіка DHCP не працюватиме, поки пакети не течуть.

Завдання 4: протестуйте досяжність і шлях (підтвердіть маршрути та ACL)

cr0x@server:~$ ping -c 3 10.65.10.1
PING 10.65.10.1 (10.65.10.1) 56(84) bytes of data.
64 bytes from 10.65.10.1: icmp_seq=1 ttl=63 time=22.1 ms
64 bytes from 10.65.10.1: icmp_seq=2 ttl=63 time=21.7 ms
64 bytes from 10.65.10.1: icmp_seq=3 ttl=63 time=22.4 ms

--- 10.65.10.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms

Що це означає: існує L3‑з’єднання принаймні до віддаленого шлюзу.
Рішення: якщо ping падає — перевірте маршрути і фаєрвол. Якщо ping працює, але застосунки не працюють — ймовірно DNS, MTU або фільтрація портів.

Завдання 5: протестуйте MTU з ping без фрагментації (знайдіть чорну діру)

cr0x@server:~$ ping -M do -s 1472 -c 2 10.65.10.1
PING 10.65.10.1 (10.65.10.1) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1420

--- 10.65.10.1 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1026ms

Що це означає: ефективний MTU на шляху менший за 1500; 1420 поширений для WireGuard.
Рішення: обмежте TCP MSS на тунелі або встановіть відповідний MTU на інтерфейсах. Інакше ви будете нескінченно «налагоджувати» flaky SMB/HTTPS.

Завдання 6: покажіть оренди DHCP на Linux‑сервері DHCP (перевірте поведінку скопа)

cr0x@server:~$ sudo tail -n 8 /var/lib/dhcp/dhcpd.leases
lease 10.64.10.101 {
  starts 5 2025/12/27 10:22:10;
  ends 5 2025/12/27 22:22:10;
  cltt 5 2025/12/27 10:22:10;
  binding state active;
  hardware ethernet 3c:52:82:aa:bb:cc;
  client-hostname "laptop-hr";
}

Що це означає: сервер видає адреси у очікуваній підмережі відомому MAC.
Рішення: якщо оренди показують адреси з неправильного скопа або несподіваних підмереж — ви неправильно налаштували скопи або релє (або у вас є rogue DHCP‑сервер деінде).

Завдання 7: слухайте DHCP‑повідомлення (виявляйте rogue DHCP і неправильні релє)

cr0x@server:~$ sudo tcpdump -ni eth0 -vvv 'port 67 or port 68' -c 6
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:31:00.102345 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 3c:52:82:aa:bb:cc, length 300
10:31:00.105210 IP 10.64.10.5.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300, yiaddr 10.64.10.101, Server-ID 10.64.10.5
10:31:00.106901 IP 10.64.10.250.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300, yiaddr 10.64.10.199, Server-ID 10.64.10.250

Що це означає: два різні DHCP‑сервери пропонують оренди (10.64.10.5 і 10.64.10.250).
Рішення: знайдіть і відключіть rogue‑сервер або ізолюйте його. У сценарії багатосайтного VPN переконайтеся, що ви випадково не мостили L2 або не релєли DHCP там, де не треба.

Завдання 8: перевірте, чи налаштовано DHCP‑релє (і куди він форвардить)

cr0x@server:~$ ps aux | grep -E 'dhcrelay|isc-dhcrelay' | grep -v grep
root      1123  0.0  0.1  18720  4120 ?        Ss   10:01   0:00 /usr/sbin/dhcrelay -4 -i eth1 10.64.10.5

Що це означає: ця машина релєє DHCP‑запити з інтерфейсу eth1 до DHCP‑сервера 10.64.10.5.
Рішення: якщо той сервер знаходиться через VPN, упевніться, що релє має стабільну маршрутизацію, фаєрвол дозволяє UDP 67/68, і часи оренд підходять для залежності від WAN.

Завдання 9: перевірте розв’язування DNS з віддаленого сайту (відокремте DNS від маршрутизації)

cr0x@server:~$ resolvectl status | sed -n '1,25p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.64.20.10
       DNS Servers: 10.64.20.10 10.64.20.11
        DNS Domain: corp.example

Link 2 (eth0)
Current Scopes: DNS

Що це означає: система використовує внутрішні DNS‑сервери (10.64.20.10/.11).
Рішення: якщо клієнт віддаленого офісу вказує на DNS, до якого він не може дістатися (через відсутні маршрути або фаєрвол), DHCP «працює», але дає непридатну конфігурацію. Виправляйте DHCP‑опції або маршрути.

Завдання 10: доведіть розв’язування імен проти доступності (припиніть звинувачувати VPN за DNS)

cr0x@server:~$ getent hosts fileserver.corp.example
10.65.20.20     fileserver.corp.example

Що це означає: DNS (або NSS) резолвить ім’я у віддалену IP.
Рішення: якщо резолв ламається, але IP‑пінг працює — потрібно виправляти DNS (форвардери, split‑horizon, пошукові домени або DHCP‑опція 15/6). Якщо резолв працює, але з’єднання не працює — це маршрутизація/фаєрвол/MTU.

Завдання 11: трасуйте маршрут (знайдіть асиметричні або несподівані хопи)

cr0x@server:~$ tracepath 10.65.20.20
 1?: [LOCALHOST]                                         pmtu 1500
 1:  10.64.10.254                                          1.012ms
 2:  10.65.0.1                                            22.104ms
 3:  10.65.20.20                                          23.001ms reached
     Resume: pmtu 1420 hops 3 back 3

Що це означає: трафік проходить VPN‑маршрутизатор і досягає призначення; PMTU — 1420.
Рішення: якщо список хопів показує інтернет‑херпінг або несподіваний маршрутизатор, виправте маршрути. Якщо PMTU низький і аплікації ламаються — обмежте MSS.

Завдання 12: перевірте лічильники фаєрволу на скиданий трафік (доведіть питання політики)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,80p'
table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    ct state established,related accept
    iifname "wg0" oifname "eth1" ip saddr 10.65.0.0/16 ip daddr 10.64.20.0/24 accept
    counter packets 0 bytes 0 drop
  }
}

Що це означає: політика forward за замовчуванням — drop; дозволений лише конкретний wg0→eth1 потік. Існує лічильник drop.
Рішення: якщо лічильники показують дропи для очікуваних потоків, коригуйте політику свідомо. Якщо ви «тимчасово дозволили все» для тесту — не забудьте відкотити; тимчасові правила часто стають постійною архітектурою.

Завдання 13: виявляйте дублікати IP з кінцевої точки (ARP підкаже)

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

Що це означає: IP зараз відображається на один MAC.
Рішення: якщо MAC часто змінюється без переміщення пристрою, можливо IP конфлікти або rogue DHCP. Корелюйте з DHCP‑логами і MAC‑таблицями комутаторів.

Завдання 14: знайдіть порт комутатора для підозрілого MAC (знайдіть rogue‑пристрій)

cr0x@server:~$ ssh admin@switch-a01 "show mac address-table address 3c:52:82:aa:bb:cc"
Mac Address Table
-------------------------------------------
Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
  10    3c:52:82:aa:bb:cc DYNAMIC     Gi1/0/24

Що це означає: MAC навчено на порту Gi1/0/24 у VLAN 10.
Рішення: якщо цей порт веде до неуправляємого комутатора або «тимчасового» маршрутизатора — вимкніть його або перемістіть у ізольований VLAN. Потім повторіть тест DHCP‑offers.

Завдання 15: перевірте ідентичність DHCP‑сервера з Windows‑клієнта (звично в офісах)

cr0x@server:~$ ssh user@winclient "ipconfig /all | findstr /I \"DHCP Server IPv4 Address\""
   DHCP Server . . . . . . . . . . . : 10.64.10.5
   IPv4 Address. . . . . . . . . . . : 10.64.10.101

Що це означає: клієнт отримує оренду від 10.64.10.5.
Рішення: якщо DHCP‑сервер змінюється між оновленнями — у вас кілька DHCP‑відповідачів. Це проблема локалізації, а не «налагодження VPN».

Завдання 16: підтвердіть опції DHCP, що доставлені (помилки шлюзу/DNS виглядають як відмови VPN)

cr0x@server:~$ sudo dhclient -v -1 eth0
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
DHCPOFFER of 10.64.10.120 from 10.64.10.5
DHCPREQUEST for 10.64.10.120 on eth0 to 255.255.255.255 port 67
DHCPACK of 10.64.10.120 from 10.64.10.5
bound to 10.64.10.120 -- renewal in 36000 seconds.

Що це означає: переговори DHCP пройшли успішно.
Рішення: перевірте застосовані маршрути і resolv.conf після цього. Якщо шлюз вказує на віддалений сайт через VPN випадково, виправте опції скопа; не звинувачуйте тунель за те, що він робить те, що ви йому наказали.

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

1) «Деякі користувачі можуть дістатися віддаленого офісу, а деякі — ні»

• Симптом: переривчастий доступ; один стіл працює, інший — ні; перезавантаження «тимчасово вирішує».
• Корінна причина: перекриття підмереж або кілька DHCP‑серверів, що призначають різні шлюзи/DNS.
• Виправлення: усунути перекриття, перенумерувавши; знімати DHCP‑offers; відключити rogue‑DHCP; стандартизувати опції скопа.

2) «VPN піднятий, але нічого не маршрутизується»

• Симптом: тунель показує connected/handshake OK, але віддалені підмережі недосяжні.
• Корінна причина: відсутні маршрути (або відсутні allowed IP в WireGuard), або політика форварду фаєрволу блокує.
• Виправлення: додайте явні маршрути з обох сторін; перевірте forward/NAT‑правила; підтвердіть симетрію шляху за допомогою tracepath.

3) «DNS працює локально, але падає з іншого офісу»

• Симптом: пінг по IP працює; імена таймаутять; або резолвяться в неправильні цілі.
• Корінна причина: DHCP дає недосяжні DNS‑сервери; split‑DNS неправильно налаштований; фаєрвол блокує TCP/UDP 53 через VPN.
• Виправлення: переконайтеся, що віддалі сайти можуть дістатися DNS; додайте локальні кешуючі резолвери при потребі; дозволіть DNS через VPN; перевірте getent/dig.

4) «SMB/HTTPS нестабільні, але ping працює»

• Симптом: копіювання файлів зависає; веб‑додатки частково завантажуються; RDP іноді підвисає.
• Корінна причина: MTU/PMTUD‑чорна діра; відсутнє MSS‑clamping.
• Виправлення: обмежте TCP MSS на тунелі; встановіть MTU інтерфейсу відповідно; повторно протестуйте ping -M do і tracepath PMTU.

5) «Після підключення VPN принтери почали дублюватися або змінювати IP»

• Симптом: IP‑адреси принтерів змінюються; черги друку ламаються; з’являються попередження про дублікати IP.
• Корінна причина: принтер на DHCP з давно запам’ятаною статичною конфігурацією; обидва сайти використовують ту саму підмережу принтерів; або не використано DHCP‑резервації.
• Виправлення: зарезервуйте MAC‑адреси принтерів; тримайте принтери в виділеному VLAN на кожному сайті; уникайте перекритих підмереж принтерів; документуйте статичні адреси в IPAM.

6) «Гостьовий Wi‑Fi бачить корпоративні ресурси після проєкту VPN»

• Симптом: гостьові клієнти дісталися внутрішніх IP або сервісів.
• Корінна причина: надто широкі домени шифрування VPN/allowed IP; політики фаєрволу не сегментовані; маршрути протікають між VRF/VLAN.
• Виправлення: обмежте VPN‑селектора/allowed IP до потрібних підмереж; застосуйте між‑VLAN політики; явно заблокуйте guest→corp через тунель.

7) «Під час WAN‑падінь все ламається, а потім повільно відновлюється»

• Симптом: після коротких провалів багато кінцевих точок втрачають доступ; відновлення займає години.
• Корінна причина: централізований DHCP залежить від WAN; короткі часи оренди; залежність від віддалених DNS без локального кеша.
• Виправлення: тримайте DHCP локально або додайте локальний failover; подовжіть оренди; розгорніть локальні кешуючі резолвери; ставтеся до WAN як до ненадійного, поки не доведено протилежне.

8) «Ми виправили перекриття NAT, тепер логи і ACL дивні»

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

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

Покроково: проєктування нового VPN між офісами без майбутніх жалів

1. Інвентаризація підмереж на обох сайтах. Перерахуйте кожен VLAN/підмережу, включно з гостьовим Wi‑Fi, голосом, принтерами, management і «тимчасовими» лабораторними мережами.
2. Оберіть консистентний план адресації. Виділіть при можливості як мінімум /16 на сайт. Запишіть це в ваше джерело правди.
3. Визначте, що має бути досяжним. Матриця підмереж: хто з ким має спілкуватися і на яких портах. За замовчуванням deny, потім дозволяйте свідомо.
4. Оберіть модель DHCP. Віддавайте перевагу локальному DHCP на кожному сайті. Якщо централізуєте — дотримуйтесь релє‑конфігурації, моніторингу і довших оренд.
5. Вирішіть архітектуру DNS. Центральні резолвери прийнятні, якщо досяжні; інакше використовуйте локальні кеші, що форвардять в центр. Плануйте split DNS для внутрішніх зон.
6. Оберіть стратегію маршрутизації. Статичні маршрути — для малого і стабільного. Динамічна маршрутизація — коли зростання або часті зміни.
7. Проінженеруйте MTU наперед. Встановіть MTU/MSS clamping на тунелі на ранньому етапі. Перевірте do‑not‑fragment тести.
8. Заблокуйте VPN селектори/allowed IP. Розголошуйте лише ті внутрішні префікси, які плануєте маршрутизувати. Жодного «0.0.0.0/0 бо так працювало».
9. Моніторинг і логи. Стан тунелю, підняття/падіння, латентність, втрата пакетів, здоров’я DHCP‑серверів, затримка DNS, відмови фаєрволу. Якщо не бачите — не оперуєте.
10. Прогон перед вирізкою. План тестування перед «включенням»: оренда DHCP, розв’язування DNS, доступ до ключових сервісів, та тест передачі файлу (SMB/HTTPS) для виявлення MTU.

Покроково: коли у вас вже є перекриття підмереж

1. Підтвердіть перекриття і визначте мінімальний радіус ураження. Які префікси перекриваються? Які системи мають спілкуватися зараз?
2. Оберіть шлях ремедіації:
   • Найкращий: перенумерація одного сайту (або хоча б тих підмереж, що потребують крос‑сайтової зв’язності).
   • Тимчасовий: NAT однієї сторони на неперекривний трансляційний діапазон.
   • Уникайте: мостити, щоб «зробити одну LAN». Це злиття широкомовних доменів, а не рішення.
3. Якщо перенумерація: створіть нові DHCP‑скопи, оновіть шлюзи, DNS і резервації; мігруйте VLAN по VLAN; майте план відкату.
4. Якщо NAT: логируйте трансляції, документуйте відображення і встановіть кінцеву дату. Перевірте додатки, що залежать від IP‑джерела.
5. Після ремедіації: видаліть тимчасовий NAT/правила, затягніть фаєрвол, оновіть IPAM/джерело правди.

Операційний чек‑ліст: запобігання DHCP‑хаосу

• Увімкніть DHCP snooping на access‑комутаторах, де доступно, і довіряйте лише uplink‑портам до реальних DHCP‑серверів/релє.
• Тримайте DHCP‑сервери авторитетними для своїх скопів; уникайте дублів скопів у різних місцях, якщо немає справжнього failover.
• Стандартизуйте опції DHCP і версіонуйте конфігурації.
• Використовуйте резервації для «напів‑статичних» пристроїв (принтери, телефони, кардридери).
• Проводьте аудит на предмет rogue DHCP щоквартально (або після переселень офісу).
• Моніторте виснаження пулу і сповіщайте до того, як пул закінчиться.

FAQ

1) Чи можу я запускати один DHCP‑сервер для обох офісів через VPN?

Так, через DHCP‑релє. Але ви переносите критичну контрольну площину на WAN. Якщо WAN не надзвичайно стабільний,
тримайте DHCP локально або розгорніть локальний failover.

2) Чому DHCP не може «просто перейти через VPN» природно?

DHCP використовує широкомовлення для виявлення в LAN. Рутовані VPN‑лінки не переносять широкомовлення. Потрібен релє або міст,
а мостування зазвичай — неправильний компроміс.

3) Яке найчистіше виправлення для перекриття підмереж?

Перенумерація однієї сторони на унікальний префікс. Це робота, але дає коректність. NAT прийнятний як тимчасова міграція,
але не як постійна архітектура.

4) Якщо ми мусимо NAT‑ити, на що звернути увагу?

Логування і контроль доступу втрачають гранулярність, деякі додатки вбудовують IP‑адреси, і налагодження ускладнюється, бо в пакетах видно
трансльовані ідентичності. Документуйте відображення і плануйте видалення.

5) Чому малі пінги працюють, а передачі файлів падають через VPN?

Класична проблема MTU/PMTUD. Інкапсуляція зменшує ефективний MTU. Без MSS‑clamping або коректних MTU налаштувань більші пакети падають,
і TCP стоїть, що виглядає як «випадкова повільність».

6) Як швидко виявити rogue DHCP‑сервер?

Зробіть packet capture для DHCP‑offers на проблемному VLAN і дивіться на різні Server‑ID. Потім знайдіть MAC у MAC‑таблиці комутатора
і закрийте/ізолюйте порт.

7) Чи повинні обидва офіси використовувати ті самі DNS‑сервери?

Можуть, але забезпечте досяжність і низьку затримку. Хороший патерн — локальні кешуючі резолвери на кожному сайті, що форвардять до центральних
авторитетів. Це зменшує залежність VPN для кожного DNS‑запиту.

8) Статичні маршрути чи динамічна маршрутизація для малої компанії?

Два сайти, кілька підмереж: статичні маршрути — ок. Більше сайтів, часті зміни або багато VLAN: використовуйте OSPF або BGP, щоб не забувати маршрути під час нагальних робіт.

9) Який час оренди варто використовувати для клієнтів віддаленого офісу?

Якщо DHCP локальний — стандартні часи оренди (8–24 години для користувацьких мереж) підходять. Якщо DHCP централізований через VPN — використовуйте довші оренди,
щоб короткі WAN‑падіння не спричиняли масових оновлень і руху.

10) Чи коли-небудь прийнятне мостування через site-to-site VPN?

Рідко, і зазвичай тимчасово: нішові легасі‑потреби, короткі міграції або дуже малі середовища, де ризики прийняті свідомо.
Якщо мостите — задокументуйте план виходу з першого дня.

Висновок: наступні кроки, які дійсно знижують ризик

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

Виконайте ці кроки далі, в порядку:

1. Запишіть кожну підмережу на кожному сайті і усуньте перекриття. Якщо не можете зробити це одразу, використайте NAT з явним планом виведення.
2. Оберіть модель DHCP свідомо: локальний на сайті за замовчуванням; релє до центра лише коли WAN і операційна зрілість це дозволяють.
3. Заблокуйте маршрутизацію і політику фаєрволу до того, що вам точно потрібно, потім моніторьте дропи і стан тунелю.
4. Перевірте MTU/MSS рано, щоб не витрачати тиждень на звинувачення «VPN» за проблему розмірів пакетів.
5. Зробіть це нудним: невелике джерело правди в IPAM, повторювані чек‑лісти і вміння знімати пакети виграють над героїкою щоразу.

Якщо ви зробите це добре, VPN стане тим, чим завжди мав бути: непомітним транспортом. Ваші користувачі цього не помітять.
Це — успіх.