Не работает nat vpn

Дом.ru посадил всех за NAT: какие проблемы это принесло и как вернуть нормальный режим работы

Полагаю, многие из вас подключены к сети Интернет через провайдера Дом.ru. Можно по-разному относиться к этому поставщику услуг связи. Я и сам долго был их клиентом, старался бороться с постоянным повышением тарифов, а потом мне это всё надоело и расторг договор, но речь сегодня не об этом.

Не так давно, Дом.ru подключил всем своим абонентам функцию NAT. Особо это не афишировалось и преподнесли они это новшество под видом заботы о безопасности клиентов. На самом же деле, банально не хватает «белых» IP-адресов и мы получаем частные «серые» IP адреса.

Что такое NAT? Это сокращение от Network Address Translation или преобразование сетевых адресов. Если по-простому, то есть частные (домашние) и глобальные (Интернет) сети. В глобальной сети, свободные сетевые адреса давно кончились, потому мы пользуемся частными и NAT позволяет взаимодействовать вашей домашней сети с Интернетом.

Ничего страшного в этом разумеется нет, как таковой NAT вы используете постоянно (любой домашний роутер работает по такому же принципу, раздавая частные сетевые адреса внутри домашней сети). Строго говоря, если у вас есть роутер, то вы и так сидите за NAT. Но в данном случае у нас получается двойное преобразование адресов и это может вызывать проблемы.

При активированном NAT на стороне Дом.ru было замечено, что не работает подключение к видеонаблюдению (нет картинки в довольно популярном приложении SPYMAX, хотя пишет что соединение с камерами установлено). Аналогичным образом не работает VPN подключение по протоколу L2TP — соединение устанавливается, а пакеты не проходят.

Можно долго ковыряться в настройках своего роутера, выискиваю несуществующую проблему у себя, но на самом деле нужно в личном кабинете Дом.ru в разделе «Сервисные настройки» отключить функцию NAT для корректной работы.

Следует заметить, что изменения происходят не тут же после нажатия соответствующей кнопки в личном кабинете, а в течение примерно получаса. Точного времени сказать не могу, это вопрос к техническим специалистам Дом.ru, как они настроили своё оборудование. Так что учитывайте этот момент и не рассчитывайте на мгновенный эффект. Кроме того, роутер желательно перезагрузить.

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

Комментариев: 1

Спасибо тебе добрый человек! Весь мозг сломал, почему порт прокидываю через роутер, а его из вне не видно! Благодарю!

Источник

Исправляем проблему подключения к L2TP/IPSec VPN серверу за NAT

Столкнулись с интересной проблемой у одного из заказчиков после перенастройки VPN сервера Windows Server 2012 с PPTP на L2TP/ IPSec (из за отключения поддержки PPTP VPN в iOS). Изнутри корпоративной сети VPN клиенты без каких-либо проблем подключаются к VPN серверу, а вот внешние Windows клиенты при попытке установить соединение с L2TP VPN сервером, выдают такую ошибку:

The network connection between your computer and the VPN server could not be established because the remote server is not responding. This could be because one of the network devices (e.g. firewalls, NAT, routers, etc) between your computer and the remote server is not configured to allow VPN connections. Please contact your Administrator or your service provider to determine which device may be causing the problem.

В других версиях Windows о наличии аналогичной проблемы могут свидетельствовать ошибки VPN подключения 800, 794 или 809.

Стоит отметить, что данный VPN сервер находится за NAT, а на маршрутизаторе настроен проброс портов, необходимых для работы L2TP:

• UDP 1701 — Layer 2 Forwarding Protocol (L2F) & Layer 2 Tunneling Protocol(L2TP)
• UDP 500
• UDP 4500 NAT-T – IPSec Network Address Translator Traversal
• Protocol 50 ESP

В правилах Windows Firewall VPN сервера эти порты также открыты. Т.е. используется классическая конфигурация. Для подключения используется встроенный VPN клиент Windows.

VPN ошибка 809 для L2TP/IPSec в Windows за NAT

