Настройка сервера OpenVPN поверх PPPoE

[nedovolnyi]

Прошу помочь - в каком направлении копать. Сперва слова благодарности - после советов с форума за неделю проникся iptables, хотя был изначально был настроен решительно против изучения.
Стоит новый вопрос - требуется поднять OpenVPN сервер. Делаю согласно руководства , и наткнулся на затык в совершенно неожиданном месте - не могу поднять бридж-интерфейс br0.

Итак, ситуация следующая.

Имеется сервер с двумя сетевыми картами:
- интерфейс eth0 подключен через PPPoE к провайдеру, посредством ADSL-модема в режиме бриджа;
- интерфейс eth1, смотрит в LAN и имеет адрес вида 192.168.11.2

К сожалению, временно не могу вывести листинг ifconfig, interfaces и т.п., сервер на работе.

До моих экзерсизов вывод ifconfig  имел вид совершенно типичный -  eth1 - 192.168.11.2, eth0 - без адреса, ppp0 - c динамическим адресом провайдера, и lo. Файл interfaces также прост, как мычание - eth0 inet manual, eth1 inet static, настройка для ppp.

Приступаем к настройке OpenVPN.
Насколько я понимаю, для этого требуется создать интерфейс br0 - согласно руководства, в файл /etc/network/interfaces я дописал секцию такого вида:

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

auto br0
iface br0 inet static
        address 192.168.11.200 # надо же ему присвоить какой-то адрес?
        network 192.168.11.0
        netmask 255.255.255.0
        broadcast 192.168.11.255
        bridge_ports eth0 # непонятно, почему один интерфейс - ведь вроде как бридж?
        bridge_fd 9
        bridge_hello 2
        bridge_maxage 12
        bridge_stp off
в чем собственно проблема - перезапускаю init.d/networking, пропадает интерфейс ppp0 вместе с подключением к провайдеру. Появляется br0, уже нафиг не нужный. Подозреваю, что я делаю что-то абсурдное, прошу вразумить - что не так. Любые листинги - завтра.


upd:

как оказалось, действительно абсурд. Должно выглядеть вот так:

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

auto br0
iface br0 inet static
        address 192.168.11.2 # это будет адрес, который смотрит в локальную сеть
        network 192.168.11.0
        netmask 255.255.255.0
        broadcast 192.168.11.255
        bridge_ports eth1 # нужно назначать внутренний интерфейс
        bridge_fd 9
        bridge_hello 2
        bridge_maxage 12
        bridge_stp off

[Mam(O)n]

Ну во первых хочется спросить, а собственно все ли ты понимаешь, чего сооружаешь? Точно ли тут бридж нужен, согласно поставленной тебе/тобой задаче?

Ну а во вторых, если уж бридж поднимать, то явно в него нет смысла заводить eth0 (провайдерский), а eth1 (локалка) здесь более к месту кажется. Ну и соответственно, если eth1 будет заведен в br0, то ip протокол нужно будет поднимать не на eth1 а на br0 интерфейсе.

Ну а в третьих, ничего не вижу проблемного. При перезапуске сети, ессно все ppp/tap/tun упадут. Но там по инструкции не просто же так прописываются скрипты, которые вводят вновь созданный tap интерфейс в br0...

[nedovolnyi]

Кстати, сервер доступен, но зайти я на него не могу))) Тупняк уже приличный. Может, кто подскажет? Адрес вида host.dyndns.info
Цепляюсь ssh, предлагает авторизацию вида
user@host.dyndns.info's password:
, пароль отвергает.
Пробовал " ssh user@gateway", где gateway - имя хоста. Получается конструкция
user@gateway@host.dyndns.info' password:
, пароль также отвергает.
Зараза. На такую подлость я не рассчитывал )))

[Mam(O)n]

А точно на него ломишься, а не на какойнить пограничный маршрутизатор, у которого также есть ssh?
Пользователь решил продолжить мысль 30 Сентября 2010, 21:10:11:Ну и естественно, чтоб отвергнуть версию о криворукости, пароль методом копи из блокнота и пастой в терминал пробовал вводить?

[nedovolnyi]

Ну во первых хочется спросить, а собственно все ли ты понимаешь, чего сооружаешь? Точно ли тут бридж нужен, согласно поставленной тебе/тобой задаче?

Совершенно верно предположил - мне нужно делать быстро, в лоб. Читаю инструкцию, вижу, что не особо (вроде как) сложно, копирую команды, конфиги под себя правлю. Получилось - отлично. Не получилось - вникаю. Как с iptables )) По ним уже могу консультировать, без дураков. На стандартные вопросы, которых тут миллион - уж точно.
По существу вопроса: оказалось, что не понимаю, что сооружаю. Конструкция получилась явно абсурдная, как я и написал. Если объяснишь вкратце суть происходящего - буду благодарен. Хороший совет даст толчок в нужном направлении.

Ну а во вторых, если уж бридж поднимать, то явно в него нет смысла заводить eth0 (провайдерский), а eth1 (локалка) здесь более к месту кажется. Ну и соответственно, если eth1 будет заведен в br0, то ip протокол нужно будет поднимать не на eth1 а на br0 интерфейсе.

Вот в эти нагромождения я никак не въеду - для чего там собственно br0, tun' и tap'ы. Так сказать, физический смысл, чего-куда летает.
Если eth1 - тогда на нем пропадет ip-адрес, как общаться с внутренней сеткой?

Ну а в третьих, ничего не вижу проблемного. При перезапуске сети, ессно все ppp/tap/tun упадут. Но там по инструкции не просто же так прописываются скрипты, которые вводят вновь созданный tap интерфейс в br0...

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

Пользователь решил продолжить мысль 30 Сентября 2010, 21:23:46:

А точно на него ломишься, а не на какойнить пограничный маршрутизатор, у которого также есть ssh?
Ну и естественно, чтоб отвергнуть версию о криворукости, пароль методом копи из блокнота и пастой в терминал пробовал вводить?

Там прозрачный модем бриджом. Может статься, что информация в dyndns не обновилась, и он дает старый адрес, который уже присвоен провайдером кому-то другому. Маловероятно, но..

Ну и пароль там - единица ))) К вечеру я озверел вводить что-то сложнее ))

[Mam(O)n]

явно абсурдная, как я и написал.

Да ничего абсурдного тут нет.

Если объяснишь вкратце суть происходящего - буду благодарен. Хороший совет даст толчок в нужном направлении.

Если тебе не нужен доступ к удаленной сети на канальном уровне или объединение нескольких сетей в один широковещательный домен то и мосты c tap интерфейсами городить смысла нет. Для простого поднятия шифрованного ip туннеля, например до корпоративного сервера однаэски или допустим SQL сервера, можно обойтись tun интерфейсом и правильно настроенной маршрутизацией. Про различия между tap и tun интерфейсами можно прочитать на википедии.

Вроде как самодостаточная хаутушка есть и у нас. Можно воспользоваться ей, проигнорировав разделы настройки корпоративного шлюза в инет, настройки squid3, сконцентрировав внимание на настройке openvpn, и пренебрежительным вниманием обойти рекомендации по настройке iptables, лишь взяв нх заметку и настроив фильтрацию по уже существующим реалиям инфраструктуры правил iptables.

Если eth1 - тогда на нем пропадет ip-адрес, как общаться с внутренней сеткой?

Ессно, если интерфейс заводишь в бридж, то и адрес надо на бридже настраивать. Т.е. если делать бридж с eth1, то и все настроки ip, которые раньше были на eth1 нужно перенести на br0.

Всю инструкцию я процитировал, только адреса свои вписал. Вот она.

В первом посте ты другую инструкцию приводил, и именно там есть и про мост и про скрипты динамической настройки моста.
Пользователь решил продолжить мысль 30 Сентября 2010, 21:52:31:

Вот в эти нагромождения я никак не въеду - для чего там собственно br0, tun' и tap'ы. Так сказать, физический смысл, чего-куда летает.

Смысл объединения eth1 и tap в br0 в том, чтоб что пришло на tap то и в eth1 и вылетело и наоборот. Т.е. получается кабы обычный свитч, в один порт который вставлена локалка, а в другой порт вставлено tap удаленное подключение.
Пользователь решил продолжить мысль 30 Сентября 2010, 21:55:21:И главное, выбор типа туннеля tun или tap исходит из поставленной задачи. Если особого смысла в tap нет, то tun предпочтительнее в силу меньшего оверхеда и относительного упрощения системы.

И да, самое главное, по первой твоей проблеме - ты eth0 заводишь в бридж br0 и ppp соответственно уже не может коннект наладить по eth0. Ну а т.к. тебе вместо eth0 нужно eth1 в мост вводить, то проблема решается сама собой.

[drako]

Кстати, сервер доступен, но зайти я на него не могу))) Тупняк уже приличный. Может, кто подскажет? Адрес вида host.dyndns.info
Цепляюсь ssh, предлагает авторизацию вида
user@host.dyndns.info's password:
, пароль отвергает.
Пробовал " ssh user@gateway", где gateway - имя хоста. Получается конструкция
user@gateway@host.dyndns.info' password:
, пароль также отвергает.
Зараза. На такую подлость я не рассчитывал )))

