Как стать автором
Обновить

Комментарии 35

Проблема с клиент-банками решается с помощью опции Stickly Connections — смысл в том, что поддерживается установленное соединение через один из каналов, в отличии от балансировки по разным каналам для других правил.
Кириллические логины/пароли — это не проблема pfSense как таковой, а проблема используемого для аутентификации демона.
И да, pfSense заточен именно на конфигурацию через Web интерфейс для использования его широким кругом людей, в т.ч. не желающих умеющих работать с командной строкой. Разбирающиеся в настройке из консоли осилят (возможно и предпочтут) и настройку роутера на чистой FreeBSD.
Да, еще по поводу HAVP — дважды подумайте, нужен ли Вам такой тормоз в системе? Наверное лучше посмотреть в сторону Squid + ICAP+CLAM.
Про данную связку слышал и при написании статьи думал о ней, но я старался использовать доступные пакеты «из коробки», а там возможности подобную связочку собрать я не нашел.
Она есть в пакетах, но пока только тестовая. При наличии умелых рук заставить работать «как надо» вполне реально.
Спасибо, проверю. При работе с тестовыми версиями пакетов пока вообще на проблемы не натыкался.
Спасибо за совет по клиент-банкам, завтра попробую.
Поищите еще на форуме поддержки тему, там она уже поднималась. Возможно я написал не все, и что-то упустил.
Если Stickly Connections не помогут — можно в настройках фаервола (LAN --> Advanced --> Gateway) прибить гвоздями клиент-банк к выбранному провайдеру.
НЛО прилетело и опубликовало эту надпись здесь
i386 — не желателен, если есть возможность всегда нужно брать amd64.

Можете обосновать свою позицию?
И да, лучше брать образ для i386 системы, так как AMD в pfSense пасынок.
Я так понимаю, что под «amd64» — подразумевается x86_64, поэтому не стоит проводить параллель с вендором AMD ;)

А нежелательно потому, что в дальнейшем у Вас возникнут проблемы с масштабированием системы, когда ей понадобиться больше ресурсов.
Здесь согласен (и действительно путаю). Правда есть еще один вариант — использовать виртуальную машину. Из плюсов — возможность гибко управлять ресурсами и использовать «излишки» ресурсов для других задач.
НЛО прилетело и опубликовало эту надпись здесь
Привет, Коллега =)

Прекрасная статья!
Буду ждать воторой части.
Привет, спасибо на добром слове! Вторая часть будет обязательно.

Обманщик ;)

Ну так не сказано когда :)

Все ближе и ближе тот день )

Я так понимаю, у вас не было необходимости решать вопрос PPTP passthrough? Суть в том, что подключиться к внешнему PPTP серверу находясь за pfSense почти невозможно, если у вас нет «лишних» IP адресов. Официальная информация из документации: раз, два и тема на форуме. Мне пришлось отказаться от pfSense из за отсутствия данной возможности.
Нет, такой задачи не было. По возможности стараюсь не связываться с PPTP, но если с той стороны только он и без удаленки никак, то это печальная история.
Мы же просто отказались от PPTP в пользу L2TP.
При сильной необходимости можно с самого pfSense поднять необходимое число туннелей и маршрутить в них людей.
Дак вроде L2TP в pfsense не умеет работать с поддержкой IPSec. Или Вам нужно было только туннелирование?
Верно, нужны были только туннели.
Что-то я не очень понял: а без использования прокси разве нельзя юзверям запретить одноклассников с ютубом?
Надо было запретить не всем, а только части. Некоторые, типа отдела кадров и маркетинга, ходили туда, чтобы группы вести и прочее. Прокси дарует аутентификацию, по ней и отсеиваем юзеров. Я может не очень Вас понял, какое решение Вы предлагаете?
Да я просто спросил. Решения не предлагаю. Просто сейчас я в поиске некого подобия pfSense (а может и на нём остановлюсь), чтобы были хотелки как минимум:
1) Поддержка VPN сервера
2) Возможность фильтрации траффика
3) Наличие GUI для непрофессионалов

Касательно фильтрации было б классно (как по мне)
1) Предварительно в DHCP сервере сделать «перепись населения» и каждому присвоить свой IP на основе MAC'a
2) Разбить пользователей по группам, чтоб допустим как вы говорили отдел маркетинга всегда имел доступ к соцсетям
3) Настроить фильтрацию на основе групп пользователей и времени. Т.е. например
— группа «администраторы + директора» = полный доступ в инет всегда
— группа «обычные пользователи» = без доступа в инет, кроме обеденного перерыва со стольки до стольки
— возможно какие-то исключения
+ шейпер, чтоб какой-то умный Вася, запустив uTorrent не мешал работать VPN клиентам, которые сидят на сервере по RDP.
А вот pfsense как раз решит все Ваши задачи. VPN умеет разный, кроме L2TP/IPSec. Фильтрации трафика -легко, это же FreeBSD, шейпер «из коробки». Группы создаете или в AD или прям так перечислением диапазонов адресов, адресов, логинов. Контроль времени также есть. Все просто и удобно.
Спасибо, потренируюсь пока в виртуалке, а потом и на реальном железе.
Отличная статья, огромнае спасибо, а будут ли продолжения?
Подскажите пожалуйста.
Проброшен 80-й порт. Сайт с наружи открівается, а из локальной сети показівает веб-морду pfsense.
Говорят надо смотреть в сторону локального DNS?
Самое простое — это настроить в DNS разрешение имени сайта в его локальный IP адрес.
Не самое простое — нужно на шлюзе донастроить NAT/
Простите за археологию, но не увидел тут корректного ответа, а вопрос этот новичками задаётся довольно часто.

Идём в System / Advanced
находишь пункт WebGUI redirect и ставишь галочку. Вообще-то там прямо так и написано что это
Disable webConfigurator redirect rule

И не забудьте в разделе:
Firewall / NAT / Port Forward / внизу в NAT reflection

Перевести в режим NAT+Proxy

Всем лучики добра и читать мануалы ;-)
Спасибо. Но я для решения перевел WebGUI на 81-й порт.
Ну это понятно, однако даже если переведёте вебгуй на др. порт, то от редиректа в морду нужно всё же ставить такую галку.
То есть при простом пробросе портов появляется проблема с доступом из локалки к локальным ресурсам по внешнему адресу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории