| Руководство по pfSense 2.0. Часть 7 Трансляция сетевых адресов (NAT) |
 |
 |
 |
| 02.04.12 11:38 | ||||
|
Руководство по pfSense 2.0. Часть 7 Часть 7 Трансляция сетевых адресов (NAT)
 Рисунок 7.2. Пример перенаправления порта После нажатия Save (Сохранить), вы вернётесь к списку перенаправляемых портов, и увидите вновь созданную запись, как показано на рисунке 7.3 "Список перенаправляемых портов".  Рисунок 7.3. Список перенаправляемых портов Вы можете дважды проверить правила брандмауэра, как видно на странице Firewall -> Rules вкладки Interfaces, для интерфейса на котором было создано перенаправление портов. Это показывает, что трафик будет разрешён в NAT IP на соответствующий порт, как и показано на рисунке 7.4. "Правило брандмауэра для перенаправление порта". Рисунок 7.4. "Правило брандмауэра для перенаправление порта" Возможно, вы захотите ограничить источник (Source) автоматически сгенерированного правила. Для таких сервисов, как почтовые сервера, которые должны быть широко доступны, это мало практично, однако для сервиса VNC, в данном примере, это вполне вероятно, поскольку будет существовать небольшое количество хостов, которые должны иметь возможность VNC подключения к серверу через Интернет. Создание алисов для авторизованных хостов и изменение источников с any на алиас - наиболее безопасный способ, чем оставить источник открытым для любых хостов Интернет. Начальную проверку вы можете произвести без ограничений источника, а после проверки ограничить источники по своему усмотрению. Если всё выглядит правильно, перенаправление порта должно работать при проведении испытаний. Если что-то пошло не так, обратитесь к разделе 7.9.1, "Устранение неполадок перенаправления портов", далее в этой главе. 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. Перенаправление трафика с использованием форвардинга портов Другое использование форвардинга портов - прозрачное перенаправление трафика из вашей внутренней сети. Перенаправление портов указывается для LAN интерфейса или другого внутреннего интерфейса который будет перенаправлять соответствующий трафик к специфическому назначению. Наиболее часто это используется для организации передачи трафика прозрачного HTTP прокси на прокси-сервер или перенаправления всех исходящих SMTP запросов к одному серверу. Замечание Система к которой вы направляете трафик должна размещаться на другом интерфейсе брандмауэра. В противном случае сетевой трафик будут перенаправляться на себя. В случае HTTP-прокси сервера с перенаправлением портов по локальной сети, свои запросы никогда не смогут покинуть, если сервер находится на OPT интерфейсе. В pfSense 1.2.3 нет возможности форвардинга портов на внутреннем интерфейсе, но данная функция востребована и возможно будет включена в версию 2.0. Запись NAT показаная на рисунке 7.5, "Пример перенаправления с помощью форвардинга портов" - является примером конфигурации, позволяющей перенаправлять весь трафик HTTP, поступающий на интерфейс LAN к Squid (порт 3129) на хосте 172.30.50.10. Помните, что сервер к которому вы направляете трафик должен находиться на другом интерфейсе, отличном от того, который используется для форвардинга порта, как было сказано выше. 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 Для конфигурирования 1:1 NAT сначала добавьте виртуальный IP для публичного IP адреса который будет использоваться записью 1:1 NAT, как описано в разделе 6.8. "Виртуальные IP". Теперь перейдите к странице Firewall -> NAT и нажмите на закладку 1:1. Нажмите [+] для добавления записи 1:1. 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) Внешняя подсеть - место где определён публичный IP адрес или диапазон IP адресов для отображения 1:1. Это может быть простой IP адрес указанный с маской /32, или диапазон CIDR выбранный другой маской. 7.3.2.1.3. Внутренняя подсеть (Internal subnet) Внутренняя подсеть - место где определён внутренний IP адрес или диапазон IP адресов для отображения 1:1. Этот IP адрес или диапазон может быть разрешён на одном из ваших внутренних интерфейсов, к которым напрямую присоединена подсеть, или через статический маршрут. 7.3.2.1.4. Описание (Description) Это опциональное поле не имеющее прямого влияния на запись 1:1 NAT. Его заполнение позволит вам легко идентифицировать эту запись при работе с брандмауэром в будущем. 7.3.2.2. Пример конфигурации 1:1 для одного IP адреса В этом разделе мы рассмотрим, как настроить запись 1:1 NAT с одним внутренним и одним внешним IP. В этом примере, 10.0.0.5 - виртуальный IP адрес на WAN. В большинстве развёртываний он должен заменяться одним из ваших публичных IP адресов. Почтовый сервер для которого настраивается отображение, находится в сегменте DMZ и использует внутренний IP адрес 192.168.2.5. Запись 1:1 NAT отображающая 10.0.0.5 на 192.168.2.5 показана на рисунке 7.7. "Запись 1:1 NAT". Диаграмма отображающая эту конфигурацию показана на рисунке 7.8 "Пример 1:1 NAT -Единственный внутренний и внешний IP".  Рисунок 7.7. "Запись 1:1 NAT" Таблица 7.1. Отображение /30 CIDR - соответствие финальных октетов