Дык для сервака-то host.dyndns.info не есть localhost, так что коннектимся на ip, а не dns имя, и усе будет пучком.

[Mam(O)n]

Дык для сервака-то host.dyndns.info не есть localhost, так что коннектимся на ip, а не dns имя, и усе будет пучком.

А localhost не есть ip интерфейса для внешнего соединения. Только каким образом это влияет на ssh-сервер в дефолтной настройке?

[drako]

Дык для сервака-то host.dyndns.info не есть localhost, так что коннектимся на ip, а не dns имя, и усе будет пучком.

А localhost не есть ip интерфейса для внешнего соединения. Только каким образом это влияет на ssh-сервер в дефолтной настройке?

Имеется ввиду что машине не знает что одно из её имен host.dyndns.info, потому и посылает на три буквы.

[Mam(O)n]

Имеется ввиду что машине не знает что одно из её имен host.dyndns.info, потому и посылает на три буквы.

Ну во первых, дефолтно настроенному серверу глубоко накакать, по какому имени к нему обращаются. И во вторых,  разве у нас протокол ssh поддерживает передачу имени хоста? Если да, тогда нахрена козе баян?

[drako]

Имеется ввиду что машине не знает что одно из её имен host.dyndns.info, потому и посылает на три буквы.

Ну во первых, дефолтно настроенному серверу глубоко накакать, по какому имени к нему обращаются. И во вторых,  разве у нас протокол ssh поддерживает передачу имени хоста? Если да, тогда нахрена козе баян?

Читаем мы видимо не вдумываясь. SSH сервер не пустит никого кроме пользователей данной машины. А то что host.dyndns.info это и есть машина ему не известно.

[Mam(O)n]

Не понимаю, сначала ты говоришь, что сервер не пустит потому что к нему обращаются как к host.dyndns.info, теперь ты же утверждаешь обратное, то, что ему не известно, что к нему обращаются как к host.dyndns.info...

А то, что любой сервер с авторизацией не пустит никого, кроме тех, кто может пройти авторизацию, это как бы очевидное. Но причем тогда здесь имя host.dyndns.info? Неужели ты думаешь то, что оно является частью имени пользователя?

[drako]

Не понимаю, сначала ты говоришь, что сервер не пустит потому что к нему обращаются как к host.dyndns.info, теперь ты же утверждаешь обратное, то, что ему не известно, что к нему обращаются как к host.dyndns.info...

А то, что любой сервер с авторизацией не пустит никого, кроме тех, кто может пройти авторизацию, это как бы очевидное. Но причем тогда здесь имя host.dyndns.info? Неужели ты думаешь то, что оно является частью имени пользователя?

Читаем внимательно!

[Mam(O)n]

Читаем внимательно!

Если нормально объяснить не можешь свою позицию, то хотябы чушь не пори! Серверу по барабану, как к нему цепляться @123.45.67.89 или @host.dyndns.info :

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

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

mamon@mamon-netbook:/usr/home/mamon$ ssh mamon@172.16.10.108
mamon@172.16.10.108's password:
Linux mamon-laptop 2.6.32-24-generic #43-Ubuntu SMP Thu Sep 16 14:17:33 UTC 2010 i686 GNU/Linux
Ubuntu 10.04.1 LTS

Welcome to Ubuntu!
 * Documentation:  https://help.ubuntu.com/

Last login: Thu Sep 30 23:37:46 2010 from mamon-netbook
mamon@mamon-laptop:~$ exit
выход
Connection to 172.16.10.108 closed.
mamon@mamon-netbook:/usr/home/mamon$ ssh mamon@bigbook.local
mamon@bigbook.local's password:
Linux mamon-laptop 2.6.32-24-generic #43-Ubuntu SMP Thu Sep 16 14:17:33 UTC 2010 i686 GNU/Linux
Ubuntu 10.04.1 LTS

Welcome to Ubuntu!
 * Documentation:  https://help.ubuntu.com/

Last login: Thu Sep 30 23:38:11 2010 from mamon-netbook
mamon@mamon-laptop:~$ exit
выход
Connection to bigbook.local closed.


Пользователь решил продолжить мысль 30 Сентября 2010, 23:43:47:И так с любым именем, указывающем на ip сервера..

[Гарри Кашпировский]

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

Не надоело еще пароли набирать?

ТС кажи ssh -vv user@host, без логов обсуждать нечего.