OpenVPN. Может кто подскажет. Опции

[Decker]

Вообщем тема в расчете на то, что может быть кто-то сходу подскажет ... сейчас ни конфигов под рукой, ни времени разбираться, ни возможности сэмулировать ситуацию. Вообщем имеется некий сервер на базе Win2k3, три интерфейса OpenVPN, два из них сконфигурированы как клиенты, один как сервер. Предположим что два клиентский интерфейса называются VPN1, VPN2 и коннектятся куда-то там, серверный интерфейс называется VPNSRV и предназначен, чтобы подключались к нему. Для определенности положим что VPN1 и VPN2 принадлежат подсетям 10.10.1.0/16 и 10.10.2.0/16 соответственно, интерфейс VPNSRV - 10.10.3.0/16 ... Внутренний LAN интерфейс этого сервера принадлежит сети 192.168.3.0, за шлюзами сетей 10.10.1.0 и 10.10.2.0 скрываются сети 192.168.1.0 и 192.168.2.0 соответственно. Т.е. на самом этом сервере с тремя OpenVPN интерфейсами доступны сети 192.168.3.0, потому как он физически к ней подключен и 192.168.1.0 через VPN1, и 192.168.2.0 через VPN2. Сразу скажу, что маршрутизация пакетов, которая IPEnableRouter на нем включена. Теперь самое интересное. Рассмотрим удаленного клиента подключающегося к VPNSRV.

Для него адресом сервера будет 10.10.3.1, собственно у самого у него адрес к примеру 10.10.3.100. Нужно чтобы он имел доступ к 192.168.1.0, 192.168.2.0, 192.168.3.0 ... добавляем на этом клиенте маршруты:

Код

route add 192.168.1.0 mask 255.255.255.0 10.10.3.1
route add 192.168.2.0 mask 255.255.255.0 10.10.3.1
route add 192.168.3.0 mask 255.255.255.0 10.10.3.1

Пакеты уходят на 10.10.3.1, т.е. через наш VPNSRV. Однако, судя по трассировке доступной оказывается только сеть 192.168.3.0, к которой подключен сам сервер OpenVPN. 192.168.1.0 и 192.168.2.0, т.е. то что за двумя клиентскими интерфейсами OpenVPN сервера оказываются недоступными клиенту. Получаем что маршруты на клиенте правильные, до первого хопа пакеты доходят, а вот дальше ... что-то нужно видимо добавить в конфиги интерфейса VPNSRV. Только вот в какую сторону крутить?

Можно помочь например примером конфига в котором поднимается OpenVPN сервер и маршрутизация всего траффика (0.0.0.0) с клиентов идет через него ... Ну или "намекнуть" как-то по другому, почему клиент подключенный к VPNSRV не имеет доступа к сетям за VPN1 и VPN2.

[A_Max]

1. я надеюсь что "VPN1 и VPN2 принадлежат подсетям 10.10.1.0/16 и 10.10.2.0/16 соответственно, интерфейс VPNSRV - 10.10.3.0/16" этот опечатка? Может таки /24 везде?
2. А в сетях 192.168.1.* и 192.168.2.* куда идут маршруты по умолчанию?
Смысл в том куда собственно будут от них уходить пакеты для 10.10.3.0/24.

[Decker]

1. я надеюсь что "VPN1 и VPN2 принадлежат подсетям 10.10.1.0/16 и 10.10.2.0/16 соответственно, интерфейс VPNSRV - 10.10.3.0/16" этот опечатка? Может таки /24 везде?
2. А в сетях 192.168.1.* и 192.168.2.* куда идут маршруты по умолчанию?
Смысл в том куда собственно будут от них уходить пакеты для 10.10.3.0/24.

Да, по первому пункту действительно опечатка, конечно же /24. А по второму пункту - неизвестно куда ... смысл я вроде бы понял ...

Т.е. ты хочешь сказать, что от клиента 10.10.3.100 пакет для 192.168.1.x к примеру приходит на 10.10.3.1 (т.е. интерфейс VPNSRV), далее он маршрутизируется на 192.168.1.x и в ответ тишина, т.к. нет обратного маршрута?

А можно ли сделать некий NAT между интерфейсами посредством OpenVPN? Т.е. VPNSRV в сети 10.10.3.0 имеет адрес 10.10.3.1, в сетях 1.0 и 2.0 этот же ПК выступает клиентом, т.е. имеет к примеру адреса 192.168.1.100 и 192.168.2.100. Можно ли средствами OpenVPN добиться того, чтобы пакеты приходящие на 10.10.3.1 от клиентов 10.10.3.0 как-то NAT'ились на 1.0 и 2.0 подсети? Ведь с самой этой машины 192.168.1.0 и 192.168.2.0 прекрасно доступны ... вопрос о том, что доступа к конфигам OpenVPN сервера в подсетях 1.0 и 2.0 нет.

[A_Max]

