Политики брандмауэра не применяются к попыткам ping/tracert?
Я почти ничего не знаю о сети, поэтому извиняюсь, если это глупый или странный вопрос.
Наше системное администрирование / ИТ-поддержка передается на аутсорсинг консалтинговой компании. Я работал с ними, чтобы попытаться выяснить проблему маршрутизации. У нас настроена маршрутизация на основе политик, которая должна направлять любые попытки подключения к определенному диапазону IP-адресов через отдельный маршрутизатор. Поскольку у меня еще нет программы, которая будет использовать это соединение, я пытался проверить, правильно ли он был настроен через tracert. Эта политика иногда правильно перенаправляет его на отдельное соединение, а остальная часть времени она неправильно маршрутизируется с помощью политики подключения к Интернету для всех целей.
Человек, с которым я работал в консалтинговой компании, не мог этого понять, поэтому ему пришлось связаться с их представителем в Watchguard. Они определили, что это вызвано тем, что политика интернет-маршрутизации по умолчанию имеет более высокий рейтинг в списке политик, чем конкретная политика диапазона IP. Когда проблема продолжилась после исправления, представитель сказал, что политики брандмауэра в любом случае не будут влиять на попытки ping или tracert, и что любые программы, пытающиеся подключиться к IP в заданном диапазоне, будут правильно маршрутизироваться.
У меня еще не было возможности проверить это с конкретным приложением, которое будет использовать соединение. Однако я вижу, что некоторые попытки подключения к определенным IP-адресам случайным образом перенаправляются на отдельное подключение, когда IP-адреса не должны были запускать эту политику. Кажется, что все политики настроены правильно, поэтому я думаю, что это проблема брандмауэра. Заявление представителя о политике брандмауэра, не затрагивающей ping / tracert, имеет смысл? Мне, вероятно, придется снова связаться с ними, чтобы исправить это, но я хотел заранее знать, может ли этот парень знать или не знать, о чем он говорит.
2 ответа
ping использует ICMP, обычно traceroute генерирует трафик UDP или ICMP (разница Unix/Windows). Следовательно, технически вы должны иметь возможность легко отличить диагностический трафик от сгенерированного приложением трафика на основе используемого протокола (при условии, что он использует TCP).
Следовательно, возможно, что политика маршрутизации настроена на применение только к TCP-трафику (в качестве примера). Таким образом, утверждение в вашем вопросе может быть действительным. Но это будет конкретное решение администратора. Не должно быть никаких проблем с применением политики ко всему трафику, независимо от его типа, на основе диапазонов IP-адресов. Поэтому, если они захотят, диагностический трафик будет использовать ту же политику. На самом деле, я думаю, что было бы разумнее сделать это в первую очередь.
Тем не менее, у представителя может быть некоторая заслуга, поэтому вы не должны увольнять его слишком рано. Но я буду осторожен, так как другие проблемы, о которых вы упоминаете (политика срабатывает, когда этого не должно быть), означают, что, возможно, существуют некоторые проблемы с конфигурацией. Так что в равной степени вероятно, что он действительно не знает, о чем говорит.
Хороший ответ от Karol Picza - нужно различать TCP, UDP и ICMP. В качестве дополнительного пункта, который поможет вам устранить неполадки, взгляните на Linux Toold под названием traceproto, Это очень похоже на стандарт traceroute с дополнительной функциональностью, позволяющей указывать протокол и порт, тогда как стандартная трассировка маршрута использует только ICMP.