Форум русскоязычного сообщества Ubuntu


Получить помощь и пообщаться с другими пользователями Ubuntu можно
на irc канале #ubuntu-ru в сети Freenode
и в Jabber конференции ubuntu@conference.jabber.ru

Автор Тема: Routing и безопастность между подсетми OpenVPN и Iptables  (Прочитано 964 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн John-Silver

  • Автор темы
  • Новичок
  • *
  • Сообщений: 42
    • Просмотр профиля
    • www.dn-proekt.mksat.net
Добрый день!
Нужна помощь в настройке Iptables.
Есть два шлюза на Linux на которых установлен OpenVPN server и clien соответственно. Оба выполняют функции маршрутизатора NAT и VPN.
NAT настроен, клиенты получают интернет. Связь через OpenVPN между маршрутизаторами есть.
Пинги в локальную сеть от маршрутизатора А проходят в подсеть за маршрутизатором B и наоборот.
Клиентские ПК с обоих сторон пингуют (видят) vpn сеть.
Проблема пробиться клиентским ПК из одной подсети в другую, т.е. сеть LAN_A должна видеть сеть LAN_B и наоборот.
|LAN_A 192.168.100.0/24|-----------|ROUTER_A|----------интернет-----------|ROUTER_B|---------|LAN_B 192.168.70.0/24|
Внутренний IP  ROUTER_A 192.168.100.254
VPN Server IP 10.8.8.1
Внутренний IP  ROUTER_B 192.168.70.254
VPN Client IP 10.8.8.2

WAN="eth0"
LAN="eth1"
VPN="tun0"

Внешние IP динамические, OpenVPN работает через Dynamic DNS.
В теории от куда ноги растут знаю, это цепочка FORWARD в Iptables, но к сожалению не осилил.
Сами конфиги OpenVPN не выкладываю, как писал выше vpn работает.
Собственно только маршруты
(Нажмите, чтобы показать/скрыть)
Iptables конфиги на шлюзах одинаковые, разные только адреса.
(Нажмите, чтобы показать/скрыть)

Вывод шлюза ROUTER_A
(Нажмите, чтобы показать/скрыть)

Вывод шлюза ROUTER_B
(Нажмите, чтобы показать/скрыть)
Как видим на шлюзах маршруты есть, пинги из LAN_A в LAN_B проходят и наоборот.

Теперь клиенты которые невидять сеть за vpn.
(Нажмите, чтобы показать/скрыть)
Вариант который работает, прописать в правилах по умолчанию
iptables -P FORWARD  -j ACCEPT
или
${IPTB} -A FORWARD -s ${LAN_NET} -j ACCEPT
${IPTB} -A FORWARD -d ${LAN_NET} -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
Что одно и второе нехорошо. Потому что, если кто нибудь на левом маршрутизаторе пропишет маршрут в нашу сеть,
route add -net 192.168.100.0 netmask 255.255.255.0 gw х.х.х.х "наш внешний IP".
То этот нехороший человек получает полный доступ в нашу сеть.
Пока не прочитал эту статью сам не знал https://habrahabr.ru/post/134638/
Проверил на практике, действительно вся сеть открыта.

P/S Google в помощь не помог, основная масса статей по iptables одинакова до примитива.  :-\
« Последнее редактирование: 11 Июля 2016, 00:48:31 от John-Silver »
Ни одна седая ложь да не станет правдой для меня, ни одна удушливая догма да не стеснит мое перо!

Оффлайн AnrDaemon

  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 28358
    • Просмотр профиля
Сами шлюзы в состоянии пинговать клиенты за противоположным шлюзом?
И показывайте iptables-save, мы вам тут не онлайн-интерпретаторы скриптов.
Хотите получить помощь? Потрудитесь представить запрошенную информацию в полном объёме.

Прежде чем [Отправить], нажми [Просмотр] и прочти собственное сообщение. Сам-то понял, что написал?…

Оффлайн fisher74

  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 13756
    • Просмотр профиля
client
push "route 192.168.100.0 255.255.255.0 10.8.8.1"
Фактически не нужно, ибо для клиентской сети OVPN - есть шлюз по-умолчанию.
Но для феншуя, конечно, не помешает

server
route add -net 192.168.70.0 netmask 255.255.255.0 gw 10.8.8.2 tap0
Тьфу, выплюнь каку. Костылище.
Для такого функционала придуман параметр iroute для ccd-файлов.


Скрипт для загрузки iptables лениво распутывать, но непонятно зачем делать
(Нажмите, чтобы показать/скрыть)

Если дальше делаете это
(Нажмите, чтобы показать/скрыть)

Оффлайн John-Silver

  • Автор темы
  • Новичок
  • *
  • Сообщений: 42
    • Просмотр профиля
    • www.dn-proekt.mksat.net
Тьфу, выплюнь каку. Костылище.
Для такого функционала придуман параметр iroute для ccd-файлов.
Как раз таки да, push route прописан в ccd
push "route 192.168.100.0 255.255.255.0 10.8.8.1"
На сервере
route add -net 192.168.70.0 netmask 255.255.255.0 gw 10.8.8.2 tap0
Может и костыли но думаю что проблема не в этом.
Скрипт для загрузки iptables лениво распутывать, но непонятно зачем делать
Пока для отладки. Ну или отдельным файликом. А как сбросить не перезагружая?
Сами шлюзы в состоянии пинговать клиенты за противоположным шлюзом?
Пинги в локальную сеть от маршрутизатора А проходят в подсеть за маршрутизатором B и наоборот.
Да, пингуют сети за шлюзами.
С маршрутизатора А пингую ПК за шлюзом B, сеть 192.168.70.0/24
С маршрутизатора В пингую ПК за шлюзом A, сеть 192.168.100.0/24
Проблема не OpenVPN, проблема в цепочке FORWARD.

Добавил вывод правил из Iptables
(Нажмите, чтобы показать/скрыть)
« Последнее редактирование: 11 Июля 2016, 12:13:37 от John-Silver »
Ни одна седая ложь да не станет правдой для меня, ни одна удушливая догма да не стеснит мое перо!

Оффлайн fisher74

  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 13756
    • Просмотр профиля
Обычно мы рекомендуем приводить конфиги  и листинги диагностики (в том виде в каком просим) полностью, без инициативного "безо всякого ненужного" и  т.п.
Так и сейчас Вы отнимаете время и у себя, и у нас, не показывая того, что мы просим. AnrDaemon просил выхлоп iptables-save, и не просил показывать Ваших знаний в умении пользоваться iptables, как инструментом. Есть много причин,почему просим диагностику именно в таком виде, одна из которых, конечно-же, - привычка. Но тут будьте любезны, не мы пришили за помощью.
Так вот... конфиги OpenVPN тоже урезали до безобразия, скрыв за занавесом "вам оно не нужно, ибо работает" маленькую тонкость: OVPN используется tap-интерфейс, а netfilter грузите tun-интерфейсом. "Потому и не кусают" ©

Пользователь добавил сообщение 11 Июля 2016, 14:59:07:
Кстати, впихивание везде условия --state NEW сводит на нет всю Вашу защиту.... Да и вообще она, скажем так, раздута.
А ввиду Вашего не понимания созидаемого, собирая правил из разных источников, привело к большой дыре в виде Вашего шлюза.
В указанной  на хабре статье написано "NAT не firewall". То есть надо понимать, что механизм nat не относится к защите.
« Последнее редактирование: 11 Июля 2016, 14:59:07 от fisher74 »

Оффлайн John-Silver

  • Автор темы
  • Новичок
  • *
  • Сообщений: 42
    • Просмотр профиля
    • www.dn-proekt.mksat.net
Спасибо. Банальная невнимательность tap0. :)
По поводу Iptables и собирания правил, осознаю, буду пилить дальше.
Вопрос снят. Еще раз спасибо за помощь.
Ни одна седая ложь да не станет правдой для меня, ни одна удушливая догма да не стеснит мое перо!

 

Страница сгенерирована за 0.049 секунд. Запросов: 25.