Переход к предыдущей публикации Немного лирики… Из жизни эмо Переход к следущей публикации

ipfw + natd + tun0 - пример настройки маршрутизатора для локальной сети

Четверг, 25 октября, 2007 22:34:50 EEST

Исправления от 23 марта, 2009 09:22:17

Firewall Для некоторых кто использовал штатный фаерволл ipfw в операционной системе FreeBSD на маршрутизаторе с минимум двумя ethernet интерфейсами, один из которых являлся внешним, то есть “смотрел” в Интернет, а другой в локальную сеть, возможно, покажется странным, почему та же конфигурация не работает на машине, у которой шлюзовым является динамический интерфейс, например, tun0 или ppp0 (в зависимости от того, что используется, ppp или pppd). На самом деле сложного нет ничего. Но начнем по-порядку, с самого начала.

Итак, дано:

  • Маршрутизатор под OS FreeBSD 6.2
  • Локальная сеть 192.168.0.0/24.
  • Подключение к провайдеру услуг сети Интернет посредством PPPoE на DSL линии.

Требуется:

  • Защитить маршрутизатор и локальную сеть фаерволлом.
  • Оставить доступ к маршрутизатору, например, по протоколам SSH и FTP только с определенных адресов.
  • Дать возможность компьютерам локальной сети выйти во внешний мир.
  • Пробросить порт на NAT’е, чтобы из внешнего мира можно было подключиться удаленным рабочим столом Windows (RDP) к машине 192.168.0.100 в локальной сети.

Подразумевается, что уже у Вас имеется рабочая серверная машина, под управлением FreeBSD, с настроенным PPPoE соединением и локальной сетью. Также, подразумевается, что Вы уже умеете пересобрать ядро системы, знаете как минимум основные приемы работы в *nix консоли, а также осознаете всю ответственность за совершаемые действия. :) Каким образом будет построена локальная сеть, не имеет значения. Главное, чтобы компьютеры локальной сети имели доступ к тому компьютеру, которому в будущем будет отведена почетная роль маршрутизатора.

Реализация:

Для начала следует пересобрать ядро операционной системы для поддержки ipfw. В принципе, можно подгрузить соответствующий модуль ядра командой (из-под root’а):

root@router# kldload ipfw

Но в данном случае учтите, что после ее выполнения машина останется без связи и обрубит все существующие соединения, поскольку ipfw по-умолчанию “запрещает все”. Следовательно, не стоит выполнять эту команду, если Вы не имеете физического доступа к машине и управляете ею по ssh. Для статической поддержки ядром ipfw, добавим в конфигурационный файл ядра такие строки:

Эта часть публикации доступна только зарегистрированным посетителям!
Пожалуйста, войдите [Login] или зарегистрируйтесь [Register].

Далее, переходим в каталог /usr/src и пересобираем ядро.

Эта часть публикации доступна только зарегистрированным посетителям!
Пожалуйста, войдите [Login] или зарегистрируйтесь [Register].

- где KERNELNAME - имя файла конфигурации ядра в каталоге /usr/src/sys/i386/conf (для платформы x86). После пересборки ядра, не спешите перезагружать систему, иначе, если Вы управляете машиной удаленно, то сразу же потеряете к ней доступ, поскольку после загрузки модуля сработает дефолтовое правило ipfw, запрещающее все соединения. Добавим в файл /etc/rc.conf параметры, необходимые для запуска ppp, ipfw и natd, который будет выполнять у нас функции NAT’а.

Эта часть публикации доступна только зарегистрированным посетителям!
Пожалуйста, войдите [Login] или зарегистрируйтесь [Register].

В вышесказанном, есть упоминание о конфигурационном файле natd. Именно в нем мы и зададим параметры проброса портов на NAT’е во внутреннюю сеть с определенного порта на внешнем интерфейсе, по определенному протоколу на определенный порт и IP адрес локальной сети. В исходных данных требовалось осуществить возможность доступа из внешнего мира на машину 192.168.0.100 в локальной сети посредством удаленного рабочего стола Windows (RDP). В /etc/natd.conf добавим:

Эта часть публикации доступна только зарегистрированным посетителям!
Пожалуйста, войдите [Login] или зарегистрируйтесь [Register].

На данном этапе осталось только создать правила фаерволла и поместить их в /etc/my_firewall Ниже приводится рабочий пример конфигурации ipfw с комментариями, какое правило для чего служит.

Эта часть публикации доступна только зарегистрированным посетителям!
Пожалуйста, войдите [Login] или зарегистрируйтесь [Register].

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

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

Перезагрузили? Вошли в систему? Доступ к сети Интернет есть? Поздравляю! Значит все прошло успешно. Далеко не каждому дано с первого раза сделать все как следует. Потому, даже если у Вас что-либо неполучилось, не отчаивайтесь. Просто, попробуйте определить в чем заключается ошибка. Хотя, если Вы все делали, так же как описано в данном материале, ошибки возникнуть не должно.

Для проверки работы фаерволла, попробуйте набрать команду ipfw show. На консоль должны вывалиться все Ваши правила. Для внесения изменений, можно воспользоваться командой “ipfw [-abcdefhnNqStTv] “, либо внести соответствующие изменения в файл с набором правил, и попросту снова его запустить: /etc/my_firewall

Не забудьте, если в конфигурационном файле /etc/ppp/ppp.conf ранее использовалась секция “NAT” с конфигурацией, все эти строки следует закомментировать, а в /etc/rc.conf установить параметр ppp_nat значение “NO” поскольку теперь функции NAT’а выполняет демон natd.

Советы:

  • Учтите, что если Вы собираетесь снимать статистику пакетов с правил ipfw, то каждый перезапуск скрипта ./my_firewall приведет к обнулению счетчиков.
  • Не убирайте в скрипте фаерволла опцию ipfw “- q”. Иначе, при перезапуске скрипта /etc/my_firewall, ipfw выбросит Вам на консоль весь набор правил. При работе с машиной по ssh это может стать причиной отпадания консоли.
  • При перезапуске /etc/my_firewall лучше применять конструкцию nohup /etc/my_firewall. В данном случае, если при применении правил обнаружится какая-либо ошибка в синтаксисе файла, все сообщения об этих ошибках будут выведены в файл nohup.out который будет создан в текущем каталоге.

Удачи! :)

Добавить в закладки

Похожие публикации

Опубликовал Daemony | Рубрика FreeBSD, Система | Читали 25,218 раз(а)
Теги: , , , , , , , , , , , , , , , , , ,

Комментариев 59

1 ... 4 5 6

Sergiy 10 декабря, 2009 19:14:28 EET .:. ID #22813 .:.

Для того чтоб соединение не рвалось по SSH:

/etc/rc.d/ipfw forcerestart

4upaz01d 23 ноября, 2009 22:11:03 EET .:. ID #21740 .:.

Доброго времени суток всем. Прочитал статью и комменты. Вынес много полезного для себя, за что автору ОГРОМНОЕ спасибо! Но у меня возник вопрос, ответа на который я здесь не нашел:
При загрузке внешняя сет.карта получает “серый” адрес по DHCP. Затем ipfw считывает свой скрипт с правилами(он еще не знает о существовании tun0). Затем я вручную устанавливаю сеанс PPTP (появляется tun0 с “белым” адресом, который можно парсить). Подскажите, как можно сделать tun0 ДО того как ipfw начнет читать конфиг? Мозга пока только хватило чтоб написать скрипт, проверяющий каждую минуту наличие соединения с инетом.

UserQ 26 сентября, 2009 18:03:27 EEST .:. ID #17963 .:.

