Центр деятельности TMG по сравнению с pfSense

Я думаю, что Вашим данным нужны некоторые новые приближения, так как обычный ответ сервера DNS меньше, чем 520 байтов (на самом деле, большинство маршрутизаторов (или сетевое оборудование) может дать Вам головные боли, когда размер пакета UDP передает метку 512 КБ - но мы не говорим здесь только о UDP).

Здесь это идет - будет использовать два очень известных инструмента Linux для приближения размера типичного запроса DNS. выройте linux.org +stats

; <<>> DiG 9.6.1-P1 <<>> linux.org +stats
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7061
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;linux.org.                     IN      A

;; ANSWER SECTION:
linux.org.              43200   IN      A       198.182.196.48

;; AUTHORITY SECTION:
linux.org.              43180   IN      NS      ns0.aitcom.net.
linux.org.              43180   IN      NS      ns.invlogic.com.

;; Query time: 239 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Oct 29 11:52:44 2009
;; MSG SIZE  rcvd: 100

Как Вы видите, я сделал запрос DNS локальному серверу DNS, петлевому интерфейсу (для простоты и clarness). Необходимо найти интересным последняя строка "РАЗМЕР MSG"...

Подтвердите это с tcpdump (работающий на петлевом интерфейсе):

IP localhost.36855 > localhost.domain: 7061+ A? linux.org. (27)
IP localhost.domain > localhost.36855: 7061 1/2/0 A 198.182.196.48 (100)

Что Вы видите в конце каждой строки, это - фактический размер (вещь, которую Вы ищете).

Я советую Вам выполнять несколько тестовых запросов и насчитывать Ваш размер запроса DNS в Ваших вычислениях. Внимательно наблюдайте за доменами, которые не являются directely, подаваемым с Ваших серверов DNS (который должен быть интересным битом).

Kaplah.

3
задан 17 December 2010 в 03:12
4 ответа

Нет никакого сравнения, потому что они - действительно два полностью отдельных продукта, которые нацелены на два различных рынка. Отчасти, как Вы никогда не будете, вероятно, видеть сравнение Феррари 599 против Bugatti Veryon. Оба сумасшедших быстрых дорогих автомобиля, но нацеленный на два различных рынка.

Я использовал обоих. На самом деле наш внутренний офис использует TMG, и наш удаленный сайт использует PFSense, и он действительно сводится к тому, чем Вы находитесь после в устройстве брандмауэра и Вашей способности поддержать.

Я нахожу PFSense бризом для поддержания. Настраивая ссылки обработки отказа, туннели IPSec, VPNs, и т.д. очень очень простой. Все это намного более сложно в TMG, но поэтому TMG очень тесно интегрируется в Вашу среду Active Directory.

TMG может также сделать основанную на хосте маршрутизацию HTTP, тогда как PFSense не может, таким образом, можно использовать один IP-адрес через несколько внутренних веб-серверов, не нуждаясь в определенном обратном прокси.

Одна из лучших вещей о TMG - то, что можно эффективно выключить всего доступ в Интернет одного человека путем отключения их AD учетной записи в брандмауэре. Никакая потребность настроить любую аутентификацию Сквида с RADIUS против Вашего AD и затем настраивающий ACLs.

Я сказал бы, что TMG является более трудным изучить затем PFSense, если Вы запускаете с необработанной подложки.

9
ответ дан 3 December 2019 в 04:40

Точно как Mark сказал, они - очень два совершенно различных продукта. Если Вы ищете прокси-сервер, это тесно интегрируется с Active Directory и обеспечивает убивание хорошей функциональности в той области, Вы хотите TMG. Если Вам нужно, усовершенствовал NAT, маршрутизацию, мульти-WAN, гибкие межплатформенные опции VPN, и т.д. Вы где-нибудь между некоторыми, минимальной и несуществующей функциональностью с TMG, но pfSense предлагает много в тех областях и широко развертывается для тех вещей.

Возможно, наилучший вариант? Используйте обоих. TMG в сети, pfSense в краю, и Вы получаете лучший из обоих миров.

