Меню

Настройка pfsense для sip

Configuring NAT for a VoIP PBX¶

For VoIP there are typically a few components to get right for proper inbound and outbound audio from a local PBX.

Port forward entries with firewall rules (Or 1:1 NAT with Firewall Rules)

Manual Outbound NAT with a rule at the top set to perform static port NAT on traffic from the PBX (Or 1:1 NAT)

On the PBX, ensure it is set properly for NAT with the correct external IP and local subnets defined.

Aliases to make it easy¶

It is easiest to start by making a few entries under Firewall > Aliases to make the rules easier to accomplish:

Host alias for the PBX itself, named PBX, containing the local IP address of the PBX.

Network or Host alias called SIP_Trunks for the upstream SIP trunk addresses, if known. If the SIP_Trunk address/network is not known or changes, do not make an alias and leave these values set to any.

Port alias called PBX_Ports containing all of the port numbers needed for SIP, RTP, and other control ports. (usually 5060 and 10000:20000, but varies from provider to provider and PBX implementation)

Port Forwards¶

For the port forward (Firewall > NAT, Port Forwards tab), it can be set as follows:

Interface: WAN

Protocol: UDP (or TCP/UDP if needed)

Source: Type Single Host or Alias: SIP_Trunks – or a Any for the type if the SIP trunk IP addresses are not known.

Source Port: any/any

Destination: WAN address or external VIP for the PBX

Destination Port: PBX_Ports

Redirect target IP: PBX

Redirect target port: PBX_Ports

Manual Outbound NAT¶

For Manual Outbound NAT, navigate to Firewall > NAT, Outbound tab, switch from Automatic Outbound NAT to Manual Outbound NAT and press Save. Then at the top of the list, create a rule that looks like so:

Interface: WAN

Protocol: UDP

Source: Network, PBX

Source Port: [blank]

Destination: Network, SIP_Trunks – Or Any for the type if the SIP trunk IP addresses are not known

Destination Port: PBX_Ports (or leave blank)

Translation: Interface address if using the WAN IP address, or the external VIP for the PBX

Port: [blank]

Static Port: CHECKED

Reset States¶

After making the changes to NAT rules, the states for the PBX must be reset.

Navigate to Diagnostics > States

Enter the IP address of the PBX and click Filter

Click Kill

Once the PBX re-registers it test inbound and outbound calls and confirm inbound and outbound audio works as expected.

Источник

Настройка шлюза на базе Pfsense. Часть 1

Что всегда заметит каждый пользователь? Правильно, отсутствие интернета. Но как? «Вконтакте» не грузится — значит, интернета нет. Но ведь бывает, что директор или бравые богатыри из отдела ИБ хотят что-то запретить, что-то собрать, где-то проконтролировать. И тут администратор начинает танцевать вокруг шлюза в интернет. Если в компании много денег, то танцы могут быть длительными и с галантными кавалерами (мар Checkpoint, мистер PaloAlto, господин SonicWall). А вот что делать, если денег только на железо, функционала хотят много, а делать надо быстро? Бежать. На помощь приходит Mr Proper Pfsense, активно поддерживаемый сообществом бесплатный, гибкий и несложный в настройке межсетевой экран на базе FreeBSD.

В первой части рассмотрим классику жанра — межсетевой экран с прокси (аутентификация по учетным данным Active Directory) и фильтрацией контента, а также какой-никакой антивирусной проверкой трафика налету. Отдельно рассмотрим вопрос настройки удаленного доступа пользователей к сети предприятия.

Если будет интерес, могу написать вторую часть инструкции по развертыванию, где рассмотрю вопросы балансировки между несколькими провайдерами, создания и одновременной работы двух шлюзов, а также добавления фич безопасности типа IPS/IDS, фильтр спама, более кошерной фильтрации средствами Dansguardian, сниффинга IM и HTTPS контента и много чего еще интересного.

Для уменьшения возможного холивара: «Да, это можно сделать на %yourdistrname%» и «Да, все можно настроить из командной строки». Так, все формальности соблюдены — можно начинать.

Установку сделаем с флешки. Для этого используем образ pfSense-memstick-2.2.2-RELEASE-i386.img.gz, скачанный с одного из зеркал, указанных на официальном сайте. Очень удобно, что сначала мы выбираем архитектуру, функционал, а потом уже нам предлагают список зеркал. Процесс установки детально расписывать не буду, там все элементарно, никаких дополнительных настроек не нужно. По окончанию установки вам предложат назначить VLAN и определить интерфейсы, а также их назначение. Выглядит это примерно так:

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

