У меня ситуация идентична вопросу наIPSec VPN: трафик маршрутизируется неправильно(однако я, похоже, не могу связаться с этим пользователем напрямую, а также не могу разместить комментарий к этому вопросу — и никто так и не ответил).
У меня тоже есть сервер Windows 2008 R2 с IPSec VPN, подключенным непосредственно к серверу.
Сервер имеет один сетевой интерфейс, на котором находится публичный IP-адрес (например, назовем его 203.10.10.10).
Я хотел бы, чтобы компьютеры в удаленной частной сети (10.16.0.0/255.254.0.0) могли подключаться к этому серверу Windows по частному IP-адресу в конце туннеля IPSec, который заканчиваетсявэтом сервере (а не на маршрутизаторе перед сервером).
Не менее важно (и это может стать камнем преткновения), что мне нужно, чтобы сервер мог инициировать TCP-соединение с устройствами в удаленной сети (10.16.0.0) (например, для загрузки изображения по HTTP).
Вот как это выглядит:
Частный IP-адрес, который я выбрал для сервера, — 192.168.70.1/255.255.255.0, а фильтры IPSec, которые устанавливают туннель к удаленной частной сети, — для источника/назначения 192.168.70.0/24 и 10.16.0.0/15.
Если я пропингую адрес в удаленной сети с сервера Windows, указав аргумент источника, то я смогу установить туннель, и пинги будут работать (т. е. ping -S 192.168.70.1 10.16.0.1).
Однако любой «нормальный» трафик, отправленный на адрес 10.16.xx (включая пинги без принудительного указания исходного адреса на 192.168.70.1), без проблем отправляется в Интернет по маршруту по умолчанию и не запускается в туннель и не входит в него.
ВОПРОС
Возможна ли вообще такая настройка? Или невозможно, чтобы конечная точка VPN сама отправляла данные по туннелю, исходя из одного из ее частных адресов? (Всегда ли необходимо, чтобы конечная точка VPN находилась на отдельном маршрутизаторе по отношению к устройству(ам), отправляющему данные через туннель?)
Как настроить Windows Server так, чтобы все соединения с сетью 10.16.0.0 осуществлялись с его частного IP-адреса?
Частный адрес неиметьна 192.168.70.1 - при необходимости можно выбрать другую подсеть (я говорю это, потому что читал, что при прочих равных условиях Windows Vista и выше будут использовать исходный IP-адрес, который наиболее точно соответствует назначению - так что, возможно, использование IP-адреса 10.XXX для частного адреса сервера поможет?)
Однако я не могу это легко проверить, поскольку другой конец этого VPN-туннеля не находится под моим контролем, и мне нужно будет попросить сетевых инженеров на другом конце внести изменения в конфигурацию, если я решу изменить адрес 192.168.70.1.
ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ: ЧТО Я ПОПРОБОВАЛ НА СЕЙЧАС
Я попробовал два метода настройки этого частного IP-адреса (на сервере Windows), пытаясь заставить пакеты маршрутизироваться правильно.иудовлетворять правилам IPSec, устанавливающим туннель.
Частный адрес на главном интерфейсе
С адресом 192.168.70.1, добавленным к основному сетевому интерфейсу (в дополнение к публичному IP), не представляется возможным определить какие-либо маршруты к 10.16.0.0, которые заставили бы Windows использовать 192.168.70.1 в качестве исходного адреса. Любой трафик, предназначенный для шлюза по умолчанию, в конечном итоге будет иметь публичный IP в качестве источника.
Если есть какая-то магия маршрутизации в Windows, о которой я не знаю, я был бы рад услышать о ней! Однако команда:
route add 10.16.0.0 mask 255.254.0.0 192.168.70.1
приведет к добавлению маршрутов следующим образом (он выбирает публичный IP-адрес на том же интерфейсе для использования в качестве исходного/внутреннего шлюза).
10.16.0.0 255.254.0.0 On-link 203.10.10.10 11 10.17.255.255 255.255.255.255 On-link 203.10.10.10 266
Частный адрес на втором виртуальном адаптере
Я попытался добавить виртуальный сетевой адаптер на сервер - сначала с помощью устройства Microsoft Loopback Adapter. Устройство Loopback появилось в списке сетевых подключений как имеющее "носитель отключен". Увидев, что виртуальный сетевой адаптер не имеет подключения, Windows просто вернулась к отправке трафика через маршрут по умолчанию (с публичным исходным адресом).
Затем я попробовал другой драйвер виртуального устройства - драйвер TAP Virtual Adapter, который поставляется с OpenVPN. Этот драйвер позволяет принудительно перевести его в состояние "всегда подключен". Однако, похоже, после первого пинга Windows снова понимает, что на этом адаптере нет подключения, и возвращается к отправке трафика через шлюз по умолчанию на основном (публичном) интерфейсе.
Ну вот и все... есть идеи?
решение1
Вы как бы боретесь против естественных тенденций того, как работает выбор исходного IP-адреса, когда пытаетесь сделать это. Так почему бы просто не изменить свой дизайн немного, чтобы он тек более естественно?
Проблема в том, что выбор исходного IP-адреса выполняется до принятия решения о передаче трафика по туннелю. Это означает, что он выберет использование «публичного» IP-адреса в качестве исходного IP-адреса для любого трафика, исходящего через туннель.
В некоторых ОС:ах можно делать забавные вещи с маршрутизацией, указывая исходные адреса на маршруте для трафика, исходящего от хоста. Хотя я не могу найти ничего подобного в Windows.
Однако, учитывая структуру вашей сети, я думаю, что самый простой способ решения этой проблемы — прекратить борьбу с адресами RFC1918 на стороне сервера, а просто настроить туннель с SA между вашим публичным IP-адресом 203.10.10.10 и частными IP-адресами 10.16.0.0/15.
Клиенты тогда будут обращаться к серверу как 203.10.10.10, а не 192.168.70.1, и все остальное, будем надеяться, просто волшебным образом встанет на свои места. Таким образом, выбор исходного IP-адреса уже выберет подходящий адрес, который будет работать.
Вы можете сохранить старую политику ipsec на время переходного периода, чтобы ваши клиенты могли обращаться к серверу либо по старому адресу RFC1918, либо по новому публичному адресу, пока не истечет срок действия вашего кэша DNS (при условии, что вы используете DNS для этого — если нет, то это хорошая идея). После переходного периода адрес 192.168.70.1 больше не будет функционировать.
Другой вариант — явно указать исходный IP-адрес при инициировании соединений с вашего сервера. Это возможно, если это специальное программное обеспечение, написанное вами самостоятельно, но это довольно рискованно.
Наконец, эта идея с петлевым адаптером многообещающая, хотя странно, что она отображается как "носитель отключен". Хотя это похоже на проблему с самим петлевым адаптером, а не с идеей.