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

8

Я хочу настроить 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
vpn routing windows-server-2012 rras Мика Р Ледбеттер
источник
2
Однажды я использовал почти такую ​​же настройку, как и у вас, и не могу вспомнить, что вы делаете неправильно. Не могли бы вы опубликовать вывод ROUTE PRINT с клиента, сервера и одного хоста в сети 172.16? (я предполагаю, что хосты из сети 176.16 не имеют правильного маршрута)
Душан Баджич
Кроме того, проверьте с помощью tracert с одного из хостов 172.16 на клиент vpn - достигает ли он когда-нибудь сервера vpn?
Душан Баджич
Я добавил запрашиваемую информацию - route printи tracertвывод - и внес важные исправления в некоторые сведения, добавленные ранее. (Спасибо за помощь!)
Мика Р Ледбеттер
1
Weird. Как точно настроен ваш пул статических адресов для клиентов VPN?
Душан Баджич
@ dusan.bajic Начальный IP-адрес: 10.128.0.0; Конечный IP-адрес: 10.128.15.255; Количество адресов: 4096.
Мика Р Ледбеттер

Ответы:

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.

Сильвио Массина
источник