Миграция с PPTP на WireGuard: безопасный VPN без общего пароля

PPTP когда-то был удобным способом быстро дать сотруднику доступ во внутреннюю сеть, но сегодня его лучше не чинить, а планово заменить. Главная проблема не только в возрасте протокола: старые клиенты, GRE, сложный NAT и слабая модель защиты превращают поддержку в лотерею.

Ниже разберём миграцию на WireGuard. В итоге каждый пользователь получит отдельный ключ, доступ можно будет отзывать без смены общего пароля, а диагностика сведётся к понятным командам wg, ip route и tcpdump.

Что получится после миграции

• VPN-подсеть 10.20.0.0/24;
• отдельный ключ для каждого устройства;
• доступ к LAN 192.168.1.0/24;
• минимальный открытый порт UDP 51820;
• параллельная работа PPTP и WireGuard на время перехода;
• понятный план отключения старого VPN.

1. Фиксируем старую схему

Перед установкой нового VPN важно понять, кто и куда ходит через PPTP. Иначе после переключения быстро выяснится, что одному пользователю нужен RDP, другому — доступ к NAS, а третьему вообще требовался полный туннель.

ip -br addr
ip route
ss -lntup
iptables-save > /root/iptables-before-vpn.txt
find /etc/ppp /etc/pptpd.conf -maxdepth 3 -type f -print 2>/dev/null
cp -a /etc/ppp /root/ppp-backup-$(date +%F)

Сохраните список пользователей, VPN-подсеть и разрешённые внутренние сети. Этот этап даёт точку сравнения и позволяет вернуть старый сервис, если миграция затянется.

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

apt update
apt install -y wireguard qrencode
umask 077
wg genkey | tee /etc/wireguard/server.key | wg pubkey > /etc/wireguard/server.pub
cat /etc/wireguard/server.pub

Приватный ключ остаётся только на сервере. Публичный ключ можно свободно передавать клиентам. Если файл server.key утечёт, его нужно заменить, а не пытаться «спрятать обратно».

3. Создаём конфигурацию сервера

[Interface]
Address = 10.20.0.1/24
ListenPort = 51820
PrivateKey = SERVER_PRIVATE_KEY
PostUp = nft add rule inet filter forward iifname "wg0" oifname "lan0" ip daddr 192.168.1.0/24 accept
PostUp = nft add rule inet filter forward iifname "lan0" oifname "wg0" ip saddr 192.168.1.0/24 ct state established,related accept
PostDown = nft delete rule inet filter forward handle HANDLE_1
PostDown = nft delete rule inet filter forward handle HANDLE_2

В реальной конфигурации удобнее держать постоянные правила в /etc/nftables.conf, а не удалять их по handle. Здесь важна логика: разрешаем только трафик от VPN к нужной LAN, а не открываем весь сервер целиком.

cat > /etc/sysctl.d/99-wireguard.conf <<'EOF'
net.ipv4.ip_forward=1
EOF
sysctl --system
sysctl net.ipv4.ip_forward

Ожидаем значение 1. Без forwarding туннель поднимется, но клиент не сможет пройти дальше адреса VPN-сервера.

4. Создаём ключи клиента

install -d -m 700 /root/wg-clients/client1
cd /root/wg-clients/client1
wg genkey | tee private.key | wg pubkey > public.key
cat public.key

Один клиент — одна пара ключей. Это важное отличие от типичного PPTP с общими паролями: потерянный ноутбук можно отключить, не затрагивая остальных.

5. Добавляем peer на сервер

[Peer]
PublicKey = CLIENT1_PUBLIC_KEY
AllowedIPs = 10.20.0.10/32

Добавьте блок в /etc/wireguard/wg0.conf. Маска /32 закрепляет за клиентом один конкретный адрес и не позволяет ему заявить чужую VPN-подсеть.

6. Готовим клиентский профиль

[Interface]
PrivateKey = CLIENT1_PRIVATE_KEY
Address = 10.20.0.10/32
DNS = 192.168.1.1

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = vpn.example.ru:51820
AllowedIPs = 192.168.1.0/24,10.20.0.0/24
PersistentKeepalive = 25

Такой профиль создаёт split tunnel: через VPN идут только внутренняя сеть и сама VPN-подсеть. Интернет клиента остаётся через его обычное подключение. Для телефонов профиль удобно показать QR-кодом: qrencode -t ansiutf8 < client1.conf.

7. Запускаем и проверяем

systemctl enable --now wg-quick@wg0
systemctl status wg-quick@wg0 --no-pager
wg show
ss -lunp | grep 51820
ip addr show wg0

После подключения клиента в wg show должны появиться время последнего handshake и счётчики трафика. Если handshake есть, но LAN недоступна, ключи и порт уже работают — искать нужно в маршрутах или firewall.

ping -c 3 10.20.0.1
ping -c 3 192.168.1.1
ip route
traceroute 192.168.1.10

8. Диагностика без гадания

wg show
journalctl -u wg-quick@wg0 -b --no-pager
nft list ruleset
sysctl net.ipv4.ip_forward
tcpdump -ni any udp port 51820
tcpdump -ni wg0

Нет UDP-пакетов — проверяйте DNS, внешний firewall и проброс порта. Пакеты есть, но handshake отсутствует — обычно неверный ключ, endpoint или время. Handshake есть, но внутренний ресурс молчит — проверяйте forwarding, обратный маршрут и локальный firewall ресурса.

9. Переход пользователей и отключение PPTP

Не выключайте PPTP в первый день. Переведите одного пользователя, затем небольшую группу, проверьте RDP, файловые ресурсы, DNS и доступ с мобильного интернета. Когда все рабочие сценарии подтверждены, остановите старый сервис и закройте связанные правила firewall.

systemctl disable --now pptpd 2>/dev/null || true
ss -lntup
nft list ruleset

10. Откат

systemctl disable --now wg-quick@wg0
cp /root/iptables-before-vpn.txt /root/iptables-reference.txt
systemctl enable --now pptpd 2>/dev/null || true

Критерий успеха: у каждого пользователя свой профиль, handshake обновляется, нужные ресурсы LAN доступны, а старый PPTP больше не слушает сеть.