Как оказалось, проблема эта уже известна и описана в статье https://support.microsoft.com/en-us/kb/926179. По умолчанию встроенный VPN клиент Windows не поддерживает подключение к L2TP/IPsec через NAT. Дело в том, что IPsec использует протокол ESP (Encapsulating Security Payload) для шифрования пакетов, а протокол ESP не поддерживает PAT (Port Address Translation). Если вы хотите использовать IPSec для коммуникации, Microsoft рекомендует использовать белые IP адреса на VPN сервере.

Но есть и обходное решение. Можно исправить этот недостаток, включив поддержку протокола NAT—T, который позволяет инкапсулировать пакеты протокола ESP 50 в UDP пакеты по порту 4500. NAT-T включен по-умолчанию почти во всех операционных системах (iOS, Android, Linux), кроме Windows.

Если VPN сервер L2TP/IPsec находится за NAT, то для корректного подключения внешних клиентов через NAT необходимо на стороне Windows сервера и клиента внести изменение в реестр, разрешающее UDP инкапсуляцию пакетов для L2TP и поддержку (NAT-T) для IPsec.

1. Откройте редактор реестра regedit.exe и перейдите в ветку:
   • Для Windows 10,8.1,7 и Windows Server 2016,2012R2,2008R2 — HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent
   • Для Windows XP/Windows Server 2003 — HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSec
2. Создайте DWORD параметр с именем AssumeUDPEncapsulationContextOnSendRule и значением 2;
   

• 0 – (значение по-умолчанию), предполагается, что VPN сервер подключен к интернету без NAT;
• 1 – VPN сервер находится за NAT;
• 2 — и VPN сервер и клиент находятся за NAT.

Set-ItemProperty -Path «HKLM:SYSTEM\CurrentControlSet\Services\PolicyAgent» -Name «AssumeUDPEncapsulationContextOnSendRule» -Type DWORD -Value 2 –Force;

После включения поддержки NAT-T, вы сможете успешно подключаться к VPN серверу с клиента через NAT (в том числе двойной NAT).

L2TP VPN не работает на некоторых Windows компьютерах в локальной сети

Есть еще один интересный баг. Если в вашей локальной сети несколько Windows компьютеров, вы не сможете установить более одного одновременного подключения к внешнему L2TP/IPSec VPN серверу. Если при наличии активного VPN туннеля с одного клиента, вы попытаетесь подключиться к тому же самому VPN серверу с другого компьютера, появится ошибка с кодом 809 или 789:

По информации на TechNet проблема связана с некорректной реализацией клиента L2TP/IPSec клиента в Windows (не исправляется уже много лет).

Для исправления этого бага нужно изменить два параметра реестра в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\Parameters и перезагрузите компьютре:

• AllowL2TPWeakCrypto – изменить на 00000001 (ослабляет уровень шифрования, для L2TP/IPSec используются алгоритмы MD5 и DES)
• ProhibitIPSec – изменить на 00000000 (включает шифрование IPsec, которое часто отключается некоторыми VPN клиентами или утилитами)

Для изменения этих параметров реестра достаточно выполнить команды:
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

Это включает поддержку нескольких одновременных L2TP/IPSec-подключений в Windows через общий внешний IP адрес (работает на всех версиях, начиная с Windows XP и заканчивая Windows 10).

Источник

Не устанавливается VPN соединение через NAT/

Друзья, есть проблема. В Новый год переставил шлюз на debian. Сейчас стоит Linux emmproxy 2.4.27-2-386 #1 Wed Aug 17 09:33:35 UTC 2005 i686 GNU/Linux.
При подключении соединения VPN к налоговой (для отсылки отчетности), соединение не устанавливается.

В iptables разрешил все порты, в т.ч. и 1723. telnet идет на этот порт без проблем. При подсоединении виндовое соединение происходит нормально, идет аутентификация, но затем все отваливается по тайм-ауту. Есть подозрение , что нужен модуль ip_nat_gre, но у меня в инсталляции его нет и в помине. Пожалуйста наставьте на путь истинный!

