17 сентября 2021, 10:04

Цитата дня:

Не допустить ошибок, значит прожить неполноценную жизнь. Стив Джобс


Traffic Inspector 2.0.0.644 при запуске службы пропадает интернет

Автор Призрак, 14 октября 2019, 21:27

« предыдущая тема - следующая тема »

0 Пользователей и 1 Гость просматривают эту тему.

Вниз

Призрак

Всем привет. Знаю, знаю, что устарела программа. Мне один товарищ, из техподдержки, как пьяный попугай, это твердил. Ну нет денег у учебного заведения, что поделаешь. И не факт, что будет работать. Я не буду ругаться насчёт программного обеспечения, чтобы не раздувать конфликт. Но хотелось бы узнать, как его корректно настроить и перенести всё на "чистую", выполнив импорт только пользователей, групп и фильтров. Никаких настроек я не менял, могу поклясться, чем угодно. На Windows Server 2008 R2 эта программа должна работать, это же указано в требованиях системных. Кроме того, менял драйвер на новый, никакого толку.

Беда грянула неожиданно. Пропал интернет, в административном корпусе. Пошарив немного, я понял, что проблема в этой поделке русских программистов. Останавливаю службу, интернет тут как тут. Запускаю, снова пропал. Да что такое. Всё обшарил, всё перенастроил. Чтобы в меня не кидались, обвиняя в некомпетентности, я сделал так - остановил службу, потом убрал папки config и data, при запуске службы я запустил снова, папки создались новые. Интернет появился, только тогда, при запущенной службе, что прямо доказывает, что виновна программа.

Traffic Inspector установлен на шлюзе, с установленным NAT и двумя сетевыми картами. Настроен RRAS. При этом на сетевой карте, которая смотрит в локальную сеть, прописаны адреса DNS серверов, 192.168.10.12 и 192.168.10.13. Вот когда я включаю службу, то и на клиентах и на сервере появляется интересное сообщение, в командной строке, если пытаться пинговать по имени узла - не удалось обнаружить имя узла ya.ru. Проверьте имя узла и повторите попытку. Такое чувство, что поделка блокирует интерфейсы, но почему.

OpenVPN работает отлично.

Уваров А.С.

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

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

Призрак

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

Уваров А.С.

Ну у нас же студенты учатся, чтобы только авторизованным пользователям давать доступ.
Логин/Пароль? Так много способов. Squid или PPPoE поднять.

Призрак

#4
16 октября 2019, 06:55 Последнее редактирование: 16 октября 2019, 07:12 от Призрак
Я пробовал на виртуальной VirtualBOX машине дома pfsense, к сожалению, он не умеет работать с виртуальными сетями, как следует. Я даже импортировал существующие сертификаты OpenVPN, сервера и клиента, соответственно, на две машины, pfsense, с двумя сетевыми картами каждая - сетевого моста и внутренней сети, соответственно, два клиента, по одной сетевой карте, с внутренней сетью, соответствующей каждой из машин. OpenVPN поднялся и заработал, я в брандмауэре открыл порты, как в руководстве, даже маршруты пробовал прописывать, там в таблице маршрутизации всё ОК было, я проверял лично. Но, к сожалению, пакеты от клиента до клиента, а также от любого клиента до противоположного pfsense так и не пошли, хотя я и ICMP разрешал. Поставить пробовал на VMWare, там ещё хуже - даже получив настройки WAN по DHCP pfsense не смог достучаться до шлюза. Пишет что шлюз wan offline. К слову сказать, та же схема на VirtualBOX со шлюзами на Windows у меня получилась. Смотрел в сторону zeroshell, мне очень не понравилось, что некомпетентные разработчики сделали отображение в консоли логина с паролем, в открытом виде. Большей глупости и нельзя придумать.

Уваров А.С.

А кто мешает взять в руки просто Linux и настроить все как надо, без оглядки на то, что придумали авторы панелей? OpenVPN ведет детальный лог, по которому легко выявляются все проблемы. а маршрутизация она везде одинакова.