6
ответ дан 3 December 2019 в 04:40

И точно так же, как сказали Mark и точно так же, как Chris, продукты отличаются слишком много, чтобы быть друг по сравнению с другом, и теперь, я сделаю это более "несправедливым", потому что я сравню некоторые различия между TMG SP1 + Обновление программного обеспечения 1 по сравнению с Бета-версией pfSense 2.

pfSense является невероятным брандмауэром со многими хорошими и расширенными функциями и чрезвычайно низкими требованиями к аппаратным средствам по сравнению с TMG. Это свободно и обновляется быстро. Это просто в использовании и очень быстро отвечает на Ваши настройки.

pfSence, кажется, обрабатывает огромные правила блокирования БЫСТРЕЕ, чем TMG, и можно заметить, что в потоке трафика в обоих концах брандмауэра (после того, как пакеты были обработаны) и Вы также заметите, что ответ GUI довольно быстр на pfSense по сравнению с очень медленным TMG. Не попробовали выравнивание нагрузки за этот тест.

Когда дело доходит до устойчивости и надежности, pfSense, кажется, не имеет шанса вообще. Мы сделали стресс-тест с установкой 10 машин с 8 потоками каждым плюс 2 FTP-сервера и ферма SharePoint с 2 узлами позади брандмауэра подключенный к Интернету через 1 волокно Gbit. Кроме того, у нас было 6 других машин, подключенных к Интернету через отдельные строки на 100 Мбит (различные местоположения с различным от 4 ISPs) для нарушения трафика, который тек через брандмауэр. Без помех, поток трафика через брандмауэр TMG находился на рассмотрении где-нибудь между 60-120 МБ/с (в восходящем направлении и в нисходящем направлении) и с полным нападением от всех 6 "нарушителей", производительность снизилась до 30-70 МБ/с. Веб-страницы на сервере SharePoint отвечали довольно справедливые во время нападений. Тот же тест с pfSense как брандмауэр был ужасен :-( Пропускная способность снизилась до 2-30 МБ/с и большинство нажатий (от внешней сети) на приведенной к таймауту веб-странице SharePoint. Мы даже изменили аппаратные средства на другого производителя, чтобы быть уверенными, что это не были никакие проблемы совместимости с pfSense и сервером (серверами), но было трудно сказать, поправилось ли это или хуже.

Я не соглашаюсь, что TMG имеет минимальную функциональность для использования в качестве усовершенствованного NAT, маршрутизации, несколько WANs и т.д.; pfSense предлагает больше, но абсолютно не НАМНОГО больше.

Для использования с клиентами Windows на внутренней части TMG предлагает намного больше функциональности, особенно, если объединено с остальной частью семейства ForeFront.

Отчеты и контролирующий в TMG намного лучше, чем pfSense.

Если Вы действительно хотите сравнить TMG с другим брандмауэром, попробуйте Cisco. Мне нравится комбинация ASA и TMG.

Если Вы намереваетесь остаться партнер MS в течение долгого времени, я предлагаю, чтобы Вы использовали свои преимущества партнера для его пределов!;-)

3
ответ дан 3 December 2019 в 04:40

+1 для проблем со стабильностью / управлением с PfSense. Я думаю, что команда создала выдающийся продукт по сравнению с другими проектами с открытым исходным кодом и бесплатными проектами. С учетом сказанного: такие вещи, как исчезновение Webconfigurator и невозможность управления системой, быстро ухудшают ее удобство использования в корпоративной среде. вот ссылка одна, а интернет завален ими: http://forum.pfsense.org/index.php?topic=38965.0

Это типичный случай невозможности сравнить коммерческий продукт с открытым исходным кодом, качества просто нет. Я не собираюсь вдаваться в дебаты по этому поводу, поэтому, защищая открытый исходный код, пока что я видел ровно 1 продукт: видеокодер x264, который превосходит любую коммерческую версию. Остальное больше похоже на научный проект, чем на то, что вы хотели бы использовать там, где важна стабильность.

-2
ответ дан 3 December 2019 в 04:40

Теги

Похожие вопросы