И как с этим
${fw} add divert natd all from any to ${outip} in via ${outif}
если и динамический, видел скрипт пару комментариев назад, но как его применить не понял :(

Daemony 21 сентября, 2009 13:20:39 EEST .:. ID #17683 .:.

Serj-Spb: 1. Почему\зачем используется явное указание направления когда можно ограничится парой правил бeз in\out или есть необходимость ограничить локалку только tcp?

Можно конечно. Но, когда настраивается ipfw на роутере у которого два внешних интерфейса (аплинки) и три внутренних, смотрящих в три разные локальные сети (для которых раздается доступ к Интернет), такая детализация нужна. Без нее никак.

Serj-Spb: 2. Сакральный смысл разворота правил запрета и детализации направления ? - обычно рекомендуют тупо from{запрещенная сеть} to any?

Тут уточни, плз. Не совсем понял, что имелось в виду.

Serj-Spb 9 сентября, 2009 11:40:10 EEST .:. ID #17174 .:.

Daemony Спасибо. Раз уж я начал копатся в ipfw помучаю тебя ещё парой вопросов, если не против:
1. Почему\зачем используется явное указание направления когда можно ограничится парой правил бeз in\out или есть необходимость ограничить локалку только tcp?
…
${fw} add allow all from ${innet} to any out via ${inif}
${fw} add allow all from any to ${innet} in via ${inif}
….
${fw} add allow tcp from ${innet} to any in via ${inif}
${fw} add allow tcp from any to ${innet} out via ${inif}

2. Сакральный смысл разворота правил запрета и детализации направления ? - обычно рекомендуют тупо from{запрещенная сеть} to any?
${fw} add deny log ip from any to 0.0.0.0/8 in via ${outif}
….

PS. прошу прощения за опечатку в прошлый раз.

Daemony 7 сентября, 2009 13:03:58 EEST .:. ID #17079 .:.

Serj-Spb: Deamony ,аразмер журнала из-за правила ${fw} add 65534 deny log all from any to any не становится непомерным и не съедает всё доступное место? установленны ограничения в syslog?

Вот что-то типа такого:

# cat /etc/newsyslog.conf | grep security
/var/log/ipfw/security			root:wheel	600  	15	1024	*     	ZB

и пока проблем не было. :)

Serj-Spb 7 сентября, 2009 00:54:54 EEST .:. ID #17051 .:.

Deamony ,а размер журнала из-за правила ${fw} add 65534 deny log all from any to any не становится непомерным и не съедает всё доступное место? установленны ограничения в syslog?

Daemony 26 августа, 2009 22:21:43 EEST .:. ID #16467 .:.

Nuser: Странная затыка. В общем, получилось так. если на внут интерфейсе 192.168.1.10 (или любой другой кроме 1.1) - то все работает - порты прокидываются верно (там просто еще кой-какие прокинуты:smile: ). если ставлю 1.1 с изменением rc.conf, hosts, resolv.conf, natd.conf, rules.firewall - до меня (до шлюза) все ок. до той тачки на CentOS пакеты проходят (по логам /var/log/security) но приглашение не выдается. и до другой с виндой по портам 2ХХХХ не проходят. с настройкой шлюза 1.10 - все везде нормально…:cry:при этом bind опустил, так как приехал контроллер наконец (наконец-то у начальства nslookup ya.ru говорит хорошие вещи). на шлюзе 1.1 ОБЯЗАТЕЛЬНО! (ну вот задача такая). Решил вот как. поставил 1.10 и _alias_0= 1.1

Честно, так до конца не понял что ты имел в виду. :lol: Ну да ладно, раз разобрался, молодец. За тебя рад. :) Употребляю я пиво, но, судя по всему, ты в Нижнем Новгороде, а я в Днепропетровске… Потому пиво в ближайшее время попить не получится. Просто вспомни обо мне добрым словом, когда будешь пить с друзями или с коллегами на работе. Мне этого будет достаточно. :roll:

Nuser 26 августа, 2009 19:18:21 EEST .:. ID #16457 .:.

СПАСИБО ТЕБЕ, Daemony!!!! В любом случае с меня пиво или то, что ты употребляешь. Только скажи куда выслать!!!! :wink:

1 ... 4 5 6

Возник вопрос по этой теме, или есть что добавить? Говорите!

  1. Зарегистрированным пользователям вводить защитный код (captcha) не приходится.
  2. Загрузить свою аватарку Вы сможете, зарегистрировавшись на сервисе www.gravatar.com
Публикуя комментарий Вы подтверждаете, что ознакомились c Правилами и принимаете их!
HOMOSAPIENS ONLY! :)