Защита для домашнего сервера — настраиваем защиту через VPN-доступ за один вечер

• 1 Механизм работы

  • 1.1 Схема разделения доступов

  • 1.2 VPN - закрытый вход в частную сеть

  • 1.3 Reverse-proxy - единая точка входа

  • 1.4 Локальный DNS для VPN-клиентов

• 2 Настройка роутера

• 3 Настраиваем VPN

  • 3.1 Подготовка: установка Docker

  • 3.2 Запускаем WireGuard в Docker

  • 3.3 Важный нюанс: проблема с одинаковыми подсетями

  • 3.4 Добавление VPN-клиентов

• 4 Настраиваем DNS-резолвер (dnsmasq)

  • 4.1 Как это работает

  • 4.2 Проверка работы

• 5 Настраиваем Reverse-proxy

  • 5.1 Вариант A - «Всё в Docker» (рекомендую)

  • 5.2 Вариант B - «Nginx в Docker → сервис на хосте»

  • 5.3 Вариант C - «Всё на хосте (без Docker)»

• 6 Устанавливаем VPN-конфиг на устройства

  • 6.1 Где найти конфиги клиентов

  • 6.2 Пример клиентского конфига

  • 6.3 Установка приложения WireGuard

  • 6.4 Импорт конфига на ПК (Windows/macOS/Linux)

  • 6.5 Импорт конфига на мобильные (iOS/Android)

  • 6.6 Проверка подключения

• 7 Набор быстрых проверок (self-audit)

  • 7.1 Проверка VPN-сервера

  • 7.2 Проверка DNS-резолвера

  • 7.3 Проверка Nginx

  • 7.4 Сквозной тест с клиента

• 8 Что делать, если не работает

  • 8.1 VPN не подключается

  • 8.2 DNS не резолвит домены

  • 8.3 Nginx отдаёт ошибки

  • 8.4 Чеклист диагностики

  • 8.5 Нужна помощь?

• 9 Итоги

  • 9.1 Что мы построили

  • 9.2 Преимущества решения

  • 9.3 Когда это решение подходит

  • 9.4 Обратная связь

• 10 Финал

Нужно, чтобы IP твоего сервера был постоянным, мы будем использовать его тут и в дальнейшем при настройке конфигураций на сервере.

У меня это выглядит следующим образом:

Здесь я задал постоянный IP - 192.168.31.90

Теперь пробрасываем порты на зарезервированный IP:

• 51820/UDP - дляWireGuard(VPN-подключения)

• 80/TCP и 443/TCP - дляNginx(веб-доступ к сервисам)

Для работы WireGuard в контейнере нам нужен Docker и Docker Compose. Если у тебя уже установлен Docker, можешь пропустить этот раздел.

1. Обновляем систему

   sudo apt update
   sudo apt upgrade -y
   

2. Устанавливаем зависимости

   sudo apt install -y apt-transport-https ca-certificates curl software-properties-common gnupg
   

3. Добавляем GPG-ключ Docker

   curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
   

4. Добавляем официальный репозиторий Docker

   echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
   

5. Обновляем индекс пакетов

   sudo apt update
   

6. Устанавливаем Docker Engine + Docker Compose plugin

   sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
   

7. Запускаем и включаем Docker

   sudo systemctl enable docker
   sudo systemctl start docker
   

8. Добавляем пользователя в группу docker Чтобы не писать sudo перед каждой командой Docker:

   sudo usermod -aG docker $USER
   

9. Применяем изменения групп

   newgrp docker
   

   Или перелогинься в систему, чтобы изменения вступили в силу.

• Создаем для удобства директорию vpn:

mkdir ~/vpn
cd ~/vpn

• Создаём файл docker-compose.vpn.yml:

cat << EOF > docker-compose.vpn.yml
version: '3.8'

services:
  vpn:
    image: linuxserver/wireguard
    container_name: vpn
    network_mode: "host"         
    cap_add:
      - NET_ADMIN                        
      - SYS_MODULE                      
    environment:
      - PUID=0
      - PGID=0
      - TZ=Europe/Moscow
      - SERVERURL=home-server.ru      
      - SERVERPORT=51820
      - PEERS=mackbook,ipad     
      - PEERDNS=auto           
      - INTERNAL_SUBNET=10.8.0.0         
      - ALLOWEDIPS=10.8.0.0/24,192.168.31.90/32
      - LOG_CONFS=false
    volumes:
      - ./wireguard/config:/config
    restart: unless-stopped
EOF

Разберём конфигурацию подробнее для того, чтобы ты смог сконфигурировать сервис под свой случай.

Параметры, которые тебе с большей вероятностью нужно будет заменить:

Переменные окружения:

environment:
  - PUID=0
  - PGID=0
  - TZ=Europe/Moscow
  - SERVERURL=home-server.ru
  - SERVERPORT=51820
  - PEERS=mackbook,ipad
  - PEERDNS=auto
  - INTERNAL_SUBNET=10.8.0.0
  - ALLOWEDIPS=10.8.0.0/24,192.168.31.90/32
  - LOG_CONFS=false

• PUID / PGID
  UID и GID пользователя внутри контейнера, от имени которого будут созданы файлы в /config.
  В примере используется 0 (root) - просто и универсально. При желании можно завести отдельного пользователя.

• TZ
  Часовой пояс. Нужен для того, чтобы время в логах совпадало с твоим локальным.

• SERVERURL
  Внешний адрес, по которому к тебе будут подключаться клиенты:

  • домен (home-server.ru),

  • или белый IP сервера. Этот параметр попадает в готовые клиентские конфиги как Endpoint =home-server.ru:51820.

• SERVERPORT
  Порт WireGuard на стороне сервера. Здесь 51820, но можно выбрать любой свободный UDP-порт.
  Этот же порт мы уже пробросили на роутере (см. главу 2).

• PEERS
  Количество клиентов, для которых контейнер сам сгенерирует конфиги, или список имён через запятую. Контейнер сделает автогенерацию wg0.conf  +peerX.conf и их QR‑кодов.
  Формат:

  • PEERS=1 - один клиент  peer1 .

  • PEERS=mackbook,ipad - два клиента с такими именами.

• PEERDNS
  Какой DNS‑сервер будет прописан в конфигурациях клиентов ( DNS = ... ).
  Значения:

  • auto  (по умолчанию) - клиенты используют DNS самого контейнера, который в свою очередь форвардит запросы туда же, куда ходит основной хост.

  • Любой IP, например  1.1.1.1  или  8.8.8.8 .

• INTERNAL_SUBNET
  Базовый адрес подсети VPN.
  В примере: 10.8.0.0, значит, клиенты будут получать адреса вида 10.8.0.x.

• ALLOWEDIPS
  Какие сети клиент будет маршрутизировать через туннель.
  В примере:

  • 10.8.0.0/24 - сама VPN-подсеть (чтобы клиенты видели друг друга и сервер),

  • 192.168.31.90/32 - конкретный IP сервера с маской /32.

  ⚠️ Важно: Используем именно /32 (один конкретный хост), а не /24 (всю подсеть).
  Это гарантирует, что трафик к серверу всегда пойдёт через VPN-туннель, даже когда ты подключён из той же домашней сети - подробности в разделе 3.3 ниже.

  Весь остальной интернет-трафик (обычные сайты) будет идти напрямую через твоё текущее подключение (Wi-Fi, мобильный интернет), а не через VPN. Это называется split-tunnel режим - он экономит трафик домашнего интернета и даёт максимальную скорость.

• LOG_CONFS
  Включить или выключить вывод QR‑кодов конфигураций клиентов в лог контейнера.

  • Значения:  true или false (по умолчанию false). Я поставил false, конфиги мы потом возьмем из сгенерированных файлов.

💡 Совет: Не пугайся количества параметров - в 90% случаев достаточно поменять только SERVERURL и PEERS. Остальное работает "из коробки".

Включаем пересылку пакетов (IP forwarding)

Чтобы VPN-сервер мог маршрутизировать трафик между клиентами и локальной сетью, нужно включить пересылку пакетов:

echo "net.ipv4.ip_forward = 1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Это заставляет сервер работать как маршрутизатор:

• принимает пакеты от VPN-клиента (10.8.0.x),

• пересылает их в локальную сеть (192.168.31.x),

• и обратно - отвечает клиенту через туннель.

Запуск контейнера
Теперь всё готово для запуска VPN-сервера:

docker compose -f docker-compose.vpn.yml up -d

После запуска ты получаешь:

1. Контейнер vpn проверка:

   docker ps
   

   Должен увидеть контейнер vpn в статусе Up.

2. Интерфейс wg0 на хосте Проверка:

   ip a show wg0
   

   Должен увидеть интерфейс с адресом 10.8.0.1/24 в состоянии UP.

3. Конфигурация сервера и клиентов На хосте появилась директория:

   ls ./wireguard/config
   

   Внутри лежат конфиги WireGuard.

4. Готовность добавлять клиентов Не нужно вручную генерировать ключи - всё делает скрипт внутри контейнера.

При настройке VPN есть важная особенность, с которой ты можешь столкнуться, если находишься в той же домашней сети, что и сервер.

1 В чём проблема

Параметр AllowedIPs в WireGuard на стороне клиента задаёт маршруты - то есть говорит операционной системе: "вот эти адреса отправляй через VPN-туннель".

Казалось бы, можно указать:

AllowedIPs = 10.8.0.0/24, 192.168.31.0/24

И всё должно работать: VPN-подсеть + вся домашняя сеть. Но вот загвоздка.

Когда ты подключаешься к VPN находясь в той же домашней сети (например, сидишь дома, подключён к своему Wi-Fi с адресом 192.168.31.x), операционная система видит, что адрес 192.168.31.90 (сервер) находится в той же локальной сети, к которой ты уже подключён напрямую.

И тут происходит конфликт приоритетов в таблице маршрутизации:

• С одной стороны, WireGuard создаёт маршрут: "трафик к 192.168.31.0/24 отправляй через туннель wg0"

• С другой стороны, уже существует локальный маршрут: "трафик к 192.168.31.0/24 отправляй через Wi-Fi интерфейс напрямую"

Локальный маршрут имеет больший приоритет (меньшую метрику), потому что система считает прямое подключение к локальной сети более предпочтительным, чем туннель.

В итоге трафик идёт напрямую, в обход VPN.

2 Как это проявляется

1. Подключаешься к VPN из домашней сети

2. DNS через VPN резолвит home-server.ru в LAN IP 192.168.31.90

3. Браузер отправляет запрос на 192.168.31.90

4. Запрос идёт напрямую, минуя туннель

5. Nginx видит твой реальный домашний IP (например, 192.168.31.150), а не VPN IP (10.8.0.x)

6. Получаешь 403 Forbidden, потому что Nginx разрешает только 10.8.0.0/24

3 Почему так происходит

В таблице маршрутизации ОС правила имеют приоритет по длине префикса (маске подсети):

• Более конкретный маршрут (/32, /30) имеет больший приоритет

• Менее конкретный маршрут (/24, /16) имеет меньший приоритет

Но когда маски одинаковые (/24 через Wi-Fi vs /24 через VPN), система смотрит на метрику маршрута - и локальное подключение обычно выигрывает.

4 Решение

Нужно добавить более специфичный маршрут - указать конкретный IP сервера с маской /32. В маршрутизации более конкретный маршрут всегда имеет приоритет над общим, независимо от метрики.

Поэтому вместо:

AllowedIPs = 10.8.0.0/24, 192.168.31.0/24

Используем:

AllowedIPs = 10.8.0.0/24, 192.168.31.90/32

Где 192.168.31.90 - это IP твоего сервера (на котором крутится Nginx иWireGuard).

Теперь:

• Маршрут к 192.168.31.90/32 (через VPN) более конкретен, чем 192.168.31.0/24 (через Wi-Fi)

• Трафик к конкретному IP сервера 192.168.31.90 гарантированно пойдёт через туннель

• VPN-клиент всегда будет приходить с адреса 10.8.0.x

• Nginx пропустит запрос

5 Когда эта проблема НЕ проявляется

Если ты подключаешься к VPN из другой сети (например, с мобильного интернета, из кафе, с работы), там ��одсеть другая (скажем 172.16.x.x), и конфликта нет - трафик нормально идёт через туннель даже с AllowedIPs = 10.8.0.0/24, 192.168.31.0/24.

Но лучше сразу использовать /32 - это универсально работает везде, независимо от того, откуда ты подключаешься.

📖 Из личного опыта: Я потратил часа 4 на понимание этой проблемы. Перепроверил все конфиги, отследил все хождения запросов, искал ошибку везде. В итоге нашёл информацию об этом нюансе в интернете - оказалось, всё дело в приоритетах маршрутизации. Теперь ты не потратишь эти 4 часа!

Чтобы добавить больше узлов/клиентов, необходимо увеличить PEERS значение в нашем docker-compose.vpn.yml или добавить больше элементов в список и пересоздать контейнер.

docker compose -f docker-compose.vpn.yml down
docker compose -f docker-compose.vpn.yml up -d

🎉 Отлично! VPN-сервер запущен и готов к работе. Но клиентам ещё нужно научиться обращаться к сервисам по доменам вместо IP. Для этого настроим DNS.

1. Устанавливаем dnsmasq

   sudo apt install -y dnsmasq
   

2. Добавляем сервис в автозапуск при старте системы:

   sudo systemctl enable dnsmasq
   

3. Создаем файл dnsmasq.conf в директории vpn:

   cd ~/vpn
   cat << EOF > dnsmasq.conf
   # слушаем VPN и локально
   listen-address=10.8.0.1
   listen-address=127.0.0.1
   
   # интерфейс VPN
   interface=wg0
   bind-interfaces
   
   # внутренние домены → LAN IP reverse-proxy
   address=/home-server.ru/192.168.31.90
   address=/photos.home-server.ru/192.168.31.90
   
   EOF
   

4. Создаем символическую ссылку в  /etc/dnsmasq.d:

   sudo ln -s $HOME/vpn/dnsmasq.conf /etc/dnsmasq.d/vpn.conf
   

5. Перезапустим dnsmasq

   sudo systemctl restart dnsmasq
   

Как это работает

• Все клиенты VPN будут использовать DNS 10.8.0.1.

• При запросе home-server.ru - dnsmasq вернёт LAN IP сервера 192.168.31.90 (где установлен Nginx).

• Nginx увидит клиента как 10.8.0.x и разрешит доступ (по allow 10.8.0.0/24).

Проверка работы

1. Проверяем, что dnsmasq запущен и слушает 10.8.0.1:53:

   sudo ss -tulpn | grep ':53'
   

2. Проверяем, что домены резолвятся в нужный IP:

   dig @10.8.0.1 home-server.ru
   dig @10.8.0.1 photos.home-server.ru
   

   В секции  ANSWER  должен быть адрес 192.168.31.90

Хорошо, DNS настроен! Осталось настроить Nginx - и защита будет полной. Это последний технический шаг перед подключением устройств.

Этот вариант подразумевает, что и Nginx, и сами сервисы живут в Docker и общаются друг с другом по внутренней сети Docker, без лишних пробросов портов и танцев с IP‑адресами.Nginx смотрит наружу (80/443), а внутри проксирует запросы в другие контейнеры по их именам внутри одной сети edge_net.

docker-compose.nginx.yml

version: '3.8'

services:
    nginx:
        image: nginx:alpine
        container_name: nginx
        ports:
          - "80:80"
          - "443:443"
        networks:
          - edge_net
        volumes:
          - ./nginx.conf:/etc/nginx/nginx.conf:ro
            
networks:
    edge_net:
        external: true

docker-compose.app.yml

version: '3.8'

services:
	myapp:
		image: myapp:latest
        container_name: nginx
		expose:
		  - "9000"        # порт доступен только внутри сети edge_net
		networks:
		  - edge_net
		    
networks:
  edge_net:
    external: true

конфигурация nginx.conf

events {}

http {
	upstream myapp {
		server myapp:9000;
	}

	server {
		listen 80;
		server_name home-server.ru;
		
		# доступ только из VPN
		allow 10.8.0.0/24;
		deny  all;

		location / {
			proxy_pass http://myapp;
		}
	}
}

Плюсы подхода
- Всё изолировано внутри Docker: порты приложений не торчат на хост, наружу выходят только 80/443 с nginx.
- Упрощённый DNS: в proxy_pass и upstream используем имена сервисов ( myapp ), Docker сам резолвит их в IP.

Минусы подхода
- Требует «докеризовать» приложение.
- Отладка иногда чуть менее наглядна: нужно помнить про внутреннюю сеть Docker и её DNS, а не просто стучаться на localhost:port.

docker network create edge_net

mkdir ~/nginx
cd ~/nginx

cat << EOF > nginx.conf
events {}

http {
	upstream myapp {
		server myapp:9000;
	}

	server {
		listen 80;
		server_name home-server.ru;
		
		allow 10.8.0.0/24;
		deny  all;

		location / {
			proxy_pass http://myapp;
		}
	}
}
EOF

cat << EOF > docker-compose.nginx.yml
version: '3.8'

services:
    nginx:
        image: nginx:alpine
        container_name: nginx
        ports:
          - "80:80"
          - "443:443"
        networks:
          - edge_net
        volumes:
          - ./nginx.conf:/etc/nginx/nginx.conf:ro
            
networks:
    edge_net:
        external: true
EOF

docker compose -f docker-compose.nginx.yml up -d

Этот вариант нужен, когда приложение крутится на хосте, у него свой порт (например, 127.0.0.1:9000 ), и ты не хочешь/не можешь его перенести в Docker.
Здесь мы просто запускаем nginx в контейнере и даём ему доступ к сети хоста.
docker-compose.nginx.yml

version: '3.8'

services:
  nginx:
    image: nginx:alpine
    container_name: nginx
    network_mode: host # контейнер использует сеть хоста
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
    restart: unless-stopped

nginx.conf

events {}

http {
    upstream myapp_host {
        server 127.0.0.1:9000; # существующий сервис на хосте
    }

    server {
        listen 80;
        server_name home-server.ru;
        
        # доступ только из VPN
        allow 10.8.0.0/24;
        deny  all;

        location / {
            proxy_pass http://myapp\\\_host;
        }
    }
}

Плюсы подхода
- Не нужно переносить существующий сервис в Docker - он остаётся как есть, ты добавляешь только тонкий Nginx‑слой поверх.
- Простая схема отладки: бекенд по‑прежнему доступен на 127.0.0.1:9000 , Nginx на 80/443 того же хоста.
- Хорошо подходит для «старых» или тяжёлых сервисов, где контейнеризация откладывается на потом.

Минусы подхода
- Если на хосте уже есть другой веб‑сервер на 80/443, придётся либо переносить его, либо разруливать конфликты портов.
- В отличие от варианта «всё в Docker», приложение всё ещё «торчит» на хосте (хотя только на  127.0.0.1 ), и часть сетевой логики остаётся вне Docker.

mkdir ~/nginx
cd ~/nginx

cat << EOF > nginx.conf
events {}

http {
	upstream myapp_host {
		server 127.0.0.1:9000;
	}
	
	server {
		listen 80;
		server_name home-server.ru;
		
		allow 10.8.0.0/24;
		deny  all;
	
		location / {
			proxy_pass http://myapp\\\\_host;
		}
	}
}
EOF

cat << EOF > docker-compose.nginx.yml
version: '3.8'

services:
    nginx:
        image: nginx:alpine
        container_name: nginx
        network_mode: host
        volumes:
          - ./nginx.conf:/etc/nginx/nginx.conf:ro
        restart: unless-stopped
EOF

docker compose -f docker-compose.nginx.yml up -d

Этот вариант для максимально простой схемы. Все компоненты, приложения и nginx установлены прямо на хосте, без контейнеров.

Плюсы подхода
- Минимум частей: ничего не нужно устанавливать и обновлять в контейнерах, только пакеты ОС.
- Хорош для небольшого домашнего сервера или одной‑двух служб, когда Docker избыточен.

Минусы подхода
- Нет изоляции приложений: все процессы делят одну систему (библиотеки, окружение, зависимости).
- Развёртывание и обновление сложнее повторять: нет декларативного описания в compose‑файле, всё завязано на состояние хоста.
- При росте числа сервисов конфигурация на голом хосте начинает быстро обрастать «зоопарком» юнитов, пакетов и ручных настроек.

sudo apt update
sudo apt install nginx -y
sudo systemctl enable nginx

sudo rm /etc/nginx/sites-enabled/default

sudo tee /etc/nginx/sites-available/home-server.ru >/dev/null << 'EOF'
server {
    listen 80;
    server_name home-server.ru;

    allow 10.8.0.0/24;
    deny  all;

    location / {
        proxy_pass http://127.0.0.1:9000;
    }
}
EOF

sudo ln -s /etc/nginx/sites-available/home-server.ru /etc/nginx/sites-enabled/home-server.ru
sudo nginx -t

sudo systemctl restart nginx

Конфиги были автоматически сгенерированы при первом запуске контейнера WireGuard.

Заходим в директорию с конфигами:

cd ~/vpn/wireguard/config/
ls

В консоли ты увидишь директории с префиксом peer_ - это конфиги для VPN-клиентов. В моём случае это peer_mackbook и peer_ipad.

Заходим в директорию нужного клиента:

cd peer_mackbook
ls

Здесь лежат два файла:

• peer_mackbook.conf - конфигурационный файл для импорта

• peer_mackbook.png - QR-код для быстрого импорта на мобильные устройства

Выведем в консоль содержимое конфига:

