Маршрутизация VPN соединения - сеть предприятия и домашняя

[freeak]

Знаю что не раз уже таких тем было но что-то мне ничего не помагает из того в них написанно, помогите пожалуйста разобраться:

VPN-сервер:

breth0 - 10.45.1.1/24 - интерфейс в сеть
eth2 - 192.168.45.2/24 - интерфейс на роутер железный
tun0 - 10.0.250.1/24

# route -n | grep tun0
10.0.250.2      0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.1.0     10.0.250.2      255.255.255.0   UG    0      0        0 tun0
10.0.250.0      10.0.250.2      255.255.255.0   UG    0      0        0 tun0

начтроенно все через web интерфейс, в закладке "Брандмауэр" -> "Внешние сети" - в качестве внешнего интерфеса отмечен eth2, режим шлюз(NAT)


VPN-клиент(домашняя сеть):
eth0 - 172.1.0.2 - интерфейс на роутер железный
eth1 - 192.168.1.1 - интерфейс внутренней сети
tun - 10.0.250.6 - выданый DHCP VPN'a

# route -n | grep tun0
10.0.250.5      0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.0.250.0      10.0.250.5      255.255.255.0   UG    0      0        0 tun0
10.45.0.0       10.0.250.5      255.255.0.0     UG    0      0        0 tun0

начтроенно все через web интерфейс, в закладке "Брандмауэр" -> "Внешние сети" - в качестве внешнего интерфеса отмечен eth0, режим шлюз(NAT)

Что имеем: Соединение нормально устанавливается VPN клиент(Alt linux server Light) - великолепно видит VPN сервер по IP 10.45.1.1, IP-камеру 10.45.4.1 и т.п., но виндовая машина на его стороне уже ничего этого не видит(он у ней в качестве маррутизатора установлен).

C:\Windows\system32>tracert 10.45.1.1

Трассировка маршрута к 10.45.1.1 с максимальным числом прыжков 30

  1     1 ms    <1 мс    <1 мс  192.168.1.1
  2     *        *        *     Превышен интервал ожидания для запроса.
  3     *        *        *     Превышен интервал ожидания для запроса.

С сервера же вообще ничего не видно из домашней сети кроме соответственно клиента по адресу 10.0.250.6

Бьюсь над этим затыком уже 2 день и что-то никак у меня не получается, такое ощущение что между интерфейсами VPN клиента нет форвардинга хотя в настройках /etc/net/sysctl.conf опция net.ipv4.ip_forward = 1.

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

Помогите с проблемой, напишите что еще надо, логи там какие и где их найти и т.п.

Заранее благодарен.

[Karlsson]

Как то не понятно вы все рассказали..... Все запутанно, и не понятно.
На сколько я понял, у вас два сегмента локальной сети.
192.168.1.0/24 и 10.45.1.0/24 и вы их хотите соединить, поставив два cервера маршрутизации.
Сервера маршрутизации в соединяете VPN тунелем.
Я все правильно понял?

То есть трафифик должен бегать по следующему маршруту:
1) Уходит в первую локальную сеть с интерфейса 192.168.1.
2) Из первой локальной сети попадает на интерфейс 192.168.1.1 сервера с VPN клиентом.
3) На сервере с VPN клиентом заворачивается в VPN тунель через интерфейс 10.0.250.6.
4) По тунели бежит и попадает на интерфес 10.0.250.1 серевера с VPN сервером.
5) На сервере с VPN сервером заворачивается на интерфейс 10.45.1.1
6) С интерфеса 10.45.1.1 убегает во вторую локальную сеть.

Тунель вы говорите, работает нормально, и пинг между 10.0.250.6 и 10.0.250.1 бегает нормально.
Локальная сеть работает нормально, то есть пинги между 192.168.1.X и 192.168.1.1 бегают нормально.
А вот пинги между 192.168.1.X и 10.0.250.1 не бегают. Или бегают?
Только получив ответ на этот вопрос, можно будет думать, с какой стороны ковырять.