Первым делом создаем свой внутренний CA на pfsense или используем уже имеющийся. Для этого в меню System выбираем Cert Manager и в разделе CA проводим необходимые настройки: нужно указать длину ключа, алгоритм хэширования, время жизни и полное имя CA. Настроенный CA будет нам нужен для создания OpenVPN-сервера и для работы по LDAPS.

Теперь интегрируем наш шлюз с Active Directory. В разделе Servers блока User Manager из меню System были проведены настройки на использование контроллера домена. Все до безобразия просто — указал адрес, транспорт, область поиска, контейнеры с учетками, креды для создания привязки и шаблон для заполнения Microsoft AD — можно выпускать кракена пользователей в интернет.

Перейдем к настройке правил фильтрации трафика. Во-первых, если требуется любая группировка адресов, портов, URL, тогда добро пожаловать на вкладку Aliases. Во-вторых, вы можете настроить временные промежутки, которые можно использовать для работы правил. По умолчанию создано правило «всем везде все можно», а также правило, которое не дает заблочить доступ к веб-морде. Создание правил выглядит довольно буднично:

Однако есть ряд дополнительных возможностей, например, разрешенные ОС, какие могут быть выставлены TCP-флаги, график работы правила, а также инспектор протоколов прикладного уровня.

Настройка удаленного доступа OpenVPN с аутентификацией по паролю в локальной базе и сертификату можно посмотреть тут — www.youtube.com/watch?v=VdAHVSTl1ys. Выбор протоколов удаленного доступа невелик — IPSec, L2TP, PPTP и OpenVPN. При выборе PPTP сам pfsense напишет Вам, что протокол небезопасен и лучше выбрать другой.

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

Для экспорта настроек OpenVPN для устройств на разных платформах нужно установить пакет OpenVPN Client Export Utility, который есть в списке доступных для установки пакетов. Теперь возвращаемся к истокам – во вкладку Cert Manager, там создаем сертификат для сервера VPN и каждого клиента. Разница только в типе сертификата.

Переходим к настройке сервера OpenVPN. Выбираем режим работы сервера – в моем случае «Remote Access (SSL/TLS + User Auth)», сервер аутентификации, протокол, порт, нужный сертификат сервера VPN и выставляем нужные параметры шифрования. То, что предлагается по умолчанию — не лучший выбор.

Дальше настраиваем VPN-сеть и выставляем настройки для клиентов. Тут мы можем определить, стоит ли выдавать клиенту DNS-сервера, весь ли трафик клиента гнать в туннель и т.д. После этого сохраняемся и отправляемся на вкладку client export. Отсюда мы экспортируем нужные для подключения настройки и сертификат пользователя.

Кстати, при настройке сервера можно было воспользоваться Wizardом, который провел бы Вас через все “печали и невзгоды” настройки OpenVPN. Некий аналог кнопки “Сделать хорошо”.

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

Нам осталось настроить прокси, фильтрацию контента и антивирусную проверку. Устанавливаем HAVP-пакет – это прокси с ClamAV сканером. Для настройки указываем режим работы ClamAV и прокси, порт, интерфейс, настройки проверки проходящего трафика. Поскольку планируется использование squid, то наш режим работы — «Parent for Squid». Отдельно настраиваем параметры обновления антивирусной базы и ее зеркала.

Переходим к настройке Squid. После установки пакета выбираем режим работы прокси и порт, затем на вкладке «Auth Settings» указываем используемый метод аутентификации. Поскольку у нас стоит задача использования Active Directory в качестве базы пользователей, то используем протокол LDAP. Настройки для интеграции с контроллером домена представлены ниже.

