Сервер Windows VPN может говорить с клиентами VPN, но не отправит пакеты от его локальной сети до клиентов VPN

Я хочу настроить Windows Server 2012 и его клиентов VPN Windows 7 и Windows 8, с VPN SSTP, которая использует раздельное туннелирование и обращение вне подсети, но я сталкиваюсь с проблемой: сервер RRAS не отправит пакеты в клиентов VPN ни от какой машины кроме себя.

Мой сервер VPN работает на "Виртуальном частном облаке" Amazon, таким образом, это имеет только один NIC с IP-адресом в частной, сети RFC1918, совместно использованной со всеми моими другими серверами VPC Amazon и общедоступным IP, который передает весь трафик к тому частному адресу через NAT (Amazon называет этот "Эластичный IP").

Я установил RRAS и настроил VPN. Частная подсеть на Amazon является 172.16.0.0/17 (это - то, что я называю "LAN Amazon"), но я хочу, чтобы все клиенты VPN использовали диапазон 10.128.0.0/20 (что я называю "LAN VPN").

В моей панели управления 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-> вкладка Networking-> IPv4-> Propeties-> Advanced-> 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> 

Теперь клиент может проверить с помощью ping-запросов адрес локальной сети VPN сервера VPN (10.128.0.1) и также его адрес локальной сети (172.16.1.32) Amazon. Это сталкивается с проблемой, тем не менее, при попытке говорить с другими машинами на LAN Amazon: ping не получают ответы.

Так, например, если клиент пытается проверить с помощью ping-запросов систему, которую я знаю, произошел и отвечает на ping как 172.16.0.113, она не будет видеть те ответы (она говорит "Запрос, приведенный к таймауту"). Wireshark на сервере VPN подтверждает, что видит ping от клиента, и он даже видит ответ, отправленный от 172.16.0.113, но что ответ, по-видимому, никогда не возвращается клиенту.

Кроме того, если я проверяю с помощью ping-запросов адрес локальной сети VPN клиента от 172.16.0.113, Wireshark на сервере VPN видит ping, но не видит ответ.

Так, для резюме:

  • Сервер VPN может проверить с помощью ping-запросов другие машины на LAN Amazon (172.16.0.0/17) и получить ответы, и другие машины в той сети могут сделать то же к нему.
  • Клиент VPN может проверить с помощью ping-запросов адрес локальной сети Amazon сервера и получить ответы, после того, как клиенты добавят надлежащий маршрут, как описано ранее.
  • Клиент VPN может проверить с помощью ping-запросов адрес локальной сети VPN сервера 10.128.0.1, и сервер VPN может проверить с помощью ping-запросов адрес локальной сети VPN клиента в диапазоне 10.128.0.0/20, после того, как клиент добавляет маршрут надлежащий маршрут, как описано ранее.
  • Клиент VPN может отправить ping на машину на LAN Amazon, но когда те машины отправляют ответы, они останавливаются в сервере VPN - они не становятся переданными на клиенте, приводящем к "Запросу приведенные к таймауту" сообщения на клиенте. С другой стороны, когда машина на LAN Amazon пытается проверить с помощью ping-запросов 10.128.0.0/20 адрес локальной сети VPN клиента, сервер VPN видит ping, но клиент никогда не делает и поэтому не генерирует ответ.

Почему сервер VPN не отправляет пакеты от LAN Amazon вниз ее клиентам на LAN VPN? Это может определенно говорить с клиентами на LAN VPN, и маршрутизация включена, и это готово направить пакеты от VPN LAN-> Amazon LAN, но не реверс. Что я пропускаю здесь?

Маршруты

Вот таблицы маршрутизации от клиента VPN. Клиентом является VirtualBox VM, запускающий Windows 8. Это - IP-адрес vbox адаптера, 10.0.2.15 на/24. Этот клиент находится позади NAT (на самом деле, это находится позади двойного NAT, потому что vbox адаптер является NAT'd к моей локальной сети, которая является NAT'd к Интернету). Эта таблица маршрутизации от после ручного добавления маршрутов к 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

Вот таблицы маршрутизации для другой машины на частной сети сервера, также выполняя Сервер 2012. Это имеет один NIC, который имеет частный 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 относится к NIC на сервере 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
8
задан 18 September 2013 в 03:34
1 ответ

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

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

Замените abcd на Адрес локальной сети VPN-сервера.

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

1
ответ дан 2 December 2019 в 23:09

Теги

Похожие вопросы