Проектування та налаштування безпечних мереж та VPN

Мережева архітектура, яка не гальмує: проектування та налаштування WireGuard, BGP, VLAN

Два офіси, три хмарні VPC, десяток розробників з ноутбуками — і жоден не може підключитися до production-бази без відкритого SSH на весь інтернет. Класичний OpenVPN з центральним сервером перетворюється на вузьке місце: весь трафік йде через хаб, latency зростає, а при падінні сервера вся мережа лягає. Ми проектуємо та налаштовуємо безпечні мережі та VPN, які цього не допускають. Маємо 10+ років досвіду в мережевій інженерії та реалізували 50+ проектів з VPN, BGP та VLAN-сегментації.

Як налаштувати WireGuard mesh без єдиної точки відмови?

WireGuard — мінімалістичний VPN-протокол (~4000 рядків коду в ядрі Linux). Жодного handshake у традиційному розумінні — cryptokey routing на основі публічних ключів. Mesh-топологія з'єднує кожну ноду напряму, минаючи центральний хаб. Затримка між нодами в одному датацентрі — 0,2–0,5 мс замість 2–5 мс через hub-and-spoke. При WAN-з'єднанні ЄС–США: 85 мс проти 170 мс через європейський хаб.

Базова конфігурація на трьох нодах:

# /etc/wireguard/wg0.conf на node-1 (10.10.0.1) [Interface] PrivateKey = <node1-private-key> Address = 10.10.0.1/24 ListenPort = 51820 PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE [Peer] # node-2 PublicKey = <node2-public-key> AllowedIPs = 10.10.0.2/32 Endpoint = 203.0.113.2:51820 PersistentKeepalive = 25 [Peer] # node-3 PublicKey = <node3-public-key> AllowedIPs = 10.10.0.3/32 Endpoint = 203.0.113.3:51820 PersistentKeepalive = 25 

PersistentKeepalive = 25 — keepalive кожні 25 секунд. Потрібен для нод за NAT: без нього UDP-сесія в NAT-таблиці закінчується. Для вузлів з публічним IP не потрібен.

AllowedIPs — це одночасно маршрутизація та ACL. WireGuard відхилить пакет, якщо source IP піра не збігається з його AllowedIPs. Це cryptokey routing, а не класичний firewall.

Масштабування: коли руками вже не впоратися

Вручну керувати N*(N-1)/2 парами при 50 нодах — це 1225 конфігураційних блоків. На допомогу приходять оркестратори:

• Netmaker — self-hosted, REST API, dynamic endpoints. Агент на кожній ноді підтягує конфіг через wg syncconf. Зберігає топологію в SQLite/PostgreSQL.
• Headscale — open-source control plane для Tailscale-клієнтів. Розгортаєте на своїй інфраструктурі, Tailscale-клієнти отримують ключі та маршрути від headscale.
• Tailscale SaaS — для швидкого onboarding нових співробітників: від встановлення до працюючого VPN — 5 хвилин. Для compliance-оточень обираємо self-hosted.

Налаштування WireGuard з оркестратором — типовий проект: проектуємо топологію, налаштовуємо control plane, підключаємо ноди. Весь процес під ключ — від аудиту до гоулінгу працює.

Що робити, коли NAT заважає прямому з'єднанню

WireGuard використовує STUN-подібний механізм для NAT traversal. Якщо обидва піри за double NAT (CGNAT у провайдера), пряме з'єднання неможливе — трафік йде через relay (наприклад, DERP в Tailscale). Це збільшує latency до рівня hub-and-spoke. Діагностика:

wg show wg0 wg show wg0 latest-handshakes wg set wg0 peer <pubkey> endpoint <new-ip>:51820 

Якщо latest-handshakes показує 2+ хвилини тому при активному трафіку — UDP блокується фаєрволом або не працює ротація endpoint. Перевіряємо tcpdump -i eth0 udp port 51820. Ми гарантуємо коректне налаштування правил фаєрвола та вибір оптимального relay-сервера.

Коли OpenVPN все ще актуальний?

OpenVPN повільніший за WireGuard у 2–4 рази на типових конфігураціях, важчий у налаштуванні, але працює через TCP 443 (маскування під HTTPS) і підтримується на legacy-обладнанні (старі роутери, промислові контролери). Для site-to-site з застарілими пристроями — єдиний варіант. Ми оцінимо проект і запропонуємо оптимальну стратегію міграції.

BGP: керуємо трафіком між датацентрами та хмарами

BGP в приватній мережі — це не лише маршрутизація інтернету. Він дозволяє:

• Anycast: один IP анонсується з кількох локацій. DNS, CDN, балансування на рівні маршрутизації.
• MetalLB в Kubernetes: піднімає BGP-сесію з фізичним роутером і анонсує VIP нового сервісу типу LoadBalancer. Роутер додає маршрут напряму — ніякого DNAT.

# Пір BGP MetalLB apiVersion: metallb.io/v1beta2 kind: BGPPeer metadata: name: core-router namespace: metallb-system spec: myASN: 64512 peerASN: 64511 peerAddress: 10.0.0.1 keepaliveTime: 30s holdTime: 90s routerID: 10.0.1.100 

Cilium з eBPF може анонсувати Pod CIDR та Service VIP через BGP напряму, замінюючи kube-proxy. Пакети йдуть без VXLAN/Geneve — менше overhead.

VLAN-сегментація: коли bare metal не прощає безкарності

Базове розділення для production:

Storage VLAN з MTU 1500 втрачає 20–30% throughput на Ceph через фрагментацію. На 25 Гбіт/с різниця між 1500 і 9000 байт — не просто метрика, а гроші (економія до 40% на хмарних тарифах при правильній сегментації).

Що входить у роботу (deliverables)

Типові помилки при налаштуванні WireGuard

• Відсутність PersistentKeepalive для нод за NAT — з'єднання падає кожні 2–3 хвилини.
• Занадто широкі AllowedIPs (наприклад, 0.0.0.0/0) — весь трафік йде через VPN, хоча потрібно лише до певних підмереж.
• Не налаштовано PostUp/PostDown для forwarding та NAT — пакети не маршрутизуються.
• Обрано hub-and-spoke для великої кількості нод — дешево, але швидко перетворюється на вузьке місце.

Терміни та вартість

Вартість розраховується індивідуально після аудиту. При середньому проекті інвестиція окупається за 3–6 місяців завдяки зниженню часу простоїв та зменшенню хмарних витрат.

Замовте аудит вашої мережі — отримайте детальний план з термінами та вартістю. Отримайте консультацію: напишіть нам, і ми надішлемо чек-лист для самостійного аудиту та домовимося про першу зустріч.