При необходимости настраиваем параметры вышестоящего прокси, управления кэшем и трафиком, а также ACL. Я, например, в whitelist вносил *microsoft.com/* для нормальной работы обновлений и активации ОС, и то не сканало. Но об этом чуть ниже.

Читайте также:  Ресивер gs b210 настройка антенны

Теперь фильтрация – настраиваем squidGuardian. По подходам к фильтрации в принципе есть хорошая статья – «To-do: Фильтруем вся и всё». После установки squidGuardian через пункт «Proxy filter» меню «Services» переходим к его настройке. На вкладке «Blacklist» указываем откуда качать сами блэклисты в формате tar или tar.gz, а также на вкладке «General settings» ставим галочку для включения использования блэклистов. Я использовал бесплатные блэклисты отсюда. В случае необходимости работы контентного фильтра по времени, промежутки можно задать на вкладке Times. Дальше уже настраиваете общие или групповые ACL, главное не забыть поставить галочку напротив запрета использования IP-адресов в URL. Для настройки правил фильтрации нужно нажать «Target Rules List» и выбрать действия для нужных категорий, а также действие по умолчанию.

Если у вас есть необходимость в создании собственных категорий, то можно воспользоваться страничкой «Target Categories». После сохранения ваша категория появится в общем перечне правил. Я создавал свою категорию для разрешения доступа к ресурсам по IP-адресам, у которых нет DNS-имени.

А теперь ложка дегтя. Вполне допускаю, что проблемы вызваны собственной кривизной рук, но все же. Если кто-то из сообщества сможет подсказать какие-то решения, то я буду крайне признателен.

1. Разработчики давно обещают, но пока так и не сделали поддержку L2TP over IPSec.
2. Проблемы при попытке срастить pfsense для использования сертификатов AD CS. Я читал обсуждение отсюда, но так и не смог победить мелкомягкого дракона.
3. Проблемы работы клиент-банков в случае, если у вас есть балансировка между провайдерами.
4. Если у вас указана аутентификация пользователей через AD, а контроллер домена недоступен, то ваш встроенный(. ) админ pfsense также откажется работать. Есть обсуждение на форуме, люди пишут скрипты на php для решения вопроса, но это не является рекомендуемым решением.
5. Видимо тут мои личные проблемы с кириллицей. Во-первых, не работает аутентификация в случае использования пароля в кириллической раскладке. Во-вторых, проблемы в отображении имен контейнеров AD на кириллице.
6. Несмотря на все усилия, время от времени возникают проблемы с сервисами от Microsoft. Чаще всего не работает активация ОС. Думаю, тут все же необходимо будет поправить конфиг squid вручную.

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

Источник

Настройка pfsense для sip

Часть 7. Трансляция сетевых адресов (NAT)

7.1. Конфигурация NAT по умолчанию.

В данном разделе описывается конфигурация NAT используемая в pfSense по умолчанию. Чаще всего подходящая конфигурация NAT генерируется автоматически. В некоторых средах вы можете захотеть изменить эту конфигурацию и pfSense позволяет сделать это в полном объёме посредством Web-интерфейса. Это выгодно отличает pfSense от прочих брандмауэров проекта Open Source.

7.1.1. Конфигурация исходящего NAT по умолчанию.

Конфигурация NAT по умолчанию, используемая в pfSense с интерфейсами LAN и WAN автоматически транслирует интернет трафик в WAN IP адреса. Когда настроены несколько WAN интерфейсов, трафик покидающий любой WAN интерфейс автоматически транслируется в адрес используемого WAN интерфейса. Статический порт автоматически настраивается для трафика IKE (часть IPSec) и SIP(VoIP). Статический порт более подробно будет рассмотрен в разделе 7.6, «Исходящий NAT».

7.1.2. Конфигурация по умолчанию для входящего NAT

По умолчанию, никакой трафик из Интернет внутрь не допускается. Если вам требуется позволить трафику инициированному в Интернет попадать в вашу внутреннюю сеть, вы должны настроить форвардинг портов или 1:1 NAT. Эти возможности мы рассмотрим в следующих разделах.

7.2. Порт форвардинг (Port Forwards)

7.2.1. Риски использования форвардинга портов

7.2.2. Перенаправление портов и локальные сервисы

Порт-форвардинг может быть запущен относительно любой службы работающей локально на брандмауэре, например web интерфейсу, SSH и прочим запущенным сервисам. Например, это означает, что если вы позволили удалённый доступ с WAN используя HTTPS на порт TCP 443, если вы добавили перенаправление порта на WAN для TCP 443, то стандартный доступ к web интерфейсу работать не будет. Это не повлияет на доступ к другим интерфейсам.

7.2.3. Добавление перенаправления портов

Рисунок 7.1 «Добавление перенаправления порта»

Рисунок 7.2. Пример перенаправления порта

После нажатия Save (Сохранить), вы вернётесь к списку перенаправляемых портов, и увидите вновь созданную запись, как показано на рисунке 7.3 «Список перенаправляемых портов».

Рисунок 7.3. Список перенаправляемых портов

Рисунок 7.4. «Правило брандмауэра для перенаправление порта»

7.2.4. Ограничения перенаправления портов

Вы можете перенаправить один порт одного внутреннего хоста для каждого доступного публичного IP адреса. Например, если у вас есть только один публичный IP-адрес, вы можете иметь только один внутренний web-сервер, который использует TCP порт 80 для обслуживания web-трафика. Любые дополнительные серверы должны использовать альтернативные порты, например 8080. если у вас пять доступных публичных IP адресов сконфигурированных как виртуальные IP, можно получить пять внутренних web-серверов использующих порт 80. Смотрите раздел 6.8., «Виртуальные IP» для получения подробной информации о виртуальных адресах. Для того, чтобы перенаправить порт на WAN адрес для доступности соответствующего WAN IP адреса с внутренних интерфейсов, вам необходимо настроить рефлективный NAT (NAT reflection), который описывается в разделе 7.5. «Рефлективный NAT». Вы должны всегда проверять ваше перенаправление портов с систем на различных подключениях Интернет, а не изнутри своей сети.

7.2.5. Сервис самоконфигурирования с UPnP

Некоторые программы поддерживают Universal Plug-and-Play (UPnP) для автоматического конфигурирования перенаправления портов NAT и настройки правил брандмауэра. Это создаёт ещё больше проблем безопасности, но в домашних условиях преимущества данной технологии часто перевешивают любые потенциальные проблемы. Смотрите раздел 21.6, «UPnP» для получения дополнительной информации о настройке и использовании UPnP.

7.2.6. Перенаправление трафика с использованием форвардинга портов

7.3. 1:1 NAT

1:1 (произносится как «one to one») NAT отображает один публичный IP адрес на один частный IP адрес. Весь трафик от частного IP адреса к Интернет будет отображаться на публичный IP определённый в отображении 1:1 NAT, перекрывающем вашу конфигурацию исходящего NAT (Outbound NAT). Весь трафик инициированный в Интернет и предназначенный для указанного публичного IP адреса будет транслироваться на частный IP адрес, а затем оцениваться набором правил брандмауэра WAN. Если трафик разрешён правилами брандмауэра, он будет передан на внутренний хост.

Рисунок 7.5, «Пример перенаправления с помощью форвардинга портов»

7.3.1. Риски использования 1:1 NAT

В основном, риск использования 1:1 NAT аналогичен форвардингу портов, если вы позволяете трафик к хосту в правила брандмауэра WAN. Каждый раз, когда вы разрешаете трафик, вы разрешаете потенциально опасный трафик в вашей сети. Существует некоторый дополнительный риск при использовании 1:1 NAT, связанный с тем, что ошибки правил брандмауэра могут иметь более тяжёлые последствия. С записями форвардинга портов вы ограничиваете трафик который будет позволяться в правилах NAT и правилах брандмауэра. Если вы используете форвардинг порта TCP 80, а затем добавляете разрешение правила all на вашем WAN, на внутреннем хосте будет доступен только TCP 80. Если вы используете 1:1 NAT и добавляете разрешения правила all на WAN, все порты внутреннего хоста будут доступны из Интернет. Ошибки всегда потенциально опасны, и, как правило, это не должно рассматриваться как основание к избежанию 1:1 NAT. Просто имейте это в виду при настройке правил брандмауэра и избегайте любых ненужных разрешений.

7.3.2. Конфигурирование 1:1 NAT

7.3.2.1. Поля записи 1:1 NAT

Рисунок 7.6. » Экран редактирования 1:1 NAT» показывает экран редактирования 1:1 NAT, каждое поле которого будет детализовано более подробно.

Рисунок 7.6. «Экран редактирования 1:1 NAT»

7.3.2.1.1. Интерфейс (Interface)

Поле Интерфейс (Interface) предназначено для выбора внешней подсети. Чаще всего это WAN, или OPT WAN интерфейс в multi-WAN развертывании.

7.3.2.1.2. Внешняя подсеть (External subnet)

7.3.2.1.3. Внутренняя подсеть (Internal subnet)

7.3.2.1.4. Описание (Description)

Это опциональное поле не имеющее прямого влияния на запись 1:1 NAT. Его заполнение позволит вам легко идентифицировать эту запись при работе с брандмауэром в будущем.

7.3.2.2. Пример конфигурации 1:1 для одного IP адреса

Рисунок 7.7. «Запись 1:1 NAT»

7.3.2.3. Пример конфигурирования диапазона IP в 1:1

1:1 NAT может быть сконфигурирован для множества публичных IP адресов используя диапазоны CIDR. Суммаризация CIDR рассматривала в разделе 1.7.5. «Суммаризация CIDR». Этот раздел рассматривает конфигурацию 1:1 NAT для диапазона CIDR IP /30.

Внешние IP Внутренние IP

Внешние IP Внутренние IP

Я рекомендую выбирать схему адресации, в которой последние октеты совпадают, поскольку это делает её проще, для понимания, и соответственно для поддержки. Рисунок 7.9, «Запись 1:1 NAT для диапазона CIDR /30», показывает как настроить 1:1 NAT для достижения отображения приведённого в таблице 7.1.

Читайте также:  Настройка новостной ленты яндекс

7.3.3. 1:1 NAT на WAN IP, типа «DMZ» на Linksys

Некоторые популярные маршрутизаторы, такие как Linksys включают в себя то, что они называют «DMZ», куда направляются все порты и протоколы предназначенные для WAN IP к системе находящейся в LAN. Фактически это представляет собой 1:1 NAT между WAN IP и IP адресом внутренней системы. В данном контексте «DMZ» не имеет ничего общего с реальным сетевым термином DMZ. На самом деле всё выглядит совсем наоборот. В реальной DMZ, хост находится в сети изолированной от других хостов LAN, вдали от Интернет и хостов локальной сети. Напротив, «DMZ» хост в понимании Linksys, не только находится в той же LAN где и остальные хосты, но и подвержен входу незащищенного трафика. В pfSense вы не можете получить активный 1:1 NAT на WAN IP. WebGUI не допустит такой конфигурации, поскольку это нарушило бы связь для других хостов сети. Вместо этого, вы должны перенаправлять протоколы и порты, необходимые вашим серверам или приложениям, и ограничивать их использование правилами брандмауэра, там где это возможно. Технически, то же самое вы можете реализовать, перенаправив TCP и UDP порты с 1 до 65535 и протоколы GRE и ESP, однако это весьма строго не рекомендуется делать, поскольку может привести к серьёзным проблемам безопасности.

7.4. Порядок работы NAT и брандмауэра

Понимание последовательности, в которой работают брандмауэр и NAT очень важно при их настройке. Рисунок 7.10, «Последовательность работы NAT и брандмауэра» показывает этот порядок. Кроме того, он описывает участие tcpdump, поскольку использование данного инструмента устранения неполадок будет описано в книге позже (смотрите глав 25, «Захват пакетов»). В данную схему попадают не все уровни. Рисунок 7.11 «Обработка LAN to WAN» и рисунок 7.12, «Обработка WAN to LAN» иллюстрируют то, какие уровни применяются для трафика инициированного из сети LAN в WAN, и обратно (когда такой трафик разрешён). Для трафика из LAN к WAN, сначала оцениваются правила брандмауэра, затем применяется исходящий NAT, при условии, что трафик разрешён. Правила WAN NAT и брандмауэра не применяются к трафику инициированному в LAN.

Рисунок 7.12 Обработка WAN to LAN

7.4.1. Экстраполяция для дополнительных интерфейсов

7.4.2. Правила для NAT

Рисунок 7.13, «Правила брандмауэра для форвардинга порта к хосту LAN»

7.5. Зеркальный NAT

7.5.1. Настройка и использование зеркального NAT

Рисунок 7.14. «Включение зеркального NAT»

7.5.1.1. Предостережение использования зеркального NAT

7.5.2. Разделение DNS

7.5.2.1. Переопределение форвардера DNS

7.5.2.2. Внутренние серверы DNS

При использовании других серверов DNS в вашей внутренней сети, например это часто бывает при использовании Microsoft Active Directory, вам необходимо создать зоны для всех доменов размещающихся в сети, наряду со всеми прочими записями этих доменов (A, CNAME, MX и прочие).

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

7.6. Исходящий NAT (Outbound NAT)

7.6.1. Правила исходящего NAT по умолчанию.

При использовании стандартного автоматического исходящего NAT, pfSense автоматически создаёт правила NAT для трансляции трафика покидающего любую внутреннюю сеть к IP-адресу WAN интерфейса с которого он уходит в Интернет.

7.6.2. Статический порт

7.6.3. Отключение исходящего NAT

Если вы используете публичные IP адреса на локальных интерфейсах, и следовательно, вам нет необходимости применять исходящий NAT для трафика проходящего через брандмауэр, вам следует отключить исходящий NAT для данного интерфейса. Для того чтобы это сделать, вам следует сначала изменить настройки исходящего NAT на Manual Outbound NAT, а затем нажать Save. После этих изменений, одно или несколько правил появятся в списке на экране Outbound NAT. Удалите правило или правила для публичных IP подсетей, нажав на каждой строке (или отметив флаг в начале строки) и нажав кнопку[Х] в нижней части списка для их удаления. Нажмите Apply Changes. После удаления всех правил, исходящий NAT не будет активен для этих адресов, а pfSense будет маршрутизировать публичные IP-адреса без трансляции. Чтобы полностью отключить исходящий NAT, удалите все правила которые присутствуют при использовании Manual Outbond NAT.

7.7. Выбор конфигурации NAT

Ваш выбор конфигурации NAT будет зависеть, в основном от числа доступных публичных IP-адресов и числа систем которым требуется входящий доступ из Интернет.

7.7.1. Единственный публичный IP-адрес WAN

Когда у вас имеется единственный IP-адрес на WAN, ваши опции NAT ограничены. Вы можете использовать 1:1 NAT только с виртуальными IP, не с любыми WAN IP. В данном случае вы можете использовать только форвардинг порта.

7.7.2. Множественные публичные IP адреса на WAN

С множеством публичных IP на WAN, вы получаете несколько опций для конфигурирования вашего исходящего и входящего NAT. В некоторых обстоятельствах могут потребоваться форвардинг портов, 1:1 NAT, и Advanced Outbound NAT.

7.8. NAT и совместимость протоколов

Некоторые протоколы плохо работают с NAT, а некоторые и вовсе не работают. Ряд протоколов внедряют IP адреса в пакеты, некоторые не работают должным образом, если переписывается порт источника, а некоторые испытывают трудности из-за ограничений pf. В данном разделе рассматриваются протоколы, которые испытывают трудности при использовании NAT pfSense, и возможности решения данных вопросов.

7.8.1. FTP

FTP имеет проблемы как с NAT так и с брандмауэрами, поскольку структура протокола первоначально была разработана в 1970 году, а существующий стандарт, определяющий характеристики протокола был написан в 1985 году. FTP был создан более чем за десять лет до появления NAT, и за долго до того, как брандмауэры стали обычным делом, поэтому он делает некоторые вещи, к которым NAT и брандмауэры относятся весьма недружелюбно. pfSense использует два различных приложения FTP-прокси, pftpx и ftpsesame. pftpx используется для всех сценариев NAT, а ftpsesame объединяет бриджинг и маршрутизацию публичных IP-адресов.

7.8.1.1. Ограничения FTP

Поскольку в pf отсутствует возможность правильной обработки FTP-трафика без прокси, а реализация FTP-прокси в pfSense несколько слабая, существуют некоторые ограничения на использование FTP (* В pfSense 2.0, FTP-прокси и его дополнения были устранены. Все эти функции легко обрабатываются более надёжными способами внутри ядра).

7.8.1.1.1. Подключение FTP-клиентов к Интернет

Для подключения FTP клиентов всегда будет использоваться основной интерфейс WAN. Нет возможности использовать любой из интерфейсов OPT WAN. Более подробную информацию о бэтом можно найти в главе 11, «Множественные соединения WAN».

7.8.1.1.2. FTP сервер за NAT

FTP сервер за NAT должен использовать порт 21, т.к. FTP прокси будет запущен только когда указан порт 21.

7.8.1.2. Режимы FTP

7.8.1.2.1. Активный режим

В активном режиме FTP, когда требуется передача файла, клиент слушает локальный порт, а затем сообщает серверу IP-адрес клиента и номер порта. Сервер, соответственно, подключается к IP адресу и соответствующему порту для передачи данных. Эта проблема существенна для брандмауэров, поскольку порт, обычно выбирается случайно, хотя современные клиенты позволяют ограничить используемый диапазон выбора. Как вы возможно догадались, если клиент находится за NAT, IP- адрес будет локальным, недоступным для сервера. Кроме того, необходимо добавить правила брандмауэра для порта, и разрешено движение трафика на этот порт. Когда используется FTP-прокси, он пытается сделать три вещи. Во-первых, он переписывает команду PORT FTP таким образом, чтобы IP адрес соответствовал WAN IP брандмауэра и рандомизирует выбор порта на этом IP адресе. Далее, прокси добавляет форвардинг порта, который соединяет транслируемый IP адрес и порт с оригинальным IP адрес и портом указанный клиентом FTP. И наконец, прокси позволяет трафик с FTP сервера для соединения с этим «публичным» портом. Когда всё работает как надо, все операции производятся прозрачно. Сервер никогда не знает, что он общается с клиентом находящимся за NAT, а клиент не знает, что сервер не подключён непосредственно. В случае, когда сервер находится за NAT, это не становится проблемой, поскольку сервер будет только слушать порт для установления соединения на стандартном порту FTP, а затем создавать исходящее соединение обратно к клиенту.

7.8.1.2.2. Пассивный режим

Пассивный режим (PASV) действует обратным способом. Для клиентов, он более дружествен NAT и брандмауэру, поскольку сервер, а не клиент, прослушивает порт когда запрашивается передача файла. Как правило, пассивный режим будет работать на FTP клиентах находящихся за NAT, без использования прокси или специальных обработок. Однако, если сервер находится за NAT, этот трафик должен быть проксирован в обратном направлении, если клиенты пытаются использовать пассивный режим. FTP прокси может справиться с этим сценарием, но все входящие FTP запросы будут приходить с системы pfSense, а не от клиентов. По аналогии с предыдущим разделом, когда клиент запрашивает пассивный режим, сервер должен дать ему IP адрес и случайный порт к которому клиент может подключиться. поскольку сервер находится в частной сети, IP-адрес и порт должны быть транслированы и разрешены брандмауэром.

Читайте также:  Настройка почты inbox на андроиде

7.8.1.2.3. Расширенный пассивный режим

Расширенный пассивный режим (EPSV) работает аналогично режиму PASV, но с поддержкой использования IPv6. Когда клиент запрашивает передачу, сервер будет отвечать портом на который требуется соединиться клиенту. Для серверов в режиме PASV применяются те же замечания.

7.8.1.3. FTP сервера и форвардинг портов

7.8.1.4. FTP сервер и 1:1 NAT

7.8.2. TFTP

7.8.3. PPTP/GRE

7.8.4. Онлайн игры

Игры, как правило, являются дружественны к NAT, но здесь существует несколько оговорок. Этот раздел рассматривает компьютерные игры с возможностями работы через Интернет, а так же подобные игровые консоли. В данном разделе приводится обзор опыта многочисленных пользователей pfSense. Я рекомендую посетить Gaming board на форуме pfSense [http://forum.pfsense.org], чтобы найти больше информации. 7.8.4.1 Статический порт Некоторые игры не могут работать должным образом, если вы не включаете статический порт. Если у вас возникли проблемы с игрой, лучшим решением будет попробовать включить статический порт. Обратитесь к разделу Статический порт для получения дополнительной информации. 7.8.4.2. Несколько игроков или устройств за одним NAT В некоторых играх существует проблема, когда несколько игроков или устройств находятся за одним NAT. Эти вопросы кажутся характерными для NAT, а не для pfSense, поскольку пользователи, которые пробовали использовать другие брандмауэры испытывали те же проблемы. Для решения данного вопроса вам следует обратиться на форум pfSense.

7.8.4.3. Преодоление проблемы NAT с помощью UPnP

Многие современные игровые системы поддерживают UPnP, для автоматической настройки любых специфических потребностей с точки зрения NAT, форвардинга портов и правил брандмауэра. Вы можете обнаружить, что включение UPnP на pfSense позволяет легко обеспечить работу игр. Смотрите раздел 21.6, «UPnP» для получения дополнительной информации о настройке и использовании UPnP.

7.9. Поиск и устранение неисправностей

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

7.9.1. Решение проблем использования форвардинга портов

Форвардинг портов, в частности, может быть проблемным поскольку существует много вещей которые могут пойти не так, как ожидалось. Многие проблемы могут возникать на стороне клиента, а не в pfSense. Большинство проблем, с которыми сталкиваются наши пользователи, были решены одной или несколькими следующими рекомендациями.

7.9.1.1. Некорректная запись форвардинга порта

7.9.1.2. Отсутствующие или некорректные правила брандмауэра

После проверки настроек форвардинга портов, дважды проверьте корректность настройки правил брандмауэра. Некорректность правила брандмауэра будет очевидно при просмотре журнала брандмауэра (Раздел 6.10, «Просмотр журналов брандмауэра»). Помните, что назначением для правила брандмауэра должен быть внутренний IP адрес на целевой системе, а не адрес интерфейса содержащего форвардинг порта. Смотрите раздел 7.4.2. «Правила NAT» для получения большей информации.

7.9.1.3. Включение брандмауэра на целевой машине

Другим, не менее важным моментом является то, что pfSense может корректно осуществлять форвардинг порта, однако брандмауэр на целевой машине может блокировать этот трафик. Если на целевой системе присутствует локальный брандмауэр, необходимо проверить его журналы и настройки, чтобы убедиться блокируется или не блокируется трафик.

7.9.1.4. pfSense не является шлюзом на целевой системе

Для того, чтобы pfSense правильно осуществлял форвардинг порта для локальной системы, он (pfSense) должен являться шлюзом по умолчанию для этой системы. Если pfSense не является шлюзом по умолчанию, целевая система будет пытаться отправить ответы на трафик форвардинга из любой систем являющейся шлюзом. Далее случится одно из двух: в этой системе трафик будет сброшен, поскольку нет никакого соответствующего состояния соединения на маршрутизаторе, или к нему будет применён NAT данного маршрутизатора, а затем он будет сброшен системой в связи стем, что ответ приходит с иного адреса отличного от того с которого поступил первоначальный запрос.

7.9.1.5. Целевая машина не слушает на перенаправленном порту

Если, при тестировании соединения, запрос будет сброшен по таймауту, скорее всего pfSense перенаправляет соединение корректно, а отклонение производится целевой системой. Это может произойти, если целевая система не имеет соответствующего сервиса слушающего запросы порта, или если перенаправляемый порт не соответствует порту, на котором слушает целевая система. Например, если целевая система, как предполагается, слушает SSH соединения, но перенаправление порта установлено для 23 порта вместо 22, скорее всего, запросы будут отклонены. Вы можете проверить доступность порта различными путями, например соединившись по telnet. Сообщение о ботказе подключения указывают на то, что хост сбрасывает подключения.

7.9.1.6. Провайдер блокирует перенаправляемый порт

В некоторых случаях, провайдеры осуществляют фильтрацию входящего трафика изестных портов. Проверьте условия обслуживания вашего провайдера (TOS) и посмотрите наличие пункта о работающих серверах. Такие ограничения наиболее часто встречаются для персональных соединений, чем для коммерческих. Если вы сомневаетесь, обратитесь к провайдеру для разъяснения ситуации. Если порты фильтруются провайдером, возможно вам придётся перенести свои сервисы на другой порт для обхода фильтрации. Например, если ваш провайдер не позволяет сервер на порту 80, попробуйте использовать 8080 или 8888. прежде чем обходить фильтрацию, проконсультируйтесь с вашим провайдером, чтобы не нарушать общие правила.

7.9.1.7. Тестирование изнутри своей сети, а не снаружи

По умолчанию, форвардинг порта будет работать только при соединении из вне вашей сети. Это очень распространённая ошибка при проверке форвардинга портов. Если вам требуется работать с форвардингом внутренне, смотрите раздел 7.5., «Зеркальный NAT». Тем не менее, использование Split DNS (раздел 7.5.2. «Разделение DNS») является более правильным и элегантным решением данной проблемы, исключающей необходимость полагаться на зеркальный NAT или форвардинг порта, и оно стоит затраченных усилий.

7.9.1.8. Некорректный или отсутствующий виртуальный IP адрес

При использовании IP-адресов, не являющихся фактическими IP-адресами назначенными интерфейсу, вам необходимо использовать виртуальные IP (VIPs, смотрите раздел 6.8, «Виртуальные IP»). Если форвардинг порта на альтернативный IP адрес не работает, вам придётся перейти на другой тип VIP. Например, вам может понадобиться использовать тип Proxy ARP вместо Other. При тестировании, так же следует убедиться, что вы подключаетесь к надлежащему VIP.

7.9.1.9. pfSense это не пограничный маршрутизатор

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

7.9.1.10 Необходимо дальнейшее тестирование

Если ни одно из данных решений не помогло достичь рабочего форвардинга порта, обратитесь к главе 25, «Захват пакетов» для получения информации о использовании захвата пакетов для диагностики проблем форвардинга портов.

7.9.2. Устранение проблем зеркального NAT

Зеркальный NAT (раздел 7.5, «Зеркальный NAT») является более проблемным и чаще работает не так, как ожидалось. Мы не можем вам рекомендовать просто использовать вместо него Split DNS (смотрите раздел 7.5.2, «Разделение DNS»). Если зеркальный NAT не работает как ожидается, убедитесь, что он был включён правильно, и что в не перенаправляете большой диапазон портов. Правила зеркального NAT дублируются для каждого интерфейса системы, поэтому, если у вас много перенаправлений портов и интерфейсов, число отражений может превысить ограничения системы. если это произойдёт, соответствующие записи появятся в системных журналах.

7.9.2.1. Web доступ не работает при включение зеркального NAT

Если у вас неорректно указан форвардинг порта NAT, это может вызвать проблемы при включении зеркального NAT. Наиболее часто эта проблема возникает, если у вас имеется локальный web-сервер, а порт 80 направляется на него с некорретно указанного внешнего адреса (External Address). Если зеркалный NAT включен и External Address установлен как any, любые соединения проходят на ваш web-сайт. Для исправления такого поведения, измените форвардинг порта NAT для порта и измените внешний адрес (External Address) на адрес интерфейса (Interfaces Address). Если вам действительно требуется установить значение внешнего адреса в any, то зеркальный NAT не будет работать, и вы должны будете использовать Split DNS.

7.9.3. Решение проблем исходящего NAT

Если у вас включён ручной исходящий NAT, и присутствует несколько локальных подсетей, записи исходящего NAT необходимы для каждой из них. Особенно это важно, если вы хотите получить трафик выходящий с NAT после прихода в pfSense маршрутизатор через VPN соединение, такое как PPTP или OpenVPN. Одним из признаков отсутствия правила исходящего NAT будет наблюдение пакетов покидающих интерфейс WAN с исходными адресами частной сети. Смотрите главу 25, «Захват пакетов» для более детального изучения процесса захвата пакетов.

Источник

Adblock
detector