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

Как настроить маршруты для IPSec VPN, при которых конечная точка VPN должна иметь возможность связываться с удаленной сетью

У меня ситуация идентична вопросу на 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.x.x (включая эхо-запросы без принудительного указания адреса источника 192.168.70.1), благополучно отправляется в Интернет по маршруту по умолчанию и не запускается или не входит в туннель.

ВОПРОС

Возможна ли вообще такая установка? Или невозможно, чтобы конечная точка VPN сама отправляла данные по туннелю, исходящие с одного из ее частных адресов? (Всегда ли необходимо, чтобы конечная точка VPN находилась на отдельном маршрутизаторе от устройств, отправляющих данные через туннель?)

Как я могу настроить Windows Server, чтобы гарантировать, что все коммуникации с сетью 10.16.0.0 будут происходить с его частного IP-адреса.

Частный адрес не иметь должно быть 192.168.70.1 - при необходимости может быть выбрана другая подсеть (я говорю это, потому что я читал это, при прочих равных условиях, Windows Vista и выше будут использовать исходный IP-адрес, наиболее точно соответствующий целевому, поэтому, возможно, используя 10.XXX ip для личного адреса сервера поможет?)

Однако я не могу это легко проверить, поскольку другой конец этого 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, который поставляется с OpenVPN. Этот драйвер позволяет принудительно перевести его в состояние «всегда подключен». Однако, похоже, после первого эхо-запроса Windows снова обнаруживает, что на этом адаптере нет подключения, и возвращается к отправке трафика через шлюз по умолчанию на основном (общедоступном) интерфейсе.

Итак, вот и все ... есть идеи?

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

Наконец, идея этого адаптера обратной петли является многообещающей, хотя странно, что она отображается как «медиа отключено». Это похоже на проблему с самим адаптером обратной петли, а не с идеей.