cat peer_mackbook.conf

Пример того, что увидишь:

[Interface]
Address = 10.8.0.2/32
PrivateKey = <приватный ключ клиента>
DNS = 10.8.0.1

[Peer]
PublicKey = <публичный ключ сервера>
PresharedKey = <общий ключ>
Endpoint = home-server.ru:51820
AllowedIPs = 10.8.0.0/24, 192.168.31.90/32
PersistentKeepalive = 25

Разбор параметров:
Секция [Interface] (настройки клиента):

• Address = 10.8.0.2/32 - IP-адрес клиента в VPN-сети (каждый клиент получает свой уникальный адрес)

• PrivateKey - приватный ключ клиента (генерируется автоматически, никому не показывай)

• DNS = 10.8.0.1 - DNS-сервер для резолвинга внутренних доменов (наш dnsmasq) Секция [Peer] (настройки сервера):

• PublicKey - публичный ключ сервера WireGuard

• PresharedKey - дополнительный общий ключ для усиления безопасности (опционально)

• Endpoint =home-server.ru:51820 - адрес и порт сервера для подключения

• AllowedIPs = 10.8.0.0/24, 192.168.31.90/32 - какие сети маршрутизировать через VPN:

  • 10.8.0.0/24 - VPN-подсеть (для связи между клиентами и сервером)

  • 192.168.31.90/32 - IP сервера в локальной сети (почему /32 - см. раздел 3.3)

• PersistentKeepalive = 25 - отправлять keepalive-пакеты каждые 25 секунд

Перейди на официальный сайт WireGuard и скачай приложение для своей платформы

Скопируй файл конфига с сервера на свой компьютер:
Вариант A - через SCP:

scp user@192.168.31.90:~/vpn/wireguard/config/peer_ipad/peer_ipad.conf ~/Downloads/

Вариант B - вручную:

• Выведи содержимое:
  cat ~/vpn/wireguard/config/peer_ipad/peer_ipad.conf

• Скопируй весь текст

• Создай файл peer_ipad.conf на своём компьютере

• Вставь туда скопированный текст

Передай файл с компьютера на мобильное устройство:

• Для iOS/macOS: используй AirDrop

• Для Android: через USB, Bluetooth или облако (Google Drive, Dropbox)

• Универсально: через мессенджер (Telegram "Избранное", отправь файл самому себе)

Импортируй конфиг в приложение WireGuard:

• Открой приложение WireGuard на телефоне

• Нажми "+" → "Create from file or archive"

• Выбери файл peer_ipad.conf

• Конфиг импортируется в приложение

Активируй подключение:

• Включи переключатель напротив туннеля

• Статус должен измениться на "Active"

Скопируй файл конфига с сервера на свой компьютер:
Вариант A - через SCP:

scp user@192.168.31.90:~/vpn/wireguard/config/peer_ipad/peer_ipad.conf ~/Downloads/

Вариант B - вручную:

• Выведи содержимое:
  cat ~/vpn/wireguard/config/peer_ipad/peer_ipad.conf

• Скопируй весь текст

• Создай файл peer_ipad.conf на своём компьютере

• Вставь туда скопированный текст

Передай файл с компьютера на мобильное устройство:

• Для iOS/macOS: используй AirDrop

• Для Android: через USB, Bluetooth или облако (Google Drive, Dropbox)

• Универсально: через мессенджер (Telegram "Избранное", отправь файл самому себе)

Импортируй конфиг в приложение WireGuard:

• Открой приложение WireGuard на телефоне

• Нажми "+" → "Create from file or archive"

• Выбери файл peer_ipad.conf

• Конфиг импортируется в приложение

Активируй подключение:

• Включи переключатель напротив туннеля

• Статус должен измениться на "Active"

После активации VPN проверь доступ к защищённому сервису.

Проверь доступ с включённым VPN:
Открой браузер и введи:

http://home-server.ru

Должен открыться твой сервис.

• Если видишь 403 Forbidden - что-то не так с маршрутизацией или конфигом Nginx (см. главу 8).

• Если страница не загружается - проверь DNS и маршруты (см. главу 8).

Проверь, что блокировка работает БЕЗ VPN: Отключи VPN в приложенииWireGuard и попробуй снова открыть http://home-server.ru. Теперь должна быть ошибка подключения или 403 Forbidden - это значит, что защита работает, и без VPN доступа нет.

Убедимся, что контейнер WireGuard запущен и интерфейс поднят.

1. Проверяем статус контейнера:

   docker ps | grep vpn
   

   Ожидаем увидеть контейнер vpn в статусе Up.

2. Проверяем интерфейс wg0 на хосте:

   ip a show wg0
   

   Должен быть виден интерфейс с адресом 10.8.0.1/24 в состоянии UP.

3. Смотрим подключённых клиентов:

   docker exec vpn wg show
   

   Если клиенты подключены, увидите их публичные ключи и последнее время handshake. Если клиенты ещё не подключались, список peers будет пустым - это нормально.

Проверим, что dnsmasq слушает на VPN-интерфейсе и корректно резолвит внутренние домены.

1. Проверяем, что dnsmasq запущен и слушает порт 53:

   sudo ss -tulpn | grep ':53'
   

   Должны увидеть процесс dnsmasq, слушающий на 10.8.0.1:53 и 127.0.0.1:53.

2. Тестируем резолвинг (с сервера):

   dig @10.8.0.1 home-server.ru
   dig @10.8.0.1 photos.home-server.ru
   

   В секции ANSWER должен быть адрес 192.168.31.90 (LAN IP сервера). Если домены не резолвятся, проверьте записи в ~/vpn/dnsmasq.conf и перезапустите dnsmasq:

   sudo systemctl restart dnsmasq
   

Убедимся, что Nginx запущен и правильно фильтрует доступ по IP.

1. Для Docker-варианта:

   docker ps | grep nginx
   

   Ожидаем увидеть контейнер с именем nginx в статусе Up.

2. Для установки на хосте:

   sudo systemctl status nginx
   

   Ожидаем увидеть active (running) в выводе команды.

3. Тестируем блокировку доступа БЕЗ VPN:

   curl -I http://home-server.ru
   

   Ожидаем 403 Forbidden - это значит, что Nginx корректно блокирует доступ к защищённым доменам.

Финальная проверка всей цепочки с клиентского устройства (компьютер, телефон, планшет).

Подключаемся к VPN:

• Открываем приложение WireGuard на твоём устройстве

• Активируем подключение к серверу

• Должен появиться статус "Connected" или "Активно"

Проверяем доступ к защищённому домену:

• Открываем браузер

• Вводим в адресной строке: http://home-server.ru

• Должна открыться целевая страница

Если всё работает - поздравляем, защита настроена!

Проверяем блокировку без VPN:

• Отключаем VPN в приложении WireGuard

• Обновляем страницу в браузере или пробуем зайти снова на http://home-server.ru

• Должны получить ошибку подключения (браузер не может подключиться к сайту) или 403

Это подтверждает, что без VPN доступ действительно закрыт.

Симптомы:

• Приложение WireGuard показывает "Inactive" или "Handshake failed"

• Подключение зависает на "Activating..."

• Сразу после активации происходит отключение

Что проверить:

1 Порт 51820/UDP открыт на роутере?

Проверь настройки проброса портов на роутере (см. главу 2). Убедись, что:

• Порт 51820 UDP (не TCP!) пробросил на IP сервера

• IP сервера совпадает с тем, что указан в пробросе

2 Контейнер WireGuard запущен?На сервере про��ерь статус:

docker ps | grep vpn

Должен увидеть контейнер vpn в статусе Up. Если его нет:

cd ~/vpn
docker compose -f docker-compose.vpn.yml up -d

3 Интерфейс wg0 поднят?

Проверь на сервере:

ip a show wg0

Должен увидеть интерфейс с адресом 10.8.0.1/24 в состоянии UP.

Если интерфейса нет - перезапусти контейнер:

docker restart vpn

4 Firewall на сервере не блокирует порт?

Проверь, есть ли активный firewall:

sudo ufw status

Если активен - добавь правило для WireGuard:

sudo ufw allow 51820/udp
sudo ufw reload

5 Смотрим логи WireGuard

Логи контейнера покажут, в чём проблема:

docker logs vpn --tail 50

Симптомы:

• VPN подключается, но home-server.ru не открывается

• Браузер говорит "DNS_PROBE_FINISHED_NXDOMAIN"

• ping home-server.ru не находит хост

Что проверить:

1 DNS указан в клиентском конфиге?

Открой файл конфига на устройстве (в приложении WireGuard → Edit):

[Interface]
DNS = 10.8.0.1

Параметр DNS должен быть равен 10.8.0.1. Если его нет - добавь вручную и сохрани.

