Здравствуйте, господа!Волнует такой вопрос:
Какой интерфейс указывать(защищать) в качестве внешнего в правилах ipfw, прятать за nat-ом?
- Интерфейс сетевой карты network_interfaces (rlX,skX и т.д.)?
- Созданный ppp туннель tunХ ?Специфика такая: ip-адрес, выданный провайдером динамический.
Предполагаю, что tun ближе к интернету, поэтому его и защищать?
>[оверквотинг удален]
>Волнует такой вопрос:
>Какой интерфейс указывать(защищать) в качестве внешнего в правилах ipfw, прятать за nat-ом?
>
>- Интерфейс сетевой карты network_interfaces (rlX,skX и т.д.)?
>- Созданный ppp туннель tunХ ?
>
>Специфика такая: ip-адрес, выданный провайдером динамический.
>
>Предполагаю, что tun ближе к интернету, поэтому его и защищать?
>Защищать нужно все интерфейсы. Если интересует теория - то в Вашем понимании интерфейсы rlX,skX - "самые внешние", ибо они физически присутствуют на машине, поднимаются со стартом машины, и через них машина напрямую взаимодействует с внешним миром. Интерфейсы tunХ создаются уже после того, как машина связалась с внешним миром. На "самых внешних" интерфейсах защита должна прикрывать машину от всего самого худшего, что можно себе представить, ведь не известо что там творится за пределами Вашей сети. А вот с интерфейсами tunХ не так. Всё зависит от того, куда созданы РРР коннекты, кто на тругом конце, контролируете ли Вы машину (сеть) на другом конце, и т.п. (тоесть, здесь диапазон потенциальных угроз можно сузить).
respect,
ronin
Благодарю за ответ!Т.е. защищаем "карточные" интерфейсы, это я понял.
А, что, tuns тоже надо защищать при этом?Уточняю, на другом конце....опасны, опасный мир :)
>Благодарю за ответ!
>
>Т.е. защищаем "карточные" интерфейсы, это я понял.
>А, что, tuns тоже надо защищать при этом?
>
>Уточняю, на другом конце....опасны, опасный мир :)Повторяю: защищать нужно всё. Но защищать с умом - в зависимости от выполняемых функций, среды обитания, и т.п. А среда обитания определяет потенциальные угрозы, от которых нужно защищаться.
respect,
ronin
Я в такойже ситуации написал единые правила для всего, тоесть если разрешаем то везде если мы хотим закрыть то тоже везде, однако, в случае необходимости указывать интерфейс то не обламываюсь написать одно для "карточного" и такое же для виртуального.
>Я в такойже ситуации написал единые правила для всего, тоесть если разрешаем
>то везде если мы хотим закрыть то тоже везде, однако, в
>случае необходимости указывать интерфейс то не обламываюсь написать одно для "карточного"
>и такое же для виртуального.Хм... может это и правильно, но не могу судить, не зная всю схему.
У меня, например, сейчас стоит похожая задача:роутер, 1 интерфейс в локалку, другой - наружу. Правила фаерволла и таблицы маршрутизации поднимаются автоматом на старте машины. После этого поднимается openvpn демон и создаёт свой tun0 интерфейс.
Так вот - вопрос сводится к тому, как грамотно прикрутить правила фаерволла и таблицы маршрутизации для этого tun0-интерфейса.
В скрипты, которые поднимают фаерволл/маршрутизацию на старте не запихнёш, ибо в этот момент интерфейс tun0 ещё не существует; тогда, получается, надо запихать в отдельный скрипт, который вызывать после старта openvpn демона, но тут опять заковыка: иногда приходится передёргивать правила ферволла и маршрутизации вручную (например, после вноса изменений, а такая потребность не часто, но возникает), и при этом потеряются все правила и таблицы маршрутизации для tun0. Тоесть, придётся ещё передёргивать ручками скрипты фаерволла и маршрутизации для tun0-интерфейса, даже если туда никакие изменения не вносились и передёргивать в принципе не зачем. Неудобно, вобщем, получается. Вот, сижу, думаю как это оптимизировать...respect,
ronin