И подсказка, мало включить форвардинг пакетов. Нужно еще пакетному фильтру рассказать, что делать с такими пакетами.
Вот про настройки пакетного фильтра, вы не сказали не слова.

PS: Я представления не имею, где в веб интерфейсе это посмотреть. ЧТо бы узнать как в коммандной строке это посмотреть, достаточно попросить гугля расказать об IPTABLES.

[freeak]

Как то не понятно вы все рассказали..... Все запутанно, и не понятно.
На сколько я понял, у вас два сегмента локальной сети.
192.168.1.0/24 и 10.45.1.0/24 и вы их хотите соединить, поставив два cервера маршрутизации.
Сервера маршрутизации в соединяете VPN тунелем.
Я все правильно понял?

Да

То есть трафифик должен бегать по следующему маршруту:
1) Уходит в первую локальную сеть с интерфейса 192.168.1.
2) Из первой локальной сети попадает на интерфейс 192.168.1.1 сервера с VPN клиентом.
3) На сервере с VPN клиентом заворачивается в VPN тунель через интерфейс 10.0.250.6.
4) По тунели бежит и попадает на интерфес 10.0.250.1 серевера с VPN сервером.
5) На сервере с VPN сервером заворачивается на интерфейс 10.45.1.1
6) С интерфеса 10.45.1.1 убегает во вторую локальную сеть.

Точнее и не скажешь -  именно так.

Тунель вы говорите, работает нормально, и пинг между 10.0.250.6 и 10.0.250.1 бегает нормально.
Локальная сеть работает нормально, то есть пинги между 192.168.1.X и 192.168.1.1 бегают нормально.

Да

А вот пинги между 192.168.1.X и 10.0.250.1 не бегают. Или бегают?
Только получив ответ на этот вопрос, можно будет думать, с какой стороны ковырять.

Нет, не идут... с 192.168.1.X на 10.0.250.6 идут прекрасно

И подсказка, мало включить форвардинг пакетов. Нужно еще пакетному фильтру рассказать, что делать с такими пакетами.
Вот про настройки пакетного фильтра, вы не сказали не слова.

Т.к. оба сервера функционируют в режиме шлюз(NAT) все в том же web то при одинаковых условиях подключения(один интерфейс наружу, один внутренняя сеть) они имеют соответственно одинаковые(за исключением IP адресов определенных для каждой системы) настройки пактных фильтров:

Таблица: filter/INPUT

-P ACCEPT
-f -j DROP
-m state --state ESTABLISHED,RELATED -j ACCEPT
-i eth2 -p tcp --dport 8080 -j ACCEPT
-i eth2 -p udp --dport 1194 -j ACCEPT
-i eth2 -p tcp --dport 1194 -j ACCEPT
-i eth2 -p tcp --dport 22 -j ACCEPT
-i eth2 -p udp --dport 22 -j ACCEPT
-i eth2 -p icmp -j ACCEPT
-i eth2 -j DROP

Таблица: filter/OUTPUT

-P ACCEPT
-f -j DROP
-m state --state ESTABLISHED,RELATED -j ACCEPT

Таблица: filter/FORWARD - у клиента так же, только ip внешнего интерфейса другой

-P ACCEPT
-f -j DROP
-m state --state ESTABLISHED,RELATED -j ACCEPT
-i eth2 -d 192.168.45.0/24 -j ACCEPT
-m physdev --physdev-is-bridged -j ACCEPT
-i eth2 -m state --state ESTABLISHED,RELATED -j ACCEPT
-i eth2 -j DROP

PS: Я представления не имею, где в веб интерфейсе это посмотреть. ЧТо бы узнать как в коммандной строке это посмотреть, достаточно попросить гугля расказать об IPTABLES.

no comment :)

Вот вроде все так.... все почти идентично но в клиентскую сеть не идет, судя по всему какие-то проблемы между 192.168.1.1 и tun интерфейсами, хотя с 192.168.1.X на 10.0.250.6 пинги ходят...