В логах tcpdump при подключении:

# tcpdump host 192.168.0.134
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
12:18:57.626977 arp who-has 192.168.0.134 tell 192.168.0.100
12:18:58.592749 arp who-has 192.168.0.1 tell 192.168.0.134
12:18:58.592768 arp reply 192.168.0.1 is-at 00:02:b3:cc:7c:af
12:18:58.592874 IP 192.168.0.134.1431 > 213.182.169.11.1723: S 3504288852:3504288852(0) win 65535
12:18:58.625223 IP 213.182.169.11.1723 > 192.168.0.134.1431: S 1984623213:1984623213(0) ack 3504288853 win 65535
12:18:58.626519 IP 192.168.0.134.1431 > 213.182.169.11.1723: P 1:157(156) ack 1 win 65535: pptp CTRL_MSGTYPE=SCCRQ PROTO_VER(1.0) FRAME_CAP(A) BEARER_CAP(A) MAX_CHAN(0) FIRM_REV(2600) [|pptp]
12:18:58.663913 IP 213.182.169.11.1723 > 192.168.0.134.1431: P 1:157(156) ack 157 win 65535: pptp CTRL_MSGTYPE=SCCRP PROTO_VER(1.0) RESULT_CODE(1) ERR_CODE(0) FRAME_CAP(S) BEARER_CAP(DA) MAX_CHAN(0) FIRM_REV(257) [|pptp]
12:18:58.665198 IP 192.168.0.134.1431 > 213.182.169.11.1723: P 157:325(168) ack 157 win 65379: pptp CTRL_MSGTYPE=OCRQ CALL_ID(32768) CALL_SER_NUM(15869) MIN_BPS(300) MAX_BPS(100000000) BEARER_TYPE(Any) FRAME_TYPE(E) RECV_WIN(64) PROC_DELAY(0) PHONE_NO_LEN(0) [|pptp]
12:18:58.799041 IP 213.182.169.11.1723 > 192.168.0.134.1431: . ack 325 win 65535
12:19:03.622870 arp who-has 192.168.0.134 tell 192.168.0.1
12:19:03.623001 arp reply 192.168.0.134 is-at 00:0c:76:5e:11:92
12:19:03.758271 IP 213.182.169.11.1723 > 192.168.0.134.1431: P 157:189(32) ack 325 win 65535: pptp CTRL_MSGTYPE=OCRP CALL_ID(15007) PEER_CALL_ID(32768) RESULT_CODE(1) ERR_CODE(0) CAUSE_CODE(0) CONN_SPEED(64000) RECV_WIN(16) PROC_DELAY(1) PHY_CHAN_ID(1507328)
12:19:03.868767 IP 192.168.0.134.1431 > 213.182.169.11.1723: . ack 189 win 65347
12:19:03.950154 IP 192.168.0.134.1431 > 213.182.169.11.1723: P 325:349(24) ack 189 win 65347: pptp CTRL_MSGTYPE=SLI PEER_CALL_ID(15007) SEND_ACCM(0xffffffff) RECV_ACCM(0xffffffff)
12:19:03.953991 IP 192.168.0.134 > 213.182.169.11: call 15007 seq 0 gre-ppp-payload
12:19:04.077281 IP 213.182.169.11.1723 > 192.168.0.134.1431: . ack 349 win 65535
12:19:05.947779 IP 192.168.0.134 > 213.182.169.11: call 15007 seq 1 gre-ppp-payload
12:19:08.948762 IP 192.168.0.134 > 213.182.169.11: call 15007 seq 2 gre-ppp-payload
12:19:12.947611 IP 192.168.0.134 > 213.182.169.11: call 15007 seq 3 gre-ppp-payload
12:19:16.947595 IP 192.168.0.134 > 213.182.169.11: call 15007 seq 4 gre-ppp-payload
12:19:20.947441 IP 192.168.0.134 > 213.182.169.11: call 15007 seq 5 gre-ppp-payload
12:19:23.932392 IP 213.182.169.11.1723 > 192.168.0.134.1431: P 189:205(16) ack 349 win 65535: pptp CTRL_MSGTYPE=StopCCRQ REASON(3)
12:19:23.932564 IP 192.168.0.134.1431 > 213.182.169.11.1723: P 349:365(16) ack 205 win 65331: pptp CTRL_MSGTYPE=StopCCRP RESULT_CODE(1) ERR_CODE(0)
12:19:23.935846 IP 213.182.169.11.1723 > 192.168.0.134.1431: P 205:353(148) ack 349 win 65535: pptp CTRL_MSGTYPE=CDN CALL_ID(15007) RESULT_CODE(3) ERR_CODE(0) CAUSE_CODE(0) [|pptp]
12:19:24.098434 IP 213.182.169.11.1723 > 192.168.0.134.1431: F 353:353(0) ack 365 win 65535
12:19:24.098608 IP 192.168.0.134.1431 > 213.182.169.11.1723: F 365:365(0) ack 354 win 65183
12:19:24.168897 IP 213.182.169.11.1723 > 192.168.0.134.1431: . ack 366 win 65534

27 packets captured
27 packets received by filter
0 packets dropped by kernel

# lsmod
Module Size Used by Not tainted
ip_gre 7488 0 (unused)
nls_iso8859-1 2780 0 (autoclean)
isofs 23092 0 (autoclean)
ip_conntrack_ftp 3440 1 (autoclean)
ip_nat_ftp 2512 0 (unused)
af_packet 11048 0 (autoclean)
ipt_REJECT 3160 0 (autoclean)
ipt_state 504 54 (autoclean)
iptable_filter 1644 1 (autoclean)
ipt_MASQUERADE 1304 5 (autoclean)
ipt_mark 472 8 (autoclean)
iptable_nat 14758 2 (autoclean) [ip_nat_ftp ipt_MASQUERADE]
ip_conntrack 17000 1 (autoclean) [ip_conntrack_ftp ip_nat_ftp ipt_state ipt_MASQUERADE iptable_nat]
ipt_MARK 728 8 (autoclean)
iptable_mangle 2040 1 (autoclean)
ip_tables 10400 10 [ipt_REJECT ipt_state iptable_filter ipt_MASQUERADE ipt_mark iptable_nat ipt_MARK iptable_mangle]
ehci-hcd 14764 0 (unused)
usb-uhci 19504 0 (unused)
usbcore 52268 1 [ehci-hcd usb-uhci]
i810_audio 21372 0 (unused)
ac97_codec 11252 0 [i810_audio]
soundcore 3268 2 [i810_audio]
ide-scsi 8272 0
scsi_mod 86052 1 [ide-scsi]
8139too 12328 1
mii 1952 0 [8139too]
crc32 2848 0 [8139too]
e100 42868 1
ide-cd 27072 0
cdrom 26212 0 [ide-cd]
rtc 5768 0 (autoclean)
ext3 65388 3 (autoclean)
jbd 34628 3 (autoclean) [ext3]
ide-detect 288 0 (autoclean) (unused)
piix 7784 1 (autoclean)
ide-disk 12448 4 (autoclean)
ide-core 91832 4 (autoclean) [ide-scsi ide-cd ide-detect piix ide-disk]
unix 12752 104 (autoclean)

Источник

Устранение неполадок с подключением виртуальных частных сетевых клиентов Microsoft L2TP/IPSec

В этой статье описывается устранение неполадок с подключением виртуальной частной сети (VPN) L2TP/IPSec.

Применяется к: Windows 10 — все выпуски
Исходный номер КБ: 325034

Сводка

Прежде чем сделать VPN-подключение L2TP/IPSec, необходимо иметь подключение к Интернету. Если вы попробуете сделать VPN-подключение перед подключением к Интернету, у вас может возникнуть длинная задержка, обычно 60 секунд, а затем вы можете получить сообщение об ошибке, в результате чего не было ответа или что-то не так с модемом или другим устройством связи.

