The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Самый внешний интерфейс eht или tun?"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение [ Отслеживать ]

"Самый внешний интерфейс eht или tun?"  +/
Сообщение от ALP (ok) on 19-Окт-09, 11:01 
Здравствуйте, господа!

Волнует такой вопрос:
Какой интерфейс указывать(защищать) в качестве внешнего в правилах ipfw, прятать за nat-ом?
- Интерфейс сетевой карты network_interfaces (rlX,skX и т.д.)?
- Созданный ppp туннель tunХ ?

Специфика такая: ip-адрес, выданный провайдером динамический.

Предполагаю, что tun ближе к интернету, поэтому его и защищать?
  

Высказать мнение | Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Самый внешний интерфейс eht или tun?"  +/
Сообщение от ronin (??) on 19-Окт-09, 11:12 
>[оверквотинг удален]
>Волнует такой вопрос:
>Какой интерфейс указывать(защищать) в качестве внешнего в правилах ipfw, прятать за nat-ом?
>
>- Интерфейс сетевой карты network_interfaces (rlX,skX и т.д.)?
>- Созданный ppp туннель tunХ ?
>
>Специфика такая: ip-адрес, выданный провайдером динамический.
>
>Предполагаю, что tun ближе к интернету, поэтому его и защищать?
>

Защищать нужно все интерфейсы. Если интересует теория - то в Вашем понимании интерфейсы rlX,skX - "самые внешние", ибо они физически присутствуют на машине, поднимаются со стартом машины, и через них машина напрямую взаимодействует с внешним миром. Интерфейсы tunХ создаются уже после того, как машина связалась с внешним миром. На "самых внешних" интерфейсах защита должна прикрывать машину от всего самого худшего, что можно себе представить, ведь не известо что там творится за пределами Вашей сети. А вот с интерфейсами tunХ не так. Всё зависит от того, куда созданы РРР коннекты, кто на тругом конце, контролируете ли Вы машину (сеть) на другом конце, и т.п. (тоесть, здесь диапазон потенциальных угроз можно сузить).

respect,
ronin


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Самый внешний интерфейс eht или tun?"  +/
Сообщение от ALP (ok) on 19-Окт-09, 11:24 
Благодарю за ответ!

Т.е. защищаем "карточные" интерфейсы, это я понял.
А, что, tuns тоже надо защищать при этом?

Уточняю, на другом конце....опасны, опасный мир :)


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Самый внешний интерфейс eht или tun?"  +/
Сообщение от ronin (??) on 19-Окт-09, 12:58 
>Благодарю за ответ!
>
>Т.е. защищаем "карточные" интерфейсы, это я понял.
>А, что, tuns тоже надо защищать при этом?
>
>Уточняю, на другом конце....опасны, опасный мир :)

Повторяю: защищать нужно всё. Но защищать с умом - в зависимости от выполняемых функций, среды обитания, и т.п. А среда обитания определяет потенциальные угрозы, от которых нужно защищаться.

respect,
ronin

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Самый внешний интерфейс eht или tun?"  +/
Сообщение от oligarh (ok) on 20-Окт-09, 13:59 
Я в такойже ситуации написал единые правила для всего, тоесть если разрешаем то везде если мы хотим закрыть то тоже везде, однако, в случае необходимости указывать интерфейс то не обламываюсь написать одно для "карточного" и такое же для виртуального.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Самый внешний интерфейс eht или tun?"  +/
Сообщение от ronin (??) on 20-Окт-09, 17:54 
>Я в такойже ситуации написал единые правила для всего, тоесть если разрешаем
>то везде если мы хотим закрыть то тоже везде, однако, в
>случае необходимости указывать интерфейс то не обламываюсь написать одно для "карточного"
>и такое же для виртуального.

Хм... может это и правильно, но не могу судить, не зная всю схему.
У меня, например, сейчас стоит похожая задача:

роутер, 1 интерфейс в локалку, другой - наружу. Правила фаерволла и таблицы маршрутизации поднимаются автоматом на старте машины. После этого поднимается openvpn демон и создаёт свой tun0 интерфейс.
Так вот - вопрос сводится к тому, как грамотно прикрутить правила фаерволла и таблицы маршрутизации для этого tun0-интерфейса.
В скрипты, которые поднимают фаерволл/маршрутизацию на старте не запихнёш, ибо в этот момент интерфейс tun0 ещё не существует; тогда, получается, надо запихать в отдельный скрипт, который вызывать после старта openvpn демона, но тут опять заковыка: иногда приходится передёргивать правила ферволла и маршрутизации вручную (например, после вноса изменений, а такая потребность не часто, но возникает), и при этом потеряются все правила и таблицы маршрутизации для tun0. Тоесть, придётся ещё передёргивать ручками скрипты фаерволла и маршрутизации для tun0-интерфейса, даже если туда никакие изменения не вносились и передёргивать в принципе не зачем. Неудобно, вобщем, получается. Вот, сижу, думаю как это оптимизировать...

respect,
ronin

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
MIRhosting
Inferno Solutions
Hosting by Ihor
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2019 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру