Какие порты открыть для L2TP/IPsec VPN: полное руководство по настройке

Введение: почему L2TP/IPsec требует особого подхода к портам

L2TP/IPsec — одна из самых распространённых технологий VPN, но одновременно и одна из самых капризных в настройке. В отличие от WireGuard или OpenVPN, которые используют один порт, L2TP/IPsec опирается на комбинацию UDP-портов и отдельного IP-протокола. Ошибка хотя бы в одном элементе приводит к тому, что соединение не устанавливается, а диагностика превращается в долгий поиск.

Чтобы понять, какие порты открывать, нужно разобраться в архитектуре. L2TP (Layer 2 Tunneling Protocol) сам по себе не шифрует трафик — он лишь создаёт туннель. Вся безопасность обеспечивается поверх него протоколом IPsec, который отвечает за шифрование и аутентификацию. Поэтому для работы нужны порты и протоколы, относящиеся к обоим уровням: и к L2TP, и к IPsec.

В этой статье мы подробно разберём, какие именно порты и протоколы необходимы, как их открыть на разных платформах (Windows, MikroTik, Linux), как решить проблемы с NAT и почему даже при правильно открытых портах соединение может не работать.

Полный список портов и протоколов для L2TP/IPsec

Для корректной работы L2TP/IPsec VPN необходимо открыть следующие элементы:

• UDP 500 — используется протоколом IKE (Internet Key Exchange) для согласования ключей шифрования и аутентификации. Это первый этап установки соединения.
• UDP 1701 — порт самого L2TP, через который передаются данные туннеля. Важно: это UDP, а не TCP, как иногда ошибочно указывают.
• UDP 4500 — порт для NAT-T (Network Address Translation Traversal). Используется, когда клиент или сервер находятся за NAT, чтобы инкапсулировать IPsec-пакеты в UDP.
• ESP (IP-протокол 50) — Encapsulating Security Payload, протокол, который непосредственно шифрует данные. Это не порт, а отдельный IP-протокол, и правило для него создаётся иначе, чем для TCP/UDP.
• AH (IP-протокол 51) — Authentication Header, используется для аутентификации без шифрования. В большинстве конфигураций L2TP/IPsec не требуется, но иногда его тоже нужно разрешить.

Если сервер находится за NAT, порт 1701 пробрасывать не обязательно — достаточно открыть UDP 500 и 4500, так как весь трафик инкапсулируется в UDP 4500. Однако если сервер имеет белый IP-адрес и доступен напрямую, ESP должен быть разрешён.

Важно помнить: открытие портов — это только половина дела. Необходимо также настроить правила файрвола на всех уровнях: на самом сервере, на роутере (если есть NAT) и в облачной панели управления (если сервер виртуальный).

Настройка портов на Windows Server и Windows Firewall

Если L2TP/IPsec VPN сервер работает на Windows Server, нужно создать правила в Windows Defender Firewall. Проще всего это сделать через PowerShell, используя командлет New-NetFirewallRule.

Вот готовые команды для открытия всех необходимых портов:

New-NetFirewallRule -DisplayName "L2TP IKE Inbound" -Direction Inbound -Protocol UDP -LocalPort 500 -Action Allow -Profile Any
New-NetFirewallRule -DisplayName "L2TP NAT-T Inbound" -Direction Inbound -Protocol UDP -LocalPort 4500 -Action Allow -Profile Any
New-NetFirewallRule -DisplayName "L2TP Data Inbound" -Direction Inbound -Protocol UDP -LocalPort 1701 -Action Allow -Profile Any
New-NetFirewallRule -DisplayName "L2TP ESP Inbound" -Direction Inbound -Protocol 50 -Action Allow -Profile Any

Обратите внимание: для ESP используется -Protocol 50, а не -Protocol UDP или -Protocol TCP. Это отдельный IP-протокол, и Windows Firewall позволяет создавать такие правила.

Если вы используете графический интерфейс, создайте правила вручную: «Брандмауэр Защитника Windows» → «Правила для входящих подключений» → «Создать правило» → «Настраиваемые» → «Протокол и порты». Для UDP-портов укажите тип «UDP» и номера портов, для ESP — тип «Любой» и протокол 50.

После создания правил проверьте, что службы IKEEXT (IKE and AuthIP IPsec Keying Modules) и PolicyAgent (IPsec Policy Agent) запущены. Это можно сделать командой:

Get-Service IKEEXT, PolicyAgent

Если службы остановлены, запустите их и установите автоматический тип запуска.

Настройка портов на MikroTik RouterOS

MikroTik — популярная платформа для построения VPN-серверов, особенно в небольших и средних сетях. Настройка L2TP/IPsec на MikroTik требует не только открытия портов, но и создания правил IPsec.

Для начала создайте профиль PPP и включите L2TP-сервер:

/ppp profile add name=ipsec_vpn local-address=192.168.102.1 dns-server=1.1.1.1
/interface l2tp-server server set enabled=yes default-profile=ipsec_vpn authentication=mschap1,mschap2

Затем настройте IPsec peer и identity. Для RouterOS 6.44 и выше:

/ip ipsec peer add exchange-mode=main passive=yes name=l2tpserver
/ip ipsec identity add generate-policy=port-override auth-method=pre-shared-key secret="STRONG_SECRET_HERE" peer=l2tpserver

И, наконец, откройте порты в файрволе. Правила должны быть добавлены в начало списка, иначе они могут не сработать:

/ip firewall filter add chain=input action=accept protocol=udp port=1701,500,4500
/ip firewall filter add chain=input action=accept protocol=ipsec-esp

Обратите внимание: в MikroTik для ESP используется protocol=ipsec-esp, а не номер протокола. Если сервер находится за NAT, также нужно настроить NAT-T и проброс портов на внешнем роутере.

Если вы используете более старую версию RouterOS (до 6.44), команды для IPsec peer будут другими:

/ip ipsec peer add address=0.0.0.0/0 port=500 auth-method=pre-shared-key secret="STRONG_SECRET_HERE" exchange-mode=main-l2tp send-initial-contact=no generate-policy=port-override

После настройки не забудьте добавить пользователя:

/ppp secret add name="USERNAME" password="STRONG_PASSWORD" service=l2tp profile=ipsec_vpn remote-address=192.168.102.2

Настройка портов на Linux (iptables)

На Linux-серверах, использующих iptables, правила для L2TP/IPsec выглядят следующим образом:

iptables -A INPUT -i $EXT_NIC -p udp --dport 500 -j ACCEPT
iptables -A INPUT -i $EXT_NIC -p udp --dport 4500 -j ACCEPT
iptables -A INPUT -i $EXT_NIC -p 50 -j ACCEPT
iptables -A INPUT -i $EXT_NIC -p 51 -j ACCEPT
iptables -A INPUT -i $EXT_NIC -p udp -m policy --dir in --pol ipsec -m udp --dport 1701 -j ACCEPT

Здесь $EXT_NIC — имя внешнего сетевого интерфейса (например, eth0). Последнее правило с -m policy разрешает входящие L2TP-пакеты только в том случае, если они уже прошли IPsec-обработку — это повышает безопасность.

Если вы используете nftables, синтаксис будет другим, но принцип тот же: разрешить UDP 500, 4500, 1701 и протоколы 50/51.

Важно: на Linux также нужно убедиться, что модули ядра для IPsec загружены (например, xfrm), и что службы strongSwan или libreswan запущены.

Проблемы с NAT и двойным NAT: как их решить

Одна из самых частых причин, почему L2TP/IPsec не работает, — это NAT. Протокол IPsec изначально не поддерживает NAT, потому что ESP-пакеты не содержат информации о портах, и NAT-устройства не могут корректно преобразовывать адреса. Для решения этой проблемы был разработан NAT-T (NAT Traversal), который инкапсулирует ESP-пакеты в UDP-дейтаграммы на порту 4500.

NAT-T включён по умолчанию в большинстве операционных систем (iOS, Android, Linux), но в Windows его нужно активировать вручную, если сервер или клиент находятся за NAT. Для этого необходимо изменить параметр реестра AssumeUDPEncapsulationContextOnSendRule.

Вот как это сделать:

1. Откройте редактор реестра (regedit.exe).
2. Перейдите в ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent (для Windows 10/11 и Windows Server 2016+).
3. Создайте DWORD-параметр с именем AssumeUDPEncapsulationContextOnSendRule.
4. Установите значение:

• 0 — если сервер не за NAT (по умолчанию);
• 1 — если сервер за NAT;
• 2 — если и сервер, и клиент за NAT.

1. Перезагрузите компьютер.

Эту же операцию можно выполнить через PowerShell:

Set-ItemProperty -Path "HKLM:SYSTEM\CurrentControlSet\Services\PolicyAgent" -Name "AssumeUDPEncapsulationContextOnSendRule" -Type DWORD -Value 2 -Force

Если и сервер, и клиент находятся за NAT (двойной NAT), параметр нужно установить на обоих машинах. В этом случае порт 1701 пробрасывать не нужно — весь трафик идёт через UDP 4500.

Ещё одна распространённая проблема — несколько Windows-клиентов за одним NAT не могут одновременно подключиться к одному L2TP/IPsec серверу. Это известный баг Windows, который проявляется ошибками 809 или 789. Решение — изменить два параметра реестра в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\Parameters:

reg add "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rasman\Parameters" /v AllowL2TPWeakCrypto /t REG_DWORD /d 1 /f
reg add "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rasman\Parameters" /v ProhibitIpSec /t REG_DWORD /d 0 /f

После этого перезагрузите компьютер. Эти изменения разрешают использование слабых алгоритмов шифрования (MD5, DES) и включают IPsec, что позволяет нескольким клиентам подключаться через общий внешний IP.

Типичные ошибки и их диагностика

Даже при правильно открытых портах L2TP/IPsec может не работать. Рассмотрим самые частые ошибки и способы их диагностики.

Ошибка 800, 794, 809 — «Не удается установить связь между компьютером и VPN-сервером». Эта ошибка появляется, когда сервер не отвечает. Причины могут быть разными: неправильный адрес сервера, закрытые порты, блокировка провайдером. Проверьте, что порты UDP 500, 1701, 4500 и протокол ESP открыты на всех уровнях (файрвол ОС, роутер, облачная панель).

Ошибка 789 — «Попытка L2TP-подключения не удалась из-за ошибки на уровне безопасности». Часто возникает при проблемах с IPsec-согласованием. Убедитесь, что на клиенте и сервере используются совместимые алгоритмы шифрования и аутентификации. Также проверьте, что службы IKEEXT и PolicyAgent запущены.

Ошибка 809 — часто связана с NAT. Если сервер за NAT, настройте параметр AssumeUDPEncapsulationContextOnSendRule как описано выше.

Для диагностики полезно включить логирование файрвола. В Windows это можно сделать командой:

Set-NetFirewallProfile -LogBlocked True

Затем посмотрите журнал блокировок. Если пакеты не доходят до сервера, проблема может быть на стороне провайдера или в облачном файрволе.

Также проверьте, какие порты реально слушает сервер:

Get-NetUDPEndpoint | Where-Object {$_.LocalPort -in 500,1701,4500}

Если порты не прослушиваются, значит, служба VPN не запущена или настроена неправильно.

Проверка доступности портов и протоколов

После настройки портов важно убедиться, что они действительно доступны извне. Для этого можно использовать несколько инструментов.

Проверка UDP-портов — стандартные утилиты вроде telnet не работают с UDP, поэтому используйте nc (netcat) или специализированные сервисы. Например, на Linux:

nc -u -vz <server_ip> 500
nc -u -vz <server_ip> 4500
nc -u -vz <server_ip> 1701

Проверка ESP — ESP не является портом, поэтому проверить его сложнее. Можно использовать tcpdump на сервере, чтобы увидеть входящие ESP-пакеты:

tcpdump -i eth0 proto 50

Если пакеты приходят, значит, ESP разрешён.

Проверка с помощью PortQry — утилита от Microsoft, которая поддерживает UDP. Скачайте её и выполните:

portqry -n <server_ip> -e 500 -p UDP
portqry -n <server_ip> -e 4500 -p UDP
portqry -n <server_ip> -e 1701 -p UDP

Если порты закрыты, вы увидите сообщение «Filtered» или «Not listening».

Также можно использовать онлайн-сервисы проверки портов, но они обычно проверяют только TCP, поэтому для UDP они не подходят.

Если порты открыты, но VPN всё равно не работает, проверьте настройки IPsec: совпадение pre-shared key, алгоритмы шифрования, типы аутентификации. Часто проблема именно в несовпадении параметров.

Безопасность: почему не стоит открывать лишние порты

Открытие портов — это всегда увеличение поверхности атаки. Поэтому не рекомендуется открывать все порты сразу «на всякий случай». Открывайте только те порты, которые реально использует ваш VPN-сервер.

Для L2TP/IPsec минимальный набор — UDP 500, 4500, 1701 и ESP 50. Если вы используете только IKEv2, порт 1701 не нужен. Если сервер не за NAT, порт 4500 может не понадобиться, но лучше оставить его открытым для совместимости.

Также важно ограничить доступ к портам по IP-адресам, если это возможно. Например, в Windows Firewall можно указать список разрешённых удалённых IP-адресов. Это снизит риск сканирования портов и атак.

Не забывайте про обновления: регулярно обновляйте операционную систему и VPN-сервер, чтобы закрыть известные уязвимости. Используйте сильные pre-shared keys и сертификаты вместо паролей, если это возможно.

И помните: открытые порты — это не только про доступ, но и про ответственность. Неправильная настройка может привести к несанкционированному доступу в вашу сеть.

Заключение: чек-лист для успешной настройки

Чтобы L2TP/IPsec VPN заработал, выполните следующие шаги:

1. Определите, где находится сервер — за NAT или с белым IP. Это определит, нужно ли открывать ESP и пробрасывать порт 1701.
2. Откройте порты на сервере — UDP 500, 4500, 1701 и ESP 50 (если сервер не за NAT). Используйте команды для вашей ОС.
3. Настройте NAT-T — если сервер или клиент за NAT, установите параметр AssumeUDPEncapsulationContextOnSendRule в реестре Windows.
4. Проверьте службы — убедитесь, что IKEEXT и PolicyAgent запущены.
5. Проверьте доступность портов — используйте netcat, PortQry или tcpdump.
6. Проверьте настройки клиента — тип туннеля L2TP/IPsec, pre-shared key, протокол аутентификации (обычно MS-CHAP v2).
7. Если не работает — включите логирование файрвола и посмотрите, доходят ли пакеты до сервера.

Следуя этому чек-листу, вы сможете настроить L2TP/IPsec VPN даже в сложных сетевых условиях. Если проблема остаётся, обратитесь к документации вашего VPN-сервера или к сообществу администраторов.

Вопросы и ответы