Средствами опенвпн нат не уверен, а вот в вин2к3 вполне можно настроить.
Лучше бу конечно на филиалах маршруты добавить.... но раз доступа туда нет, тогда токо NAT

[Decker]

Средствами опенвпн нат не уверен, а вот в вин2к3 вполне можно настроить.
Лучше бу конечно на филиалах маршруты добавить.... но раз доступа туда нет, тогда токо NAT

A_Max, а поясни еще вот какой момент, для окончательной ясности. Допустим мы рассматриваем только TCP соединения. Если хост 10.10.3.100 знает что пакеты для 192.168.1.0 нужно роутить через его шлюз 10.10.3.1 и они туда приходят. Сам шлюз знает, что подсеть 192.168.1.0 находится от него через другой интерфейс 10.10.1.100, т.е. что все пакеты на 192.168.1.0 нужно направлять через шлюз 10.10.1.1 ... Ты хочешь сказать что без NAT'а, т.е. без замены адреса отправителя (10.10.3.100) на 10.10.1.100 TCP-туннель не установится, потому что хост-получатель в сети 192.168.1.0 не знает куда роутить пакеты для 10.10.3.0? Я правильно понимаю?

Ведь в то же время пакеты из сети 192.168.3.0 (LAN интерфейс машины с OpenVPN сервером) и до 192.168.1.0 и до 192.168.2.0 доходят нормально. Еще раз на всякий случай нарисую картинку с интерфейсами и полученными ими IP адресами машины на которой установлен OpenVPN:

Код

VPN1: 10.10.1.100 ----------------- route 192.168.1.0 --------> 10.10.1.1
VPN2: 10.10.2.100 ----------------- route 192.168.2.0 --------> 10.10.2.1
VPNSRV: 10.10.3.1 (сюда подключаются клиенты)
LAN: 192.168.3.1 (этот интерфейс смотрит в локальную сеть)

Так вот, любой хост находящийся в 192.168.3.0 может достучаться и до 192.168.1.0 и до 192.168.2.0 ... хосты же из 10.10.3.0, т.е. те, для которых VPNSRV является шлюзом не видят 192.168.1.0 и 192.168.2.0 ... у меня "ступор" в чем случился ... видимо для LAN интерфейса NAT настроен ... или маршруты на другой стороне прописаны ... а для VPNSRV - нет ...

[A_Max]

Так вот, любой хост находящийся в 192.168.3.0 может достучаться и до 192.168.1.0 и до 192.168.2.0 ... хосты же из 10.10.3.0, т.е. те, для которых VPNSRV является шлюзом не видят 192.168.1.0 и 192.168.2.0 ... у меня "ступор" в чем случился ... видимо для LAN интерфейса NAT настроен ... или маршруты на другой стороне прописаны ... а для VPNSRV - нет ...

Ну ты сам и ответил. Если видят в обе стороны (т.е. об е переферии видят друг друга), значит используется просто маршрутизация. И к тому же клиентские машины в сетях 192.168.*.* могут вообще не иметь понятия о сети 10.10.*.*!!!! Не забывай этот момент! О них на 100% знают только машины с опенвпнами! В общем всё очень зависит от того как настроено на филиалах.

[Decker]

Вообщем с NAT'ом и роутингом разобрался. Все оказывается крайне просто, когда получаешь доступ ко всему, т.е. когда можно поменять любые настройки и на клиенте и на сервере

p.s. Возник другой вопрос ... касательно виндового RRAS'а (именно Routing & Remote Access в серверных ОС, а не ICS) ... допустим есть несколько интерфейсов, LAN, WAN, VPN1, VPN2. Где LAN - это локальная сеть, WAN - выход в интернет, VPN1, VPN2 - VPN интерфейсы, в которых данный ПК выступает как клиент. На WAN, VPN1, VPN2 поднят NAT средствами RRAS. Соответственно клиенты из LAN замечательно выходят и в интернет и на ресурсы расположенные за VPN1 и VPN2. Теперь вопрос. Возможно ли средствами того же RRAS внести в этот NAT "коррективы", таким образом, чтобы пакеты "извне" с интерфейса, ну например VPN1 имели доступ в LAN, а не отбрасывались, т.к. это соединение не было инициировано изнутри. Надеюсь понятно объяснил ... Т.е. нужен не Port Forwarding, а именно маршрутизация пакетов во внутреннюю сеть, с одного определенного IP, находящегося за VPN1.

[A_Max]

Нет конечно :о)
Это ж вам не линухенция, а МИНИМАЛЬНЫЙ набор для того чтоб вообще работало.

[Decker]

Нет конечно :о)
Это ж вам не линухенция, а МИНИМАЛЬНЫЙ набор для того чтоб вообще работало.

Некошерно как-то )) Я думал у RRAS возможностей побольше ... а минимальный набор он и в Workstation системах есть ... достаточно включить ICS, маршрутизацию и вот он минимальный набор ) Ладно, спасибо. Ясно.