WireGuard для віддаленого доступу в домашню мережу – VPN-схема, де телефон або ноутбук ззовні отримує доступ до хостів у LAN без пробросу зайвих сервісів назовні. Тут потрібні чотири речі: робочий конфіг на Linux, коректний AllowedIPs, DNS до локальних імен і перевірка, яка швидко показує зламаний вузол.
Нормальний результат простий: клієнт піднімає тунель, бачить домашню підмережу, резолвить локальні імена через домашній DNS і не жене весь інтернет у VPN. Handshake сам по собі тут нічого не гарантує. Найчастіше тунель піднявся, а доступу до LAN немає через хибні маршрути, вимкнений forwarding або невдалий AllowedIPs.
Який результат має дати мінімальний домашній WireGuard
Після базового налаштування клієнт отримує адресу в окремій VPN-підмережі, бачить домашню LAN і ходить через тунель тільки туди. Для дому цього зазвичай вистачає: NAS, Proxmox, SSH, веб-інтерфейси і локальний DNS працюють без маршрутизаційного хаосу.
Цільова схема така: домашня мережа 192.168.1.0/24, VPN-підмережа 10.7.0.0/24, сервер має 10.7.0.1, клієнт – 10.7.0.2. Клієнт відправляє в тунель тільки 192.168.1.0/24 і VPN-підмережу. Решта трафіку йде через його звичайний інтернет.
Для одного-двох користувачів схема зазвичай спокійна. Коли клієнтів стає більше, росте шанс перетину адрес, дублювання маршрутів і плутанини з DNS. Для доступу до кількох домашніх пристроїв це все ще найчистіший варіант.
Яка мінімальна безпечна схема WireGuard працює вдома без зайвих дірок
Базовий варіант – сервер у домашній мережі, окрема VPN-підмережа і дозвіл тільки на потрібні маршрути. Full tunnel через 0.0.0.0/0 тут зазвичай зайвий, якщо задача зводиться до доступу до своїх ресурсів.
Сервер зручно ставити на окремий Linux-хост або домашній mini PC, який і так працює постійно. Роутер теж підійде, але на слабких коробках дебаг гірший, а правила firewall часто заховані в GUI. Для першого запуску Linux-сервер прозоріший.
Яку адресацію взяти за базу
У тунелі краще не використовувати популярні домашні підмережі на кшталт 192.168.0.0/24. Коли клієнт сидить у готелі, кав’ярні або чужому офісі з такою ж адресацією, маршрут до дому конфліктує з локальною мережею. VPN-підмережа на кшталт 10.7.0.0/24 зручніша.
Домашню LAN теж краще мати не надто типовою. Якщо є вибір, мережі рівня 192.168.50.0/24 або 10.20.30.0/24 приносять менше сюрпризів, ніж 192.168.1.0/24. Саме ця дрібниця часто вирішує, чи запрацює доступ з першого разу.
Які порти і доступ відкривати
Назовні потрібен тільки UDP-порт WireGuard, зазвичай 51820/udp. Після підняття тунелю вже можна ходити до SSH, веб-панелей і внутрішніх сервісів по локальних адресах. Якщо потрібен захист самого SSH, окремо варто додати 2FA для SSH через PAM і TOTP.
Якщо провайдер не дає білу адресу або немає бажання відкривати порт, ручний тунель швидко впирається в мережеві обмеження. У такому випадку іноді простіше дати доступ до окремого сервісу через Cloudflare Tunnel без пробросу портів, а не тягнути повний VPN.
Як налаштувати сервер WireGuard на Linux з конкретним конфігом
Для робочого сервера потрібні пакет WireGuard, увімкнений IP forwarding, конфіг інтерфейсу і NAT або маршрут на роутері. Для дому найпростіший варіант – Linux-сервер у LAN, який маскарадує трафік клієнтів у домашню мережу.
Нижче приклад для Debian або Ubuntu. Сервер стоїть у LAN з адресою 192.168.1.10, домашня мережа – 192.168.1.0/24, VPN – 10.7.0.0/24, зовнішній інтерфейс – eth0.
Встановлення пакетів і ключів
sudo apt update sudo apt install wireguard iptables umask 077 wg genkey | sudo tee /etc/wireguard/server.key | wg pubkey | sudo tee /etc/wireguard/server.pub wg genkey | sudo tee /etc/wireguard/client1.key | wg pubkey | sudo tee /etc/wireguard/client1.pub
Конфіг сервера /etc/wireguard/wg0.conf
[Interface] Address = 10.7.0.1/24 ListenPort = 51820 PrivateKey = ВМІСТ_/etc/wireguard/server.key PostUp = sysctl -w net.ipv4.ip_forward=1; iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -s 10.7.0.0/24 -d 192.168.1.0/24 -o eth0 -j MASQUERADE PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -s 10.7.0.0/24 -d 192.168.1.0/24 -o eth0 -j MASQUERADE [Peer] PublicKey = ВМІСТ_/etc/wireguard/client1.pub AllowedIPs = 10.7.0.2/32
Такий NAT не найелегантніший, зате для дому передбачуваний. Якщо є контроль над основним роутером, чистіше додати на ньому маршрут до 10.7.0.0/24 через Linux-сервер і прибрати маскарадинг. Для першого запуску NAT економить час і зменшує кількість точок, де все ламається.
Увімкнення сервера
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-wireguard.conf sudo sysctl --system sudo systemctl enable wg-quick@wg0 sudo systemctl start wg-quick@wg0 sudo systemctl status wg-quick@wg0 sudo wg show
Офіційна документація і пакети доступні на сайті WireGuard. Якщо потрібен тунель між двома майданчиками, логіка вже інша: там важливі статичні маршрути і симетрія підмереж. Для цього сценарію підійде окремий розбір про WireGuard між двома локаціями в UniFi.
WireGuard для віддаленого доступу в домашню мережу і роль AllowedIPs
AllowedIPs у WireGuard одночасно задає список адрес peer і таблицю маршрутів. На сервері це адреса самого клієнта в тунелі. На клієнті – мережі, які треба відправляти через VPN. Саме тут найчастіше ламають доступ у LAN або випадково женуть у тунель увесь інтернет.
Що ставити на сервері
Для одного клієнта на сервері зазвичай достатньо 10.7.0.2/32. Peer відповідає тільки за свою VPN-адресу і не заявляє інших підмереж. Для домашнього доступу цього вистачає.
Типова помилка – ставити на сервері 0.0.0.0/0 або домашню LAN у peer клієнта. Після цього маршрути перекривають один одного. Якщо клієнтів кілька, сервер може перестати розуміти, кому віддавати пакети.
Що ставити на клієнті
На клієнті для доступу в LAN треба вказати домашню підмережу і, за потреби, адресу DNS у тунелі. Для описаної схеми безпечний запис такий: 10.7.0.0/24, 192.168.1.0/24. Через VPN піде тільки трафік до дому.
Коли ставлять 0.0.0.0/0, клієнт переходить у full tunnel. Це доречно, якщо весь трафік треба виводити через дім або використовувати сервер як exit node. Для доступу до домашньої LAN такий запис зазвичай створює зайву роботу з DNS, NAT і MTU.
Приклад клієнтського конфига
[Interface] Address = 10.7.0.2/24 PrivateKey = ВМІСТ_КЛІЄНТСЬКОГО_КЛЮЧА DNS = 192.168.1.1 [Peer] PublicKey = ВМІСТ_/etc/wireguard/server.pub Endpoint = <server-ip-or-hostname>:51820 AllowedIPs = 10.7.0.0/24, 192.168.1.0/24 PersistentKeepalive = 25
PersistentKeepalive = 25 корисний для телефонів, ноутбуків за NAT і мобільних мереж. Без нього тунель може підніматись, але після простою переставати приймати вхідні пакети до наступного вихідного трафіку клієнта.
Як налаштувати DNS у WireGuard без витоків і без зламаного резолвінгу
Для домашнього доступу в DNS на клієнті варто ставити локальний резолвер, який доступний через тунель: адресу роутера, Pi-hole, AdGuard Home або внутрішній DNS-сервер. Якщо вказати зовнішній DNS, локальні імена не відкриватимуться. Якщо вказати домашній DNS без маршруту до нього, зламається весь резолвінг.
У схемі вище логічно використовувати 192.168.1.1, якщо роутер обслуговує локальні записи, або адресу окремого DNS-хоста в LAN. Клієнт має мати маршрут до цієї адреси через AllowedIPs. Інакше DNS формально заданий, але пакети до нього підуть повз тунель.
Чому перестають відкриватися локальні імена
Зазвичай проблема в тому, що клієнт використовує публічний DNS від провайдера або системний DNS мобільної мережі. Тоді запит до nas.home.arpa або локального hostname не знає, куди йти. Рішення просте: задати домашній DNS і прокласти до нього маршрут через VPN.
Чому після підключення пропадають зовнішні сайти
Таке стається, коли в клієнті виставили домашній DNS, але в AllowedIPs забули домашню підмережу або адресу DNS. Тунель може бути живий. Імена не резолвляться, браузер виглядає зламаним, а причина банальна – клієнт не може дістатись DNS-сервера.
Ще один неприємний випадок – локальний DNS у домашній мережі віддає зовнішні домени через upstream, який фільтрується або недоступний із сервера. Тоді локальні імена працюють, а зовнішні частково ні. Тут проблема вже в DNS-ланцюжку, а не в тунелі.
Як перевірити, що тунель, маршрути і доступ до LAN реально працюють
Перевірка йде в такому порядку: handshake, маршрут до домашньої мережі, пінг сервера у VPN, доступ до хоста в LAN, потім DNS. Якщо пропустити один крок, легко шукати проблему не там.
Що перевірити на сервері
sudo wg show ip addr show wg0 ip route sysctl net.ipv4.ip_forward sudo iptables -S sudo iptables -t nat -S
У wg show має бути latest handshake і лічильники трафіку. Якщо handshake немає, проблема ще до маршрутизації: порт, endpoint, ключі або NAT між клієнтом і сервером.
Що перевірити на клієнті
wg show ip route ping 10.7.0.1 ping 192.168.1.1 ping 192.168.1.10 getent hosts google.com getent hosts <local-hostname>
Спочатку має відповідати 10.7.0.1. Потім – роутер або інший вузол у LAN. Якщо VPN-адреса доступна, а хости в домашній мережі ні, проблема майже завжди в forwarding, NAT або маршруті назад із LAN до VPN-підмережі.
Для Windows і мобільних клієнтів порядок той самий: стан тунелю, IP у VPN, локальний хост у LAN, і лише потім DNS. Браузер нічого не пояснює, а ping і таблиця маршрутів пояснюють швидко.
Чому WireGuard підключається, але домашня мережа не відкривається
Найчастіші причини чотири: сервер не форвардить пакети, немає NAT або зворотного маршруту, на клієнті зламаний AllowedIPs, або домашній firewall ріже трафік із VPN-підмережі. Handshake в такій ситуації є, але LAN лишається недоступною.
Handshake є, але пінгується тільки 10.7.0.1
Класичний симптом вимкненого net.ipv4.ip_forward або відсутнього правила FORWARD. Сервер бачить клієнта як peer, але не маршрутизує пакети далі в домашню мережу.
Інший варіант – маскарадинг не спрацював. Тоді хост у LAN отримує пакет від 10.7.0.2, але не знає, куди надсилати відповідь. Якщо на роутері немає статичного маршруту назад до 10.7.0.0/24, без NAT відповіді не буде.
Після підключення зник інтернет на клієнті
Зазвичай у клієнтському конфізі стоїть AllowedIPs = 0.0.0.0/0. Увесь трафік пішов через тунель, а сервер не налаштований як вихід у інтернет. Для домашнього доступу це треба замінити на маршрути тільки до LAN.
Якщо full tunnel все ж потрібен, схема вже інша. Сервер має NAT-ити трафік у WAN, коректно віддавати DNS і не ламати MTU. Для таких сценаріїв іноді простіше підняти Tailscale exit node на Linux.
Домашні хости відкриваються по IP, але не по імені
Маршрути тут уже працюють. Проблема майже напевно в DNS: не той сервер, не той search domain або DNS-сервер не має маршруту через тунель. Перевірка через getent hosts або nslookup знаходить це відразу.
Підключення нестабільне з мобільної мережі
Часто допомагає PersistentKeepalive = 25 на клієнті. Без нього state у NAT на стороні мобільного оператора може протухати. Симптом типовий: після простою тунель наче підключений, але вхідний трафік не доходить.
Коли WireGuard вручну ще має сенс, а коли краще взяти Tailscale
WireGuard для віддаленого доступу в домашню мережу доречний там, де потрібен повний контроль: свій сервер, свої ключі і своя маршрутизація. Для одного дому та кількох клієнтів це чисте рішення. Коли з’являються CGNAT, кілька користувачів, кілька локацій і потреба в простому онбордингу, Tailscale часто економить години дебагу.
Така схема добре підходить для доступу до NAS, Proxmox, SSH і локального DNS без зайвого шару абстракції. Але після кількох мобільних клієнтів і змішаних мереж головна складність уже не в шифруванні, а в тому, що маршрути мають збігатись у всіх точках.
Tailscale виграє там, де головний ворог – мережеве оточення. NAT traversal, авторизація користувачів і швидке підключення нових пристроїв там зроблені краще. Якщо стоїть вибір між цими підходами, варто глянути окреме порівняння Tailscale чи WireGuard для homelab.
Якщо задача вузька і зрозуміла, ручний конфіг виглядає краще. Коли тунель має просто працювати на різних мережах без полювання на AllowedIPs, DNS і NAT, перехід на Tailscale зазвичай дешевший за подальший ручний супровід.
WireGuard для віддаленого доступу в домашню мережу добре працює як мінімальний VPN до своїх ресурсів, якщо не чіпати зайві маршрути і не тягнути весь трафік у тунель без потреби. Більшість збоїв тут виникає через AllowedIPs, DNS і зворотний маршрут із LAN. Якщо саме це вже забирає більше часу, ніж сам доступ до сервісів, ручна схема вперлась у свою межу.
Коментарі
Коментарів ще немає. Обговорення - у Telegram.