При устранении неполадок подключения L2TP/IPSec полезно понять, как происходит подключение L2TP/IPSec. При запуске подключения на сервер отправляется начальный пакет L2TP с запросом подключения. Этот пакет заставляет уровень IPSec на компьютере договариваться с VPN-сервером о том, чтобы настроить защищенный сеанс IPSec (ассоциация безопасности). В зависимости от многих факторов, включая скорость ссылок, переговоры по IPSec могут занять от нескольких секунд до двух минут. Когда создана ассоциация безопасности IPSec (SA), начинается сеанс L2TP. Когда она начинается, вы получаете запрос на имя и пароль (если подключение не настроено для автоматического подключения в Windows Millennium Edition.) Если VPN-сервер принимает ваше имя и пароль, настройка сеанса завершается.

Распространенный сбой конфигурации в соединении L2TP/IPSec — это неправильно сконфигурованный или отсутствующий сертификат или неправильно сконфигурованный или отсутствующий предустанавленный ключ. Если на уровне IPSec не удастся установить зашифрованный сеанс с VPN-сервером, он будет работать безмолвно. В результате уровень L2TP не видит ответа на запрос подключения. Задержка будет долгой, обычно 60 секунд, и тогда вы можете получить сообщение об ошибке, в результате чего на сервере не было ответа или не было ответа от модема или устройства связи. Если вы получили это сообщение об ошибке перед получением запроса на имя и пароль, IPSec не устанавливал сеанс. Если это произойдет, проверьте конфигурацию сертификата или предварительно предварительного ключа или отправьте журнал isakmp администратору сети.

Вторая распространенная проблема, которая препятствует успешному сеансу IPSec, — это использование сетевого перевода адресов (NAT). Во многих небольших сетях маршрутизатор с функциональными возможностями NAT используется для обмена одним интернет-адресом между всеми компьютерами в сети. Оригинальная версия IPSec сбрасывает подключение, которое проходит через NAT, так как обнаруживает адресное сопоставление NAT как подделывания пакетов. Домашние сети часто используют NAT. Это блокирует использование L2TP/IPSec, если клиент и шлюз VPN не поддерживают возникающий стандарт IPSec NAT-Traversal (NAT-T). Дополнительные сведения см. в разделе «Nat Traversal».

Если подключение сбой после получения запроса на имя и пароль, сеанс IPSec был создан, и, вероятно, что-то не так с вашим именем и паролем. Другие параметры сервера также могут препятствовать успешному подключению L2TP. В этом случае отправьте журнал PPP администратору.

NAT Traversal

При поддержке IPSec NAT-T в VPN-клиенте Microsoft L2TP/IPSec сеансы IPSec могут проходить через NAT, когда VPN-сервер также поддерживает IPSec NAT-T. IPSec NAT-T поддерживается Windows Server 2003. IPSec NAT-T также поддерживается Windows 2000 Server с обновлением L2TP/IPSec NAT-T для Windows XP и Windows 2000.

Для сторонних VPN-серверов и шлюзов обратитесь к администратору или поставщику шлюзов VPN, чтобы убедиться, что IPSec NAT-T поддерживается.

Дополнительная информация

Кроме того, в утилите конфигурации предусмотрена проверка, которая включает ведение журнала IPSec. Если вы не можете подключиться, и администратор сети или сотрудники службы поддержки обратились к вам с просьбой предоставить им журнал подключения, вы можете включить ведение журнала IPSec здесь. При этом журнал (Isakmp.log) создается в C:\Program Files\Microsoft IPSec VPN папке. При создании подключения также включить ведение журнала для обработки PPP в L2TP. Для этого:

1. Щелкните правой кнопкой мыши папку сети dialup и нажмите кнопку Свойства.
2. Щелкните вкладку Networking, а затем выберите запись файла журнала для этого окна подключения.

Источник