РЕШЕНО! Port Forward перестает работать каждый день
-
Добрый день народ,
:'(Очень нужна помощь!!!
Имеется сервер dell PE1800 с установленным PfSense 64 бит (сперва обновленный с версии 2.2.4) 2.3.1-RELEASE-p5.
На встроенной сетевой карточке intel em настроены vlan для внешних сетей (3 ISP - Uznet 27, Uznet213, SITA 151). Кроме того, имеются еще 3 сетевухи - VPN ведомственный, локальная сеть и DMZ зона, где имеются серваки, в т.ч. веб-сервак на базе Win 2008 + IIS.На основном внешнем канале (UzNET 27) настроен Port Forward в DMZ зону (публичный адрес:порт 80 - в нужный адрес DMZ:порт 80).
Внешние IP адреса настроены как IP alias для интерфейса UzNET 27.
На версии PfSense 2.2.4 Port Forward работал без проблем.После обновления клиенты начали жаловаться, что не могут достучаться до веб-серверов. Отмечено, что с момента обновления до 2.3.1-RELEASE, где-то через каждые 3-4 часа после перезагрузки пропадает доступ к внутренним серверам. Также время от времени (примерно через 2-3 дня) сильно тормозит выход из локальной сети в Интернет через PfSense.
Для тестирования открыл доступ ICMP и стал пинговать.Да, кстати, сделал Packet Capture UZNET27. Так вот, когда пропадает доступ к веб-серваку, на интерфейсе UZNET27 нет информации о пингах или доступе к порту 80 из внешней сети за пределами моего периметра.
В тоже время, доступ к веб и пинги спокойно проходят из моей внешней подсети, т.е. другого публичного IP адреса сети UZNET27. Все это прекрасно видно также на Packet Capture.Такое ощущение, что маршрутизатор провайдера (шлюз для UZNET27) не пересылает пакеты на мой PfSense или по крайней мере они не доходят.
Но, почему-то после перезагрузки PfSense (больше ничего - свитчи, маршрутизаторы и серверы не трогаю) все начинает работать, к сожалению, не долго.
В логах замечено следующее:
Jul 17 14:37:05 birinchi nginx: 2016/07/17 14:37:05 [error] 35362#0: send() failed (54: Connection reset by peer) периодически
Jul 17 12:07:00 xinetd 23251 Reconfigured: new=0 old=1 dropped=0 (services) периодически
Jul 17 12:07:00 xinetd 23251 readjusting service 6969-udp периодически
Jul 17 12:07:00 xinetd 23251 Swapping defaults периодически
Jul 17 12:07:00 xinetd 23251 Starting reconfiguration периодически
Jul 17 11:53:36 php-fpm /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use UZNET27GW. периодическиJul 17 11:52:36 dpinger VPN 10.0.20.245: sendto error: 65 каждую секунду, после каждой перезагрузки меняется интерфейс, т.е. UZNET 213, UZNET 27, SITA 151, но только те, где есть шлюз
Jul 17 15:17:48 filterdns: failed to resolve host 46.8.3.5.0 will retry later again. очень часто появляется эта ошибка, интересно что почему IP из 5 октетов 46.8.3.5.0?
Jul 16 10:11:40 openvpn 19734 ioctl(TUNSIFMODE): Device busy: Device busy (errno=16) (постоянно вылезает эта ошибка)
Также странно, что во вкладке Firewall ничего не отображается.
Мужики, очень срочно нужна помощь, сильно по шапке получаю.
Если нужна дополнительная информация, скажите.
-
Доброе
Смените порт веб-фейса пф с 80-го на что-то отвлеченное. И https тоже. -
Дружище, спасибо за отклик.
Я уже отключил веб морду по 80 порту, а 443 перевел на другой порт с самого начала через меню advanced. Или нужно как-то по другому?Дополнительное инфо. Вчера настроил порт маппинг на другом интерфейсе SITA151, та же самая история.
Сегодня целый день тестировалА почему веб-морда может влиять гна порт маппинг, ведь я настраиваю для IP alias, а не основного IP интерфейса.
Еще вопрос, если можно. 512мб оперативки на 25мб линк и 500 пользователей может мало, хотя судя по дашборду все ок, не более 60-70%
-
Jul 17 15:17:48 filterdns: failed to resolve host 46.8.3.5.0 will retry later again. очень часто появляется эта ошибка, интересно что почему IP из 5 октетов 46.8.3.5.0?
Проверяйте ваши Firewall: Aliases
По поводу проблем с провайдером вполне возможно — у нас была проблема , когда коммутатор провайдера просто переполнял MAC таблицу адресов, симтомы становились похожими — проподание связи, пока оператор не перезагружал коммутатор.
-
Проверяйте ваши Firewall: Aliases
Спасибо большое за подсказку. Действительно, сам оказывается вбил в алиасы 5-значный IP.
Это исправил.Проблему с Port Forward решил: т.е. полностью снес NAT таблицы и виртуальные IP - ВСЕ.
Потом заново вбил все то же самое и вуаля ЧУДО заработало. Пока тестирую, через 2-3 дня отпишусь.Странно, на 2,2,4 версии все работало, после обновления до 2,3,1 перестало.
Установка шлюза с чистого листа и накат файла конфигурации не помогли, наоборот, вообще пропала связь с настроенными Port Forward веб-серваками.Вдруг у кого-то окажется такая же фигня.