[freeak]

Ну что ни у кого идей нету? Может глобальные модераторы что-то подскажут ?
Буду рад любой помощи, даже в указании направления куда копать...

[Карлсон]

Ну что ни у кого идей нету? Может глобальные модераторы что-то подскажут ?
Буду рад любой помощи, даже в указании направления куда копать...

Рассылка sysadmins@ вам в помощь.

[Salomatin]

Покажите выводы команд на сервере и клиенте:

Код: [Выделить]

#ip a s
#ip r sНа виндовой машине:
ipconfig /all

Что имеем: Соединение нормально устанавливается VPN клиент(Alt linux server Light) - великолепно видит VPN сервер по IP 10.45.1.1, IP-камеру 10.45.4.1 и т.п., но виндовая машина на его стороне уже ничего этого не видит(он у ней в качестве маррутизатора установлен).

Попробуйте добавить правило

Код: [Выделить]

#iptables -t nat -A POSTROUTING -o tun0 -s 192.168.1.0/24 -j MASQUERADE;должна появиться вся подсетка 10.0.250.0/24

если что так его можно удалить:

Код: [Выделить]

#iptables -t nat -D POSTROUTING -o tun0 -s 192.168.1.0/24 -j MASQUERADE;

С сервера же вообще ничего не видно из домашней сети кроме соответственно клиента по адресу 10.0.250.6

А вам все и не надо видеть, а только 192.168.1.0/24

Код: [Выделить]

#ip ro add  192.168.1.0/24 via 10.0.250.6 src 10.0.250.1 -добавить статический маршрут в сеть 192.168.1.0/24 через шлюз с ip-адресом 10.0.250.6 через 10.0.250.1

и может быть

Код: [Выделить]

#iptables -t nat -A POSTROUTING -o eth1 -s 10.0.250.0/24 -j MASQUERADE;

[freeak]

Спасибо за совет, буду пробовать...

Но тут натирование получается а это не совсем то чего хотелось бы добиться...

[Знайка]

Давайте еще раз, но медленее.
1) Пинги между 192.168.1.X и 10.0.250.6 бегают нормально.
2) Пинги между 10.0.250.6 и 10.0.250.1 бегают нормально.
3) Пинги между 192.168.1.X и 10.0.250.1 не бегают.
Все правильно?

Давайте разбираться по порядку.
Для начала проверте таблицы маршрутизации на VPN сервер и клиенте. Хотя, скорей всего они работают нормально.

Далее проверяете настройки пакетного фильтра.
Откровенно, понять, что и как вы прописали в настройках пакетника, мне не удалось.
По этому, делаем все с нуля.
На VPN сервере, все входящее с VPN туннеля разрешаете, и отправляете в лог.
На VPN сервере, все исходящие в VPN туннель разрешаете, и отправляете в лог.
Это вам позволит узнать, добегают ли пакеты до VPN сервера, или нет.
Ни каких привязок по IP НЕ ДЕЛАТЬ!
Таблицы правил для входящих и исходящих на сервере в студию, с пометкой, что и откуда.

Теперь настройки VPN клиента.
Полностью очищаете таблицу пересылок.
Политика по умолчанию "разрешено".
Добавляете единственное правило, запись всех пакетов в лог.
Раз натирование не нужно, то очищаете все правила в соответствующей таблицы.
Таблицы правил для пересылки на клиенте в студию, с пометкой, что и откуда.

Строчки из логов, относящиеся к форвардингу, проверить самостоятельно.
При пинге, вы должны увидеть
1) прохождение PING из локалки в тунель на клиенте.
2) поступление PING из туннеля на сервере.
3) отправку PONG в тунель на сервере.
4) прохождение PONG из тунеля в локалку на клиенте.

Если вы видите, PING или PONG не в том месте, или идущие не в то направление, то ковыряйте маршрутизацию.