Последний октет IP адресов не обязательно должен быть одинаковым внутри и снаружи, но я рекомендую делать так когда это возможно. Например в таблице 7.2. "Отображение CIDR /30 - не совпадение финальных октетов" схема отображения будет действительной. Таблица 7.1. Отображение /30 CIDR - не соответствие финальных октетов
Я рекомендую выбирать схему адресации, в которой последние октеты совпадают, поскольку это делает её проще, для понимания, и соответственно для поддержки. Рисунок 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 Для трафика инициированного в WAN, сначала применяются правила NAT, а затем правила брандмауэра. Обратите внимание, что tcpdump всегда участвует как первый и последний - первый на входящем интерфейсе, до любых обработок NAT или брандмауэра, и последний на исходящем интерфейсе. Это позволяет узнать реальную ситуацию "на проводе". (Смотрите главу 25, "Захват пакетов"). 7.4.1. Экстраполяция для дополнительных интерфейсов В предыдущих диаграммах иллюстрируются только два основных интерфейса развёртывания - LAN и WAN. Когда брандмауэр работает с интерфейсами OPT и OPT WAN, применяются те же правила. Все интерфейсы OPT ведут себя аналогично LAN, а все интерфейсы OPT WAN ведут себя аналогично WAN. Трафик между двумя внутренними интерфейсами ведёт себя так же как трафик между LAN и WAN, хотя по умолчанию, правила NAT не будут транслировать трафик между внутренними интерфейсами, т.ч. уровень NAT ничего не делает в данном случае. Если вы определили правила исходящего NAT которые проверяют трафик между внутренними интерфейсами, то они будут применяться как было показано. 7.4.2. Правила для NAT Для правил интерфейсов WAN или OPT WAN, поскольку NAT транслирует IP назначения трафика перед его оценкой правилами брандмауэра, ваши правила брандмауэра для WAN всегда должны указывать частный IP адрес в качестве пункта назначения. Например, при добавлении форвардинга порта для TCP 80 на WAN, и установленном флаге Auto-add firewall rule, это приводит к созданию правила брандмауэра на WAN. Внутренний IP адрес для форвардинга порта - 192.168.2.5. Используете ли вы форвардинг порта или 1:1 NAT, правила брандмауэра на всех интерфейсах WAN должны использовать внутренний IP в качестве адреса назначения. Обратимся к рисунку 7.13, "Правила брандмауэра для форвардинга порта к хосту LAN ", приводящему пример того как должны появляться такие правила.  Рисунок 7.13, "Правила брандмауэра для форвардинга порта к хосту LAN" 7.5. Зеркальный NAT Зеркальный NAT - способность получить доступ к внешнему сервису из внутренней сети по публичному IP-адресу, так, как если бы вы находились в Интернет. Многие коммерческие и open source брандмауэры вовсе не поддерживают данную функцию. pfSense имеет несколько ограниченную поддержку зеркального NAT, хотя в некоторых средах будет требоваться разделение инфраструктуры DNS для внедрения этой функциональности. Разделение DNS рассматривается в разделе 7.5.2., "Разделение DNS". 7.5.1. Настройка и использование зеркального NAT Чтобы включить зеркальный NAT, перейдите на страницу System -> Advanced. Прокрутите страницу вниз и снимите флаг Disable NAT Reflection (Отключить зеркальный NAT), как показано на рисунке 7.14. "Включение зеркального NAT". Нажмите кнопку Save (Сохранить) и зеркальный NAT будет включён. В дальнейшей настройке нет необходимости, режим начинает работать немедленно.  Рисунок 7.14. "Включение зеркального NAT" 7.5.1.1. Предостережение использования зеркального NAT Зеркальный NAT - практически всегда предоставляет дополнительные возможности взлома, такие как создание петли трафика через брандмауэр. Для ограничения возможностей таких сценариев, в реализации зеркального NAT pfSense введены некоторые ограничения. Диапазон портов содержащий более 500 портов не будет включаться в зеркальный NAT, а 1:1 NAT не поддерживается. Разделение DNS является единственным средством размещения больших диапазонов портов и 1:1 NAT. Я хотел бы сказать, что эта ситуация улучшится в pfSense 2.0, но это маловероятно, из за проблем реализации, учитывая ограничение базового ПО. Поддержка разделения инфраструктуры DNS требует так же многими коммерческими брандмауэрами и обычно не является большой проблемой. 7.5.2. Разделение DNS Предпочтительная альтернативой зеркального NAT - развёртывание инфраструктуры с разделённым DNS (Split DNS). Разделение DNS, это конфигурация, в которой ваш публичный Интернет DNS разрешает ваши публичные IP, а DNS в вашей внутренней сети разрешает внутренние, частные IP-адреса. Способ размещения будет зависеть от вашей специфики инфраструктуры DNS, но конечный результат будет тем же. Таким образом, вы можете обойти необходимость использования зеркального NAT путём разрешения имён хостов во внутренних, частных IP адресах. 7.5.2.1. Переопределение форвардера DNS Если вы используете pfSense как DNS сервер для внутренних узлов, вы можете использовать переопределение форвардера DNS для реализации развёртывания разделённого DNS. Чтобы добавить переопределение форвардера DNS, перейдите на страницу Services -> DNS Forwarder и нажмите [+] под надписью "You may enter records that override the results from the forwarders below" (Ниже, вы можете ввести записи которые переопределяют результаты форвардеров), как показано на рисунке 7.15., "Добавление переопределения форвардера DNS". Эта операция вызовет переход к экрану DNS forwarder -> Edit. Рисунок 7.16, "Добавление переопределения форвардера DNS для example.com" и рисунок 7.17, "Переопределение форвардера DNS для www.example.com" показывают примеры переопределения DNS для example.com и www.example.com. Вам необходимо добавить переопределение для каждого хоста используемого за брандмауэром. 7.5.2.2. Внутренние серверы DNS При использовании других серверов DNS в вашей внутренней сети, например это часто бывает при использовании Microsoft Active Directory, вам необходимо создать зоны для всех доменов размещающихся в сети, наряду со всеми прочими записями этих доменов (A, CNAME, MX и прочие). В условиях работы BIND DNS, когда публичный DNS размещается на том же сервере где и частный DNS, BIND использует разрешения DNS для внутренних хостов иначе чем для внешних. если вы используете другой DNS сервер, он тоже может поддерживать подобную функциональность. Следует обратиться к его документации. 7.6. Исходящий NAT (Outbound NAT) Исходящий NAT контролирует как должен транслироваться трафик покидающий вашу сеть. Для его настройки перейдите на страницу Firewall -> NAT и выберите закладку Outbound (Исходящий). В pfSense существует два варианта конфигурирования исходящего NAT, автоматическая генерация правил исходящего NAT и ручная генерация правил исходящего NAT (Advanced Outbound NAT (AON)). В сетях с единственным публичным IP адресом WAN, как правило, нет причины использовать AON. В средах с множеством публичных IP адресов, это может быть не желательно. В средах использующих CARP, важно, использовать исходящий NAT для трафика идущего к IP-адресу CARP, как описано в главе 20, "Избыточность брандмауэра/Высокая доступность". 7.6.1. Правила исходящего NAT по умолчанию. При использовании стандартного автоматического исходящего NAT, pfSense автоматически создаёт правила NAT для трансляции трафика покидающего любую внутреннюю сеть к IP-адресу WAN интерфейса с которого он уходит в Интернет. 7.6.2. Статический порт По умолчанию, pfSense переписывает исходный порт во всех исходящих пакетах. Многие ОС плохо выполняют рандомизацию порта источника. Это упрощает IP-спуффинг и позволяет снимать отпечатки хостов находящихся за брандмауэром с исходящего трафика. Перезапись порта источника устраняет эти потенциальные уязвимости. Тем не менее, это может нарушить работу некоторых приложений. Такие типы трафика, как UDP 500 (трафик IKE VPN) и 5060 (SIP), практически всегда нарушаются при переписывании исходящего порта. для всего остального трафика исходный порт переписывается по умолчанию. Вы можете использовать другие протоколы, например, некоторые игры кроме всего прочего, могут не работать должным образом при перезаписи порта источника. Для отключения данной функции вам следует использовать возможность статического порта (Static Port). Перейдите на страницу Firewall -> NAT и нажмите вкладку Outbound. Нажмите Manual Outbound NAT rule generation (Advanced Outbound NAT (AON)) и нажмите Save. Вы увидите правило в низу страницы помеченное как Auto created rule for LAN (Автоматически созданное правило для LAN). Нажмите кнопку [e] справа от правила для его редактирования. Отметьте флаг Static Port на этой странице и нажмите Save. Примените изменения. После принятия изменений порт источника для данного трафика будет сохранён. 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-адрес и порт должны быть транслированы и разрешены брандмауэром. 7.8.1.2.3. Расширенный пассивный режим Расширенный пассивный режим (EPSV) работает аналогично режиму PASV, но с поддержкой использования IPv6. Когда клиент запрашивает передачу, сервер будет отвечать портом на который требуется соединиться клиенту. Для серверов в режиме PASV применяются те же замечания. 7.8.1.3. FTP сервера и форвардинг портов Для корректной работы форвардинга портов с FTP прокси требуется: - публичный IP должен являться IP WAN интерфейса или типа CARP VIP, поскольку FTP прокси должен иметь возможность слушать на публичном IP, а ARP-прокси и тип Other VIP не позволяют это делать. - FTP хелпер должен быть включён на WAN интерфейсе, на котором используется форвардинг порта - сервер должен использовать порт 21. 7.8.1.4. FTP сервер и 1:1 NAT Когда для размещения FTP сервера использует 1:1 NAT, необходимо сделать три вещи, чтобы обеспечить FTP прокси функционалом, позволяющим FTP нормально работать. - используйте тип CARP VIP. Поскольку FTP-прокси должен иметь возможность слушать на VIP, а типы VIP ARP-прокси и Other не позволяют этого, вы должны использовать CARP VIP с любыми записями 1:1 NAT серверов FTP - включите FTP-хелпер на WAN, где сконфигурирована запись 1:1. Найдите интерфейс на котором располагается внешняя подсеть 1:1, в меню Interfaces. В развёртывании с одним WAN, это меню Interfaces -> WAN. Убедитесь, что флаг Disable the userland FTP proxy application под FTP Helper, не установлен. - добавьте запись форвардинга порта для TCP 21. Это может быть несколько странно, но как только вы инициировали FTP хелпер для прослушивания на 1:1 NAT IP, будет добавлена запись форвардинга порта использующая те же внутренние и внешние IP адреса и TCP порт 21. На самом деле, этот процесс не добавит указанную конфигурацию NAT, поскольку система распознаёт записи 1:1 NAT, а просто позволит запустить FTP-прокси на этом IP. Этот процесс станет более ясным в pfSense 2.0, но существующее поведение будет сохранено для обратной совместимости. 7.8.2. TFTP Стандартный TCP и UDP трафик инициированный соединениями к удалённым хостам использует случайный исходный порт в эфемерном диапазоне портов (диапазон зависит от операционной системы, но находится в пределах 1024-65535), и порт назначения используемый протоколом. Ответы от сервера к клиенту возвращают - порт источник, который является портом назначения клиента и порт назначения, который является портом источником клиента. Таким образом, pf связывает ответный трафик соединения инициированный из вашей внутренней сети. Однако, протокол TFTP (Trivial File Transfer Protocol) не следует этому правилу. Стандарт, определяющий TFTP, RFC 1350, указывает, что ответ с сервера TFTP для клиента будет получен с псевдослучайного номера порта. Ваш клиент TFTP может выбрать порт источник 10325 (например), и использовать порт назначения TFTP 69. Сервер для других протоколов отправил бы ответ используя порт источника 60 и порт назначения 10325. Поскольку TFTP использует псевдослучайный порт источника, ответный трафик не будет соответствовать состоянию pf созданному для этого трафика. Следовательно, ответы будут заблокированы, поскольку они будут расцениваться как нежелательный трафик Интернет. TFTP не является широко распространенным протоколом Интернет. Единственная проблема может возникнуть при использовании IP телефонов, которые подключаются к внешним провайдерам VoIP в Интернет с помощью TFTP для получения конфигурации и дополнительной информации. В настоящее время не существует возможности обхода данной проблемы - TFTP не будет работать через pfSense 1.2. pfSense 2.0 включает TFTP прокси который устраняет данные ограничения. 7.8.3. PPTP/GRE Ограничения работы с PPTP в pfSense вызвано ограничением возможностей pf к выполнению NAT для протокола GRE. Следовательно, ограничения распространяются на любое использование протокола GRE, а PPTP - наиболее применяемый протокол использующий GRE. Код отслеживания состояний pf для протокола GRE может отслеживать только одну сессию на публичном IP внешнего сервера. Это означает, что если вы используете соединение PPTP VPN, одновременно, можно подключить только одну внутреннюю машину к серверу PPTP в Интернет. Тысячи машин могут одновременно подключаться к тысячи различных серверов PPTP, но только одна одновременно к одному серверу. Один клиент может подключить неограниченное количество внешних серверов PPTP. Обойти эту ситуацию можно используя несколько публичных IP адресов, по одному на клиента, с помощью Outbound NAT или 1:1 NAT, либо использовать несколько публичных IP адресов на внешнем сервере PPTP. С другими типами VPN соединений эта проблема не возникает. В связи с теми же ограничениями GRE, если вы включите PPTP сервер на pfSense, вы не сможете подключиться к любому PPTP в Интернет с клиентов за NAT на WAN IP pfSense. Подобные работы потребуют использование более чем одного публичного IP-адреса. Вы можете транслировать внутренних клиентов на другие публичные адреса, которые подчиняются тем же ограничениям. Поскольку мы, в значительной степени, полагаемся на функциональность базовой системы, и просто оборачиваем GUI вокруг данной функциональности, решение данной задачи является не тривиальным. На момент написания статьи мы исследуем возможности решения данной проблемы в pfSense 2.0, но пока решение не найдено. 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.2.3, "Добавление форвардинга порта", и дважды проверьте свои настройки. Помните, что если вы изменили IP адрес NAT или порты, вам необходимо скорректировать соответствующие правила брандмауэра. В целом следует проверить: - Корректность интерфейса (как правило WAN, там где трафик будет входить в pfSense) - Корректность NAT IP, который должен быть доступен на интерфейсе маршрутизатора pfSense - Корректность диапазона портов, который должен соответствовать сервису, который вы пытаетесь перенаправить. 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, "Захват пакетов" для более детального изучения процесса захвата пакетов. |
||||
| Последнее обновление 02.04.12 14:42 |
