Я хочу настроить Windows Server 2012 и его клиенты Windows 7 и Windows 8 VPN с SSTP VPN, использующей раздельное туннелирование и адресацию вне подсети, но я столкнулся с проблемой: сервер RRAS не будет отправлять пакеты в VPN клиенты с любой машины, кроме себя.
Мой VPN-сервер работает в «Виртуальном частном облаке» Amazon, поэтому у него есть только один сетевой адаптер с IP-адресом в частной сети RFC1918, доступной для всех моих других серверов Amazon VPC, и открытый IP-адрес, который перенаправляет весь трафик на этот частный адрес. через NAT (Amazon называет это «Эластичный IP»).
Я установил RRAS и настроил VPN. Частная подсеть на Amazon - 172.16.0.0/17 (это то, что я называю «Amazon LAN»), но я хочу, чтобы все VPN-клиенты использовали диапазон 10.128.0.0/20 (то, что я называю «» VPN LAN ").
В моей панели управления Amazon я сделал следующее:
- Отключена проверка источника / назначения для VPN-сервера
- Добавлена запись в таблицы маршрутов для пула 10.128.0.0/20, которая указывает на сетевой интерфейс VPN-сервера.
Внутри MMC Routing and Remote Access, внутри меню свойств для имени сервера, я сделал следующее:
- Вкладка «Общие» -> Маршрутизатор IPv4 (проверено), включена для локальной сети и маршрутизации вызова по требованию
- Вкладка «Общие» -> IPv4-сервер удаленного доступа (проверено)
- Вкладка IPv4 -> Включить пересылку IPv4 (проверено)
- Вкладка IPv4 -> Пул статических адресов и укажите 10.128.0.1-10.128.15.154
На моем клиенте и на всех моих серверах я убедился, что ICMP явно разрешен в брандмауэре или брандмауэр полностью отключен (конечно, не постоянный план).
На клиенте, чтобы включить раздельное туннелирование, я зашел в свойства VPN-подключения -> Сеть -> IPv4 -> Свойства -> Дополнительно -> вкладка «Настройки IP» и снял флажок «Использовать шлюз по умолчанию в удаленной сети», и проверил "Отключить добавление маршрута на основе класса".
На этом этапе мои клиенты могут подключаться с помощью VPN-клиента Windows 7/8. Им назначается IP-адрес из пула 10.128.0.0/20, но, поскольку они не устанавливают автоматически какие-либо маршруты, они не могут общаться с удаленной сетью. Я могу установить маршруты к удаленной сети и к сети VPN следующим образом (на клиенте):
route add 172.16.0.0/17 <VPN IP ADDRESS>
route add 10.128.0.0/20 <VPN IP ADDRESS>
Теперь клиент может пропинговать адрес VPN LAN VPN сервера VPN (10.128.0.1), а также свой адрес Amazon LAN (172.16.1.32). Однако при попытке соединения с другими компьютерами в локальной сети Amazon возникает проблема: эхо-запросы не получают ответы.
Так, например, если клиент пытается проверить связь с системой, о которой я знаю, что она работает, и отвечает на запросы ping, такие как 172.16.0.113, он не увидит эти ответы (он говорит «Тайм-аут запроса»). Wireshark на VPN-сервере подтверждает, что он видит эхо-запрос от клиента и даже видит ответ, отправленный с 172.16.0.113, но этот ответ, очевидно, никогда не вернется к клиенту.
Более того, если я пингую VPN-адрес клиента с 172.16.0.113, Wireshark на VPN-сервере увидит пинг, но не увидит ответ.
Итак, резюмируем:
- Сервер VPN может пропинговать другие машины в локальной сети Amazon (172.16.0.0/17) и получать ответы, и другие машины в этой сети могут делать то же самое с ним.
- Клиент VPN может пропинговать адрес сервера Amazon LAN и получать ответы после того, как клиенты добавят правильный маршрут, как описано ранее.
- Клиент VPN может пропинговать адрес VPN LAN LAN сервера 10.128.0.1, а сервер VPN может пропинговать адрес VPN LAN LAN клиента в диапазоне 10.128.0.0/20, после того как клиент добавит маршрут, соответствующий правильному маршруту, как описано ранее.
- VPN-клиент может отправлять эхо-запросы на компьютер в локальной сети Amazon, но когда эти машины отправляют ответы, они останавливаются на VPN-сервере - они не перенаправляются клиенту, что приводит к появлению на клиенте сообщений «Время ожидания истекло» , И наоборот, когда машина в локальной сети Amazon пытается пропинговать адрес VPN-клиента 10.128.0.0/20 VPN, сервер VPN видит эхо-запрос, но клиент этого не делает и поэтому не генерирует ответ.
Почему VPN-сервер не отправляет пакеты из Amazon LAN своим клиентам в VPN-сети? Он может определенно общаться с клиентами в VPN LAN, и маршрутизация включена, и он готов маршрутизировать пакеты из VPN LAN -> Amazon LAN, но не наоборот. Что мне здесь не хватает?
Маршруты
Вот таблицы маршрутизации от VPN-клиента. Клиент - виртуальная машина VirtualBox под управлением Windows 8. Его IP-адрес адаптера vbox - 10.0.2.15 в / 24. Этот клиент находится за NAT (на самом деле он за двойным NAT, потому что адаптер vbox настроен на NAT для моей локальной сети, а для NAT - на Интернет). Эта таблица маршрутов создана после добавления маршрутов вручную к 10.128.0.0/20 и 172.16.0.0/17.
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.0.2.2 10.0.2.15 10
10.0.2.0 255.255.255.0 On-link 10.0.2.15 266
10.0.2.15 255.255.255.255 On-link 10.0.2.15 266
10.0.2.255 255.255.255.255 On-link 10.0.2.15 266
10.128.0.0 255.255.240.0 On-link 10.128.0.3 15
10.128.0.3 255.255.255.255 On-link 10.128.0.3 266
10.128.15.255 255.255.255.255 On-link 10.128.0.3 266
54.213.67.179 255.255.255.255 10.0.2.2 10.0.2.15 11
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
172.16.0.0 255.255.128.0 On-link 10.128.0.3 15
172.16.127.255 255.255.255.255 On-link 10.128.0.3 266
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 10.0.2.15 266
224.0.0.0 240.0.0.0 On-link 10.128.0.3 266
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 10.0.2.15 266
255.255.255.255 255.255.255.255 On-link 10.128.0.3 266
===========================================================================
Persistent Routes:
None
Вот таблицы маршрутизации от сервера RRAS, на котором работает Windows Server 2012. Этот сервер также находится за NAT, как обсуждалось выше. У него только один NIC. Его частный IP-адрес - 172.16.1.32 в / 23 (который сам является частью более крупной сети / 17; я считаю, что будет справедливо игнорировать части / 17 вне / 23, поскольку другие машины в / 23 не может достигнуть или быть достигнутым клиентами VPN также).
Виртуальный адаптер VPN имеет собственный адрес 10.128.0.1, который назначается автоматически при первом подключении клиента. Маршруты для 10.128.0.1 (для себя) и 10.128.0.2 (для его единственного клиента), которые вы видите, также добавляются автоматически в это время. На VPN-сервер маршруты не добавляются вручную.
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 172.16.0.1 172.16.1.32 10
10.128.0.1 255.255.255.255 On-link 10.128.0.1 286
10.128.0.2 255.255.255.255 10.128.0.2 10.128.0.1 31
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
169.254.169.250 255.255.255.255 172.16.0.1 172.16.1.32 10
169.254.169.251 255.255.255.255 172.16.0.1 172.16.1.32 10
169.254.169.254 255.255.255.255 172.16.0.1 172.16.1.32 10
172.16.0.0 255.255.254.0 On-link 172.16.1.32 11
172.16.1.32 255.255.255.255 On-link 172.16.1.32 266
172.16.1.255 255.255.255.255 On-link 172.16.1.32 266
172.16.2.0 255.255.254.0 172.168.0.1 172.16.1.32 11
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 172.16.1.32 266
224.0.0.0 240.0.0.0 On-link 10.128.0.1 286
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 172.16.1.32 266
255.255.255.255 255.255.255.255 On-link 10.128.0.1 286
===========================================================================
Persistent Routes:
None
Вот таблицы маршрутизации для другого компьютера в частной сети сервера, также работающего под управлением Server 2012. Он имеет одну сетевую карту с частным IP-адресом 172.16.1.177, что означает, что он находится на том же / 23, что и сервер VPN. (Обратите внимание, что маршрут к 10.128.0.0/20 установлен на шлюзе, который контролируется Amazon, поэтому вы не увидите его здесь. Я добавил правильный маршрут к Amazon, о чем свидетельствует тот факт, что Wireshark на VPN-сервер видит пакеты.)
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 172.16.0.1 172.16.1.177 10
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
169.254.169.250 255.255.255.255 172.16.0.1 172.16.1.177 10
169.254.169.251 255.255.255.255 172.16.0.1 172.16.1.177 10
169.254.169.254 255.255.255.255 172.16.0.1 172.16.1.177 10
172.16.0.0 255.255.254.0 On-link 172.16.1.177 266
172.16.1.177 255.255.255.255 On-link 172.16.1.177 266
172.16.1.255 255.255.255.255 On-link 172.16.1.177 266
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 172.16.1.177 266
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 172.16.1.177 266
===========================================================================
Persistent Routes:
None
Вот маршруты в консоли Amazon. Я думаю , что это правильно - трафик будет сделать его обратно на сервер VPN, в конце концов, только исчезнуть внутри него - но в случае , если кто - то хочет , чтобы увидеть их, вот они. (Amazon делает некоторые вещи немного странно. eni-2f3e8244 / i-77e26440
Относится к сетевому адаптеру на сервере VPN и igw-d4bc27bc
относится к контролируемому Amazon интернет-NAT / шлюзу, который все мои экземпляры используют для связи с Интернетом.)
10.128.0.0/20 eni-2f3e8244 / i-77e26440
172.16.0.0/17 local
0.0.0.0/0 igw-d4bc27bc
route print
и tracert
вывод - и внес важные исправления в некоторые сведения, добавленные ранее. (Спасибо за помощь!)