2 dnsmasq запущен на сервере?

Проверь статус:

sudo systemctl status dnsmasq

Должен быть active (running). Если нет:

sudo systemctl start dnsmasq
sudo systemctl enable dnsmasq

3 dnsmasq слушает на 10.8.0.1?

Проверь:

sudo ss -tulpn | grep ':53'

Должен увидеть dnsmasq на адресах 10.8.0.1:53 и 127.0.0.1:53.

Если не слушает на 10.8.0.1 - проверь конфиг ~/vpn/dnsmasq.conf:

cat ~/vpn/dnsmasq.conf

Должны быть строки:

listen-address=10.8.0.1
listen-address=127.0.0.1
interface=wg0

Если конфиг неправильный, исправь и перезапусти:

sudo systemctl restart dnsmasq

4 Домены прописаны в dnsmasq?

Проверь:

grep 'address=' ~/vpn/dnsmasq.conf

Должен увидеть:

address=/home-server.ru/192.168.31.90
address=/photos.home-server.ru/192.168.31.90

Если нет - добавь вручную (см. главу 4).

5 Тестируем резолвинг с сервера

На сервере выполни:

dig @10.8.0.1 home-server.ru

В секции ANSWER должен быть IP 192.168.31.90. Если нет - проблема в конфиге dnsmasq.

6 Тестируем резолвинг с клиента

На клиенте (с активным VPN):

macOS/Linux:

nslookup home-server.ru

Windows (PowerShell):

nslookup home-server.ru

Должен вернуть 192.168.31.90. Если возвращает другой IP или ошибку - DNS клиента не использует VPN.

1 Forbidden

Причина: Nginx видит IP клиента, который не входит в разрешённую подсеть 10.8.0.0/24.

Что проверить:

1. Клиент действительно получает IP из VPN?
   На клиенте с активным VPN:

   ip addr show wg0  # macOS/Linux
   

   Должен увидеть адрес типа 10.8.0.2/32.

2. Трафик идёт через туннель?
   Проблема с маршрутизацией (см. раздел 3.3). Проверь AllowedIPs в клиентском конфиге:

   AllowedIPs = 10.8.0.0/24, 192.168.31.90/32
   

   IP сервера должен быть с маской /32.

3. Nginx правильно настроен?
   Проверь конфиг Nginx:

   # Для Docker-варианта
   docker exec nginx cat /etc/nginx/nginx.conf
   

   # Для варианта на хосте
   sudo nginx -T | grep -A 10 "server_name home-server.ru"
   

   Должен увидеть:

   allow 10.8.0.0/24;
   deny  all;
   

4. Смотрим логи Nginx:

   # Docker-вариант
   docker logs nginx --tail 50
   
   # Хост-вариант
   sudo tail -f /var/log/nginx/error.log
   

   Ищи строки с IP клиента и причиной отказа.

2 Bad Gateway

Причина: Nginx не может достучаться до бэкенд-сервиса.

Что проверить:

1. Сервис запущен?
   Для Docker:

   docker ps | grep <имя_сервиса>
   

   Для процесса на хосте:

   sudo systemctl status <имя_сервиса>
   

2. Порт бэкенда открыт?
   Проверь, слушает ли сервис на нужном порту:

   sudo ss -tulpn | grep <порт>
   

3. Nginx правильно настроен?
   Проверь proxy_pass в конфиге:

   proxy_pass http://127.0.0.1:9000;  # или имя контейнера
   

   Для Docker-сети должно быть имя контейнера (http://myapp:9000).

3 Gateway Timeout

Причина: Сервис отвечает слишком долго (более 60 секунд).
Решение: Увеличь таймаут вNginx:

proxy_read_timeout 300;
proxy_connect_timeout 300;

Если не знаешь, с чего начать - проходи по этому списку сверху вниз:

Если ты прошёл весь чеклист, но проблема не решилась:

1. Перечитай раздел, в котором застрял - возможно, пропустил важную деталь

2. Собери информацию для диагностики:

   • Вывод docker ps

   • Вывод docker logs vpn --tail 100

   • Вывод sudo systemctl status dnsmasq

   • Скриншот настроек VPN-клиента

3. Напиши в комментариях с описанием проблемы и собранной информацией

4. Загляни в мой Telegram-канал - там я разберу твой кейс и по возможности помогу с проблемой.

Помни: 90% проблем решаются внимательным чтением логов и проверкой конфигов. Не спеши, всё получится!