Назад | Перейти на главную страницу

Сервер Windows VPN может общаться с клиентами VPN, но не будет отправлять пакеты из своей локальной сети клиентам VPN.

Я хочу настроить Windows Server 2012 и его клиенты VPN для Windows 7 и Windows 8 с помощью 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 маршрутизации и удаленного доступа, в меню свойств для имени сервера, я сделал следующее:

Вкладка Общие -> Маршрутизатор IPv4 (отмечен), включен для LAN и маршрутизации по требованию
Вкладка Общие -> Сервер удаленного доступа IPv4 (отмечено)
Вкладка IPv4 -> Включить пересылку IPv4 (отмечено)
Вкладка IPv4 -> Пул статических адресов и укажите 10.128.0.1-10.128.15.154

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

На клиенте, чтобы включить раздельное туннелирование, я зашел в свойствах VPN-подключения -> Сеть -> IPv4 -> Свойства -> Дополнительно -> вкладка IP Settings и снял флажок «Использовать шлюз по умолчанию в удаленной сети», и проверил "Отключить добавление маршрута на основе классов".

На этом этапе мои клиенты могут подключаться с помощью 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 (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 сервера 10.128.0.1, а сервер VPN может пинговать адрес локальной сети VPN клиента в диапазоне 10.128.0.0/20 после того, как клиент добавит правильный маршрут маршрута, как описано ранее.
VPN-клиент может отправлять эхо-запросы на машину в локальной сети Amazon, но когда эти машины отправляют ответы, они останавливаются на VPN-сервере - они не пересылаются клиенту, в результате чего на клиенте появляются сообщения «Время ожидания запроса истекло». . И наоборот, когда машина в локальной сети Amazon пытается выполнить эхо-запрос по адресу локальной сети VPN 10.128.0.0/20 клиента, VPN-сервер видит эхо-запрос, но клиент никогда этого не делает и, следовательно, не генерирует ответ.

Почему сервер VPN не отправляет пакеты из локальной сети Amazon своим клиентам в локальной сети VPN? Он определенно может разговаривать с клиентами в локальной сети VPN, маршрутизация включена, и он готов маршрутизировать пакеты из локальной сети VPN -> ЛВС Amazon, но не наоборот. Что мне здесь не хватает?

Маршруты

Вот таблицы маршрутизации от 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, как обсуждалось выше. У него только одна сетевая карта. Его частный 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

Что, если вы добавите на свои серверы статический маршрут, сообщающий им, что для достижения 10.128.0.0/20 они должны пройти через LAN-адрес сервера VPN?

route add 10.128.0.0 mask 255.255.240.0 a.b.c.d

Замените a.b.c.d адресом локальной сети VPN-сервера.

Это как минимум исключит проблемы с маршрутизацией на Amazon.