Призрак

#6
16 октября 2019, 09:14 Последнее редактирование: 16 октября 2019, 09:20 от Призрак
Так главное и в логах то всё в порядке! Я вижу, что соединение установлено, пакеты даже какие - то идут. Но при попытке пинговать соседний шлюз по серому нет ответа, почему - то. Трассировку делаю, пакеты только до шлюза доходят, дальше нет. Но я маршруты писал, бесполезно всё.

Уваров А.С.

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

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

Призрак

Я не знаю, стоит ли писать в эту тему дальше, так как Traffic Inspector меня больше не интересует. Мне прислали хамское письмо с техподдержки, тыкали законами, хотя лицензия легально приобретённая. Не хочу больше связываться с их продуктом. Я не знаю, какие ещё привести доказательства того, что у нас отвалилась сеть из-за них.

Теперь меня больше интересует межсетевой экран pfsense. Я посмотрел на него, со всех сторон, не уступает он микротику, а даже OpenVPN там реализован намного лучше. Мне удалось настроить OpenVPN вот по этой статье, между двумя pfsense.

https://docs.netgate.com/pfsense/en/latest/book/openvpn/site-to-site-example-configuration-ssl-tls.html

Всё работает прекрасно. Единственное, что меня напрягает, это то, что, возможно, придётся создавать новый сервер, OpenVPN, но на другом порту и с другим пулом, это уже для подключения локальных клиентов, не с pfsense. Подробно посмотрю, как это делается. Я подключаюсь из дома, бухгалтерия.

Я пока не хочу вникать в Squid. Меня больше интересует вот что. Чтобы загнать в домен pfsense или сделать авторизацию по ad нужно выбрать между LDAP и RADIUS. Как вы думаете, чему мне стоит отдать предпочтение?

Уваров А.С.

Опять таки стоит вопрос: для чего вы это хотите использовать? Какая конечная цель поставленной задачи. Выше вы писали про доступ студентов, сейчас откуда-то появились доменные пользователи.

Призрак

#10
20 октября 2019, 20:16 Последнее редактирование: 20 октября 2019, 20:18 от Призрак
Конкретно задачи таковы:

1. Усилить безопасность сети от атак извне.

2. Запретить доступ к сети не авторизованным пользователям к локальной сети заведения, чтобы имели к сети доступ только сотрудники. Доступ к социальным сетям и прочей шелухе не интересует совсем. Или есть доступ, или его нет.

3. Сделать более стабильным соединение OpenVPN, удобным управление.

4. Сэкономить ресурсы машины, к сожалению, они у нас не резиновые, сервера.

Насчёт откуда - то появившихся доменных пользователях - а как вы сами думаете, удобно в браузере набирать ip адрес или же удобочитаемое доменное имя? Наверное, всё - таки, второе. У меня FreeNAS установлен, для резервного копирования, четыре штуки, они все авторизованы. Для того, в основном, чтобы набирать в браузере для доступа доменное имя вместо ip адреса.

К тому же, а как же ещё сделать доступ SQUID к доменным пользователям, для той самой авторизации? В общем, вопрос LDAP или RADIUS остаётся открытым. Все пояснения я дал.

Уваров А.С.

1. К теме обсуждаемого вопроса не относится.
2. Откуда неавторизованные пользователи во внутренней сети?
3. Как pfSense повысит стабильность? Все что он вам даст - это веб интерфейс к OpenVPN.
4. Каким образом?

Идем далее, доменное имя (FQDN) никоим образом к Active Directory не относится. Тем более крайне не рекомендуется пересечение пространства имен AD и внешнего домена.

К тому же, а как же ещё сделать доступ SQUID к доменным пользователям, для той самой авторизации? В общем, вопрос LDAP или RADIUS остаётся открытым. Все пояснения я дал.
Squid прекрасно работает через Kerberos без необходимости его ввода в домен.

При этом остается непонятным, кого и где вы собрались аутентифицировать и для чего. Для выхода в интернет?

Вверх