Простой шлюз

  

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

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

конечном счёте это избавит вас от головной боли, которую я слишком часто наблюдал в

списках рассылки и группах новостей.

Делай это просто: как избежать ловушек in, out и on           При конфигурировании единственной машины, всё выглядит достаточно просто.Трафик который вы  создаёте должен выпускаться  во  внешний  мир или  блокироваться  вашими правилами фильтрации; и вы сами решаете, что вы хотите впустить к себе из вне. При настройке шлюза приоритеты меняются. Вы переходите от мышления "Я здесь – сеть там" к мышлению вида "Я тот кто решает что разрешить для тех кто ко мне подключен".

Машина  шлюз  имеет  несколько,  или  по  крайней  мере  два   сетевых   интерфейса подключенных к разным сетям, и его основная функция (или по крайней мере та функция

в которой мы заинтересованы) – передача трафика между сетями.

Вполне разумно считать, что, если вы  хотите разрешить трафик с сетевого  соединения интерфейса re1 к хостам на сетевом интерфейсе re0, вам необходимо правило подобное следующему1.

pass in proto tcp on re1 from re1:network to re0:network port $ports keep state

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

1 На самом деле хранение состояний является поведением по умолчанию, и является избыточным, если вы работаете с PF OpenBSD 4.1 или выше. Однако, как правило, нет необходимости удалять спецификации существующих правил, с которыми вы сталкивались при обновлении  с ранних версий. Для облегчения перехода, примеры этой книги  упоминают об этом когда это необходимо

именованый интерфейс указанный в правиле. Для того, чтобы пакеты двигались дальше и перешли в  другую сеть, вам необходимо соответствующее правило, которое говорит что- то вроде этого:

pass out proto tcp on re0 from re1:network to re0:network port $ports keep state

Пожалуйста,  остановитесь  и  прочитайте  эти  правила  ещё  раз.  Последнее  правило позволяет    проходить   только   пакетам   с   назначением   в      сети    непосредственно подключенной  к  re0,  и  больше  ничего.  Если  это  именно  то,  чего  вы  добивались  – прекрасно. В  другом  контексте, такие  правила,  вполне  правильные,  могут  оказаться слишком конкретизированными  чем того  требует ситуация. Весьма легко погрузиться в специфические    детали    и    потерять    более    высокую    точку    зрения    на    цели конфигурирования, тем самым заработав несколько дополнительных раундов на отладку.

Если  есть  веские   причины  для  написания  очень  конкретных  правил,   таких  как предыдущие, вероятно вы уже знаете почему нуждаетесь в  них. К тому времени, как вы

закончите читать эту книгу (а может быть и раньше) вы должны быть в состоянии ясно

сформулировать   обстоятельства   необходимости   использования   слишком   детальных правил.

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

в  ряде случаев, это бесполезно для указания направления, а для доступа в интернет из локальной сети вы будете просто использовать правило подобное следующему.

pass proto tcp from re1:network to port $ports keep state

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

Источник: Книга о PF, by Peter N.M. Hansteen, Перевод выполнил Михайлов Алексей aka iboxjo

Похожие посты:

Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий