В птс ошибка в номере двигателя: Действия, если номер двигателя не совпадает с птс

Содержание

Купил автомобиль, номер двигателя не совпадает с ПТС

Открыть содержание

С 7 октября 2018 года действуют новые Правила регистрации транспортных средств, утвержденные Приказом МВД №399 от 26.09.18, которые в том числе описывают процедуру регистрации замены двигателя. Если после покупки автомобиля при его регистрации в ГАИ окажется, что на нем установлен неродной мотор, а номер двигателя не совпадает с указанным в ПТС, то у нового собственника могут возникнуть проблемы… Но не всегда. Разберемся с вопросом во всех тонкостях.

Что говорит закон 2021 года о двигателях?

С 2011 года двигатель является запасной частью. И с тех пор на его замену не нужно получать разрешения ГИБДД. Впрочем, не нужны и никакие документы на устанавливаемый и снимаемый агрегат.

Замена двигателя на полностью идентичный внесением изменений в конструкцию транспортного средства не является.

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

Вас также заинтересует:

Про сверку номера мотора при постановке на учёт в ГИБДД

До 2011 года вопрос о проверке однотипности старого и нового двигателей продуман не был. И даже сверка номеров агрегата при регистрации не предполагалась. В результате замена двигателя на любой, подходящий к данной модели автомобиля, стала приобретать массовый характер, причем, собственники автомобилей мало задумывались, что, вероятно, данные изменения необходимо регистрировать в МРЭО.

Максимум, что в рамках закона мог сделать инспектор ГИБДД – обратить внимание на внешний вид мотора при проведении регистрационных действий. Если он догадывался, что на автомобиле двигатель, не соответствующий модели автомобиля, то в проведении регистрационных действий водителю отказывали.

Сверка номера двигателя лежала вне правового поля, но в качестве доказательства неправомерной замены вполне подходила.

С 2018 года наступила определенность в вопросе порядка такой замены.

При сверке VIN-номеров автомобиля инспектор сверяет и номера на других номерных агрегатах, в том числе, и на двигателе. Если номер не совпадает с номером, указанным в ПТС, то по VIN-номеру устанавливается, какой тип агрегата является родным для данного конкретного автомобиля.

Если номер двигателя не совпадает с номером в ПТС

В этом случае стоит или не стоит беспокоиться, зависит от того, совпадают ли у родного и нового мотора:

  • тип двигателя,
  • модель (название и начало номера),
  • характеристики,
  • не числится ли новый двигатель в розыске по базам ГИБДД.

Если двигатель заменён на аналогичный

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

Автомобиль зарегистрируют, и сотрудники МРЭО внесут необходимые изменения в ПТС и банки данных. Причем, никто не спросит, откуда взялся новый двигатель? Это по закону.

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

Мотор заменили на другую модель

Если, помимо несовпадения номеров, двигатель другого типа, большей или меньшей мощности или модели, то внесение изменений в конструкцию необходимо зарегистрировать.

Процедура не такая сложная и неоднократно описывалась на нашем сайте. Вкратце порядок следующий:

  1. До начала работ:
    1. Пройти предварительную техническую экспертизу. Экспертизу проводят только аккредитованные организации, список которых представлен на сайте http://www.eurasiancommission.org/ru
    2. Получить разрешение в ГИБДД на внесение изменений.
  2. После выполнения работ:
    1. Пройти техосмотр.
    2. Пройти повторную экспертизу.
    3. Получить в ГАИ «Свидетельство о внесении изменений в конструкцию».

Пока внесенные в конструкцию транспортного средства изменения не будут зарегистрированы, в постановке на учет самого автомобиля будет отказано.

Альтернативно водитель может доказать, что новый двигатель поставляется на рынок как запасная часть для его автомобиля.

Для подтверждения, как было сказано выше, необходимо представить сертификат или декларацию, которая подтвердит, что двигатель испытан в составе данного автомобиля в соответствии с требованиями технического регламента О безопасности ТС. Если мотор куплен у официального дилера, то проблем с сертификатом или декларацией не будет. По требованию водителя сертификат или декларацию на приобретаемый двигатель продавец обязан предоставить.

Ещё кое-что полезное для Вас:

Можно ли не ставить на учёт и что будет?

На незарегистрированном автомобиле передвигаться по дорогам запрещено.

За нарушение требований законодательства последует наказание по ч.1 ст.12.1 КоАП – штраф. Если со дня вступления постановления о наложении штрафа в силу и до истечения одного года с момента оплаты штрафа водитель вновь попадает в поле зрения ГИБДД на автомобиле без регистрации, то ему грозит лишение права управления по ч.1.1 ст.12.1 КоАП.

Единственный и довольно рискованный вариант ездить на незарегистрированном автомобиле описан в отдельной статье.

Как исправить ошибку в ПТС или СТС автомобиля?

Добрый день, уважаемый читатель.

В этой статье речь пойдет о довольно нестандартной ситуации, когда при заполнении регистрационных документов сотрудники ГИБДД допустили ошибку или опечатку. То есть документы на автомобиль уже выданы, но заполнены они неправильно.

На самом деле, с такой проблемой большинству водителей сталкиваться не приходится и в 99 процентах случаев документы оформляются абсолютно корректно. Данная статья в первую очередь предназначена для тех водителей, кто попал в «несчастливый процент» и получил на руки документы с неправильной информацией.

Как исправить ошибку, допущенную в ПТС водителем?

В 2021 году при продаже автомобиля продавец должен внести в паспорт транспортного средства (ПТС) данные следующего собственника (покупателя). Этот вопрос более подробно рассмотрен в отдельной статье:

И на практике при внесении информации может быть допущена ошибка. В этом случае исправление не вызывает никаких трудностей.

Можно просто перечеркнуть крест-накрест соответствующую область ПТС, а данные о покупателе внести заново — в очередную незаполненную область.

Альтернативный вариант — внести правильные данные в поле «особые отметки» и заверить их подписями продавца и покупателя.

Что делать, если ошибка допущена сотрудниками ГИБДД?

Перейдем к более сложной ситуации. Пусть ошибка допущена в паспорте транспортного средства (ПТС) или в свидетельстве о регистрации (СТС) сотрудниками ГИБДД. При этом документы полностью оформлены, заверены печатями и выданы на руки автовладельцу.

В данном случае не имеет принципиального значения, когда именно водитель заметил ошибку: сразу же после получения документов или лишь через несколько лет. Ее в любом случае следует исправить.

Что касается ошибок, то они могут быть допущены практически в любом поле документа. Чаще всего опечатки можно найти в следующих полях:

  • ФИО собственника.
  • Адрес собственника.
  • VIN или номер кузова.
  • Номер двигателя.

Так что при получении регистрационных документов в первую очередь проверьте именно эти данные.

Внимание! На практике возможна еще одна ситуация, однако она не является ошибкой. Речь идет о том, что регистрационный номер (номер автомобиля) в документах не соответствует номеру, установленному на машине.

Если Вы заметили подобное несовпадение, то нужно вместе со свидетельством о регистрации обратиться в ближайшую организацию, занимающуюся изготовлением номеров, и приобрести там таблички с номером, указанным в СТС.

В течение какого времени исправляется ошибка?

Вернемся к ошибкам, допущенным по вине сотрудников ГИБДД. Рассмотрим пункт 4 статьи 11 Федерального закона «О государственной регистрации транспортных средств в Российской Федерации»:

4. Техническая ошибка (описка, опечатка, грамматическая либо подобная ошибка) в регистрационных данных транспортного средства, допущенная при государственной регистрации транспортного средства, исправляется регистрационным подразделением в трехдневный срок после ее обнаружения или получения от владельца транспортного средства в письменной или электронной форме заявления о допущенной ошибке.

Данный пункт говорит о том, что ошибка должна быть исправлена в течение 3-х дней с момента получения заявления от автовладельца. То есть, если Вы нашли ошибку в ПТС или свидетельстве о регистрации, то обратитесь в ГИБДД с соответствующим заявлением. И в течение 3-х дней ошибку исправят, а Вам выдадут новые документы.

В каком подразделении ГИБДД могут исправить ошибку?

Рассмотрим пункт 161 Административного регламента Министерства внутренних дел Российской Федерации предоставления государственной услуги по регистрации транспортных средств:

161. Заявление об исправлении технической ошибки предоставляется заявителем в любое регистрационное подразделение. Исправление технической ошибки осуществляется в соответствии с графиком (режимом) работы регистрационного подразделения. В результате рассмотрения заявления должностным лицом принимается решение об исправлении технической ошибки.

Исправить ошибку можно абсолютно в любом регистрационном подразделении. При этом не имеет значения, сотрудники какого подразделения допустили ошибку и в каком регионе зарегистрирован автомобиль.

Нужно ли предоставлять автомобиль на осмотр для исправления ошибки?

Пункт 160 Административного регламента Министерства внутренних дел Российской Федерации предоставления государственной услуги по регистрации транспортных средств:

160. В случаях выявления технических ошибок, связанных с несоответствием цвета транспортных средств, маркировки основных компонентов транспортных средств, либо конструкции транспортных средств сведениям из государственного реестра транспортных средств, исправление технических ошибок производится после идентификации транспортного средства.

Осмотр автомобиля требуется лишь в том случае, если ошибка связана с:

Во всех остальных случаях обратиться в ГИБДД можно без автомобиля.

Сколько стоит исправление ошибки в документах?

Пункт 162 Административного регламента Министерства внутренних дел Российской Федерации предоставления государственной услуги по регистрации транспортных средств:

162. Исправление технической ошибки осуществляется с выдачей нового документа, взамен содержащего ошибку, осуществляется без взимания государственной пошлины. Соответствующие изменения вносятся в автоматизированные информационные системы.

То есть не смотря на то, что при исправлении ошибок сотрудники ГИБДД должны выдать новый документ (свидетельство о регистрации) и (или) внести изменения в существующий документ (паспорт транспортного средства), водитель не должен платить за эти процедуры. Ошибка должна быть исправлена бесплатно.

Подведем итоги данной статьи:

1. Если водитель обнаружил ошибку в регистрационных документах, то ему нужно обратиться в ближайшее регистрационное подразделение ГИБДД для ее исправления.

2. Ошибка должна быть исправлена в течение 3-х дней, а водителю должны быть бесплатно выданы новые документы.

3. Осмотр автомобиля требуется лишь в том случае, если ошибка связана с самим автомобилем (неправильно указан цвет, номер двигателя или кузова, дополнительный элемент конструкции).

Удачи на дорогах!

Проблема с постановкой на учет в ГИБДД


Подскажите, пожалуйста, может кто сталкивался с такой же проблемой, ну или что то знает по этому поводу:
Ставила машину на учет в ГИБДД, точнее оформляли смену собственника с сохранением номеров. Инспектор придрался к тому, что номер двигателя не совпадает с тем, который у них в базе (на одну цифру), хотя с ПТС и СТС номер двигателя совпадает. Назначил доп.проверку, правда ездить пока разрешил. Как такое может быть (двигатель не менялся точно, по крайней мере за последние 5 лет)? Машина ставилась на учет 4! раза без проблем, последние 2 раза это делала моя двоюродная сестра (первый раз при покупке, второй при потере номера), поэтому знаю точно, что проблем не было. А тут вдруг обнаружилось… Да и многие говорят, что по корректировке приказа № 28 от 2011 года двигатель вообще не должны смотреть.. Кто с этим сталкивался или что-то знает разъясните ситуацию, пожалуйста!

Комментарии


ну так они на машине двигатель при вас и не проверяли как я понял? Они сверили то что указано в ПТС и тем что в Базе! Вот у них и не совпало! а то что сейчас есть этот приказ не влияет на то что номерной агрегат у вас остался и этот агрегат может быть с угнанной машины! Суть такова что когда в прошлый раз были рег действия возможно паспартистка не правильно набила в базу номер движка!

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

ну они сейчас смотрят двигатель уже по большей части по привычке и для успокоения души, но в документы уже не вбивают! тем более раз в ПТС и свидёлке у Вас он прописан вот он и сверил, а на новых машинах уже нет нигде номеров…. я вчера тоже машину снимал с учёта, капот меня канечно попросили открыть, но номер не смотрели, а так для того чтоб удостоверится какой мотор там стоит визуально….

Они сверяют модель двигателя, чтобы вы туда от Бугатти не поставили.;)

ну я это и имел ввиду… или наоборот менее прожорливый к примеру дизельный…

Именно. Но возникает вопрос — может ли мент-недоучка на взгляд определить рабочий объем двигателя? Я — сомневаюсь.

Ничего страшного нет. Банальная ошибка в базе. Снять с учета не сможете, ездить вам запретить не могут. Должны изъять документы на экспертизу и выдать времянку — талончик, срок действия которого можно продлять. Длится это обычно 1-2 мес.

он сделал только копию ПТС, остальное отдал мне, и в заявлении указал причину задержки (заявление тоже у меня на руках)

Ну значит в Вашем случае все решится проще и быстрее. Удачи!

Djeff


что тут не понятного, дяди из гаи денег хотят)))) щас помурыжат, денег не дождутся и все встанет на свои места)))

Каким образом встанет? Номер сам изменится в базе?
Самое простое решение — ехать в другое МРЭО с надеждой, что там сотрудник не станет сверять. Но повторяю, я бы не стал рисковать. Сложно бывает доказать что-то полицаю на трассе при том, что у тебя семейство сидит и ждет в машине.

PS Взяток ментам не даю принципиально.


Понимаете, по закону номер двигла не сверяется, но в реальности какой-нить дикий полицай на пустынной дороге может наплевать на этот закон. Конечно, потом вы докажете свою правоту, но это потом….
Я предпочитаю не давать им поводов для развода.

Вобщем если доп. проверка ничего не покажет (а она скорее всего не покажет), то давить, чтобы убрали ошбику в базе?

Djeff


на Ваше замечание, даже отвечать не стану, ибо внимания оно не достойно!

да, мне все так говорят, но денег не дам =) за деньги я бы могла и в коммерческом сделать, без очередей и всяких проблем =)

Djeff


тогда ждите, им самим надоест)))

я на это и надеюсь =) мне не к спеху, главное что ездить можно =)

Free on Board


заявление на имя начальника мрэо с изложением ситуации

Начальник не будет брать на себя ответственность и волевым решением править базу. Для этого должно быть документальное подтверждение — отказ от возбуждения УД и заключение экспертизы.
Если в базу не внести исправления — то это чревато разводом на бабки на одиноко стоящем посту где-нибудь в Краснодарском крае, к примеру.;)
Я бы заморочился и решил вопрос, чтобы быть спокойным при будущей продаже ТС.

ну доп.проверку назначили, через 2 недели просили позвонить (у них как раз начальник с отпуска выходит). По идее они просто должны пометку сделать в ПТС, чтобы дальнейших проблем не было, так ведь?

Ни в коем случае!!! У Вас чистый, законый ПТС без ошибок. Пусть в базе исправляют.

Денис HR


у меня было, продал машину с номерами, отдал ПТС, договор набили по ПТС… через неделю покупатель принес новый договор с другим номером двигателя (на 1 цифру длиннее вроде), ПТС ему ГАИшники переделали

и с тех пор стало кататся 2 машины с одинаковыми агрегатами….

Ошибка работника, заносившего информацию в базу. Обычные ляпы, не только в базе, но и в документах, то печать забыли поставить, то подпись, то инициалы напутают или ещё какую информацию исказят. Не только движки или машина станет чужой, но и сам станешь другим гражданином. В некоторых случаях информацию умышленно искажают. Поэтому всегда необходимо проверять все получаемые документы и в случае несоответствия их действительности сразу же заняться их исправлением.
Если сразу отказываются исправить ошибку, то к заявлению на имя начальника приложите копию ПТС и зарегистрируйте второй экземпляр заявления у секретаря. Срок рассмотрения один месяц. Такой метод обычно действует. В случае отказа устранить допущенные нарушения — в суд.

При оформлении документов на авто допущена ошибка. Можно ли исправить?

Итак, вы купили автомобиль. Оформили все документы и только тут выяснилось, что в паспорте транспортного средства (ПТС) или свидетельстве о регистрации транспортного средства (СТС) допущена ошибка. Что же делать? Как исправить?

Честно говоря, такие ситуации являются редкостью. И по этой причине становятся настоящей проблемой, поскольку очень немногие знают, как действовать в подобных случаях.

По чьей вине может быть допущена ошибка? Вариантов два: по вине продавца либо из-за невнимательности сотрудника ГИБДД. Первый не вызывает особых сложностей и предельно прост для понимания. Второй требует более детального пояснения. Мы рассмотрим оба случая. Начнем с самого простого.

Ошибка допущена продавцом

Продажа автомобиля предусматривает добавление в ПТС информации о новом собственнике. Вносится она продавцом, поэтому в практических условиях процедура вполне может сопровождаться погрешностями.

Исправить их довольно просто. Ошибочный сектор ПТС просто перечеркивается, а следующее за ней пустое поле заполняется точными данными о покупателе. Альтернативным вариантом корректировки является размещение правильной информации в «Особых отметках» — дополнительном поле ПТС, где под обновленными сведениями продавец и покупатель ставят свои подписи.

 

Естественно, мы здесь не упоминаем СТС, поскольку при покупке авто, не зависимости от «свежести» машины (то есть неважно, новая она или подержанная), покупателю выдается новый документ — в ГИБДД или, с недавних пор, в МФЦ. Поэтому ошибки продавца тут быть не может.

А теперь рассмотрим более сложный случай.

Ошибка допущена сотрудником ГИБДД

Это может произойти как при заполнении ПТС, так и при оформлении СТС. Представьте: документы у вас на руках, полностью оформленные, заверенные печатями — но с ошибкой! В такой ситуации нет разницы, когда вы заметили неточность — сразу при выдаче или по прошествии нескольких лет, — она обязательно должна быть исправлена.

От ошибок может пострадать практически любое поле в ПТС и СТС. Но преимущественно это случается при заполнении:

  • ФИО владельца;
  • его адреса;
  • VIN-номера или номера кузова;
  • номера двигателя.

Таким образом, внимательно проверяйте указанные выше поля, когда получаете документы.

При обнаружении ошибки вы обращаетесь в ГИБДД с просьбой ее исправить. В соответствии с Федеральным законом № 283-ФЗ от 3 августа 2018 года (а конкретно — пунктом 4  статьи 11) неточность должна быть устранена в течение трех дней, после чего вы получите на руки новый документ.

Совершенно неважно, где именно зарегистрирован автомобиль и в каком подразделении ГИБДД допущена ошибка — руководствуясь Административным регламентом МВД (пункт 161), заявление на исправление вы можете подать в любое отделение Госавтоинспекции.

В такой ситуации возникает закономерный вопрос: нужно ли показать авто в ГИБДД, чтобы исправить ошибку? Ответ: нужно, но лишь в строго оговоренных случаях.

В соответствии с пунктом 160 Административного регламента, это необходимо:

  • при несоответствии цвета кузова;
  • номера кузова или двигателя;
  • конструкции транспортного средства.

Любые другие случаи не требуют доставки авто в ГИБДД для осмотра.

И последний, главный вопрос: во сколько обойдется исправление ошибки? Несмотря на то, что мы рассматриваем ситуацию, когда ошибка допущена по вине сотрудника Госавтоинспекции, документ все же выдается новый, а это дополнительная работа специалистов ГИБДД или МФЦ.

В очередной раз обратимся к нормам действующего законодательства. На помощь снова приходит Административный регламент МВД. Согласно пункту 162 этого нормативного акта исправление ошибок подразумевает выдачу нового документа, который не облагается госпошлиной.

В переводе на обычный язык это значит, что вся процедура по фактической замене ПТС или СТС, а также внесение изменений в сами документы и базы данных ГИБДД не будет стоить вам ни копейки. В подобных случаях все расходы — за счет государства.

почему могут отказать в постановке на учет и что делать

Я купила в салоне подержанную машину в кредит. Машина теперь в залоге у банка.

Приехала ставить машину на учет, но при осмотре сотрудник ГИБДД не нашел номер на двигателе. В постановке на учет мне отказали.

Что мне делать, куда обращаться? Почему так может быть? Могу ли я вернуть машину обратно в салон или отдать ее банку в счет погашения кредита?

Ксения

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

Дмитрий Сергеев

разобрался с номером двигателя

Профиль автора

В вашем случае я рекомендую внимательно посмотреть на основания отказа. Возможно, вам отказали со ссылкой на приказ МВД России № 1001. В нем сказано, что если на двигателе есть признаки скрытия его номера, то идентифицировать транспортное средство нельзя, а значит, и на учет поставить тоже нельзя. Но этот приказ с 1 января 2020 года не действует. Если вы пожалуетесь, что сотрудники ГИБДД ссылаются на недействующие нормативные акты, велика вероятность, что автомобиль вам на учет поставят. И тогда сдавать его не придется.

Избранные статьи для автомобилистов

Как ездить без штрафов и не переплачивать за обслуживание машины — в нашей рассылке вместе с другими материалами о деньгах

Почему в ГИБДД отказались регистрировать автомобиль

Раньше двигатель считался одной из основных деталей автомобиля. На него наносили номер, который нельзя было изменять или удалять. В 2013 году сотрудникам ГИБДД разрешили не проверять номер двигателя при постановке автомобиля на учет или при других регистрационных действиях. А заодно номер двигателя исчез из регистрационных документов на автомобиль — СТС и ПТС.

Приказ МВД России от 07.08.2013 № 605 — утратил силу

С 2017 года проверка номера двигателя вернулась в обязательный арсенал функций ГИБДД. В документах его по-прежнему не указывали, но если номер двигателя не обнаруживался при осмотре или выявлялись следы его изменения, то машину на учет не ставили.

абз. 5 п. 3 правил регистрации автомототранспортных средств — утратил силу

Но время идет, и сейчас на номер двигателя снова разрешено не смотреть.

Примерно так выглядит номер двигателя. Его наносит завод-изготовитель на блок цилиндров. Место производитель выбирает сам, и иногда при осмотре автомобиля даже опытные сотрудники ГИБДД затрудняются его найти. Раньше считали, что эти номера помогают бороться с кражами двигателей

Что изменилось в законах

Основные компоненты транспортного средства по этому закону — это кузов, рамы, кабина. Двигатель автомобиля к основным компонентам не относится, в документе о нем нет ни слова.

п. 3 ст. 4 закона о госрегистрации ТС

Правда, в некоторых случаях из-за замены двигателя в регистрации могут отказать. Например:

  1. Если внесены изменения в конструкцию транспортного средства. Например, на Жигули установили двигатель от Волги или перевели машину на газ. В этом случае сначала придется узаконить установку, и только потом автомобиль зарегистрируют.
  2. Если номер двигателя указан в документах, а на самом двигателе его не окажется. В этом случае в ГИБДД должны провести проверку. У продавца и покупателя возьмут объяснительные и проверят, нет ли такого двигателя среди украденных. Если выяснится, что вы никаких законов не нарушали и двигатель никто не похищал, машину зарегистрируют. Но по всей видимости, это не ваш случай: если бы двигатель посчитали похищенным, вам бы не просто отказали в регистрации, а вызвали бы на допрос.

п. 52 правил госрегистрации ТС

п. 4 ст. 20 закона о госрегистрации ТС

Почему в ГИБДД отказали в регистрации и что делать дальше

Советую обратиться с жалобой к руководству того подразделения ГИБДД, которое отказалось ставить машину на учет. Жалобу можно составить по такому шаблону:

  1. ФИО.
  2. Суть жалобы: вам отказали в постановке машины на учет. Укажите реквизиты отказа, а еще лучше приложите его копию.
  3. Основание, почему жалуетесь. Напишите, что закон от 03.08.2018 № 283-ФЗ «О государственной регистрации транспортных средств в Российской Федерации» и правила государственной регистрации транспортных средств с изменениями, внесенными 21 декабря 2019 года, не предусматривают отказ в регистрации из-за отсутствующего номера двигателя.
  4. Ваше требование: вы просите отменить решение инспектора об отказе в регистрации и зарегистрировать принадлежащий вам автомобиль.

Если вы обратитесь с жалобой сейчас, велика вероятность, что автомобиль зарегистрируют. Единственное условие — отсутствие других оснований для отказа.

Если вам отказали в постановке авто на учет по другим основаниям

Легковые автомобили отнесены к технически сложным товарам. Это означает, что вернуть автомобиль после покупки просто так не получится. Для этого нужны веские основания. Например, вы обнаружите в автомобиле существенные недостатки или не сможете использовать его в течение каждого года гарантийного срока в совокупности более чем тридцать дней.

ст. 18 закона о защите прав потребителей

Автомобиль, который не получается зарегистрировать в ГИБДД, вы не можете и использовать. Это существенный недостаток. Поэтому обратитесь в автосалон с досудебной претензией. Укажите, что вы просите забрать автомобиль обратно, а вам вернуть деньги и выплаченные проценты по кредиту. Приложите к претензии копию договора займа. А заодно отправьте копию претензии в банк.

То, что автомобиль приобретен в кредит, сути дела не меняет. Но предупредить банк, что вы хотите вернуть автомобиль, придется. Вы приобретали его в кредит, и он находится в залоге у банка. А без согласия залогодержателя вернуть автомобиль нельзя.

По кредитному договору вы уплачивали не только сумму долга, но и проценты. Скорее всего, еще делали страховку: ОСАГО и, возможно, каско. В случае удачного разрешения ситуации вы можете рассчитывать, что автосалон вернет вам не только сумму основного долга, но и выплаченные банку проценты.

ст. 24 закона о защите прав потребителей

Возможны два варианта развития событий.

Оптимальный — это мирный. В этом случае автосалон согласится с вашими доводами и вернет вам деньги.

Второй вариант — автосалон откажется вернуть деньги. В этом случае я рекомендую обратиться в Роспотребнадзор за помощью в подготовке иска.

Как все закончится, сказать сложно. Суды разбирают каждую ситуацию индивидуально и учитывают все особенности. Но в целом, если потребитель представляет убедительные доказательства нарушения своих прав, суды, как правило, на его стороне.

Что в итоге

Возможно, сотрудники ГИБДД руководствуются устаревшими нормативными актами. Напишите жалобу и ждите решения.

Если найдутся другие основания для отказа в регистрации, попробуйте вернуть автомобиль в автосалон как технически сложный товар с существенными недостатками.

Если у вас есть вопрос о личных финансах, дорогих покупках или семейном бюджете, пишите. На самые интересные вопросы ответим в журнале.

Экспертиза. Что делать если не читается номер двигателя, номер кузова, VIN. Что делать, если номер двигателя не совпадает с птс Плохо читается номер двигателя что делать

под капотом.

На мотоцикле

VIN-код на японских мотоциклах отсутствует. На американских и европейских он размещается на раме. Часто код можно найти на рулевой стойке в правой части, как требует ГОСТ, или на вилке внизу возле крыла.

Действия, если VIN номер заржавел

Часто ржавчину получается удалить самостоятельно. Цифры выбиваются достаточно глубоко, поэтому полностью сгнить они могут только при длительном воздействии агрессивной среды.

Почистить табличку с VIN-кодом от ржавчины помогут следующие меры:

  1. Протереть место с номером кузова тряпкой, смоченной в растворителе. Можно повторить процедуру несколько раз.
  2. Если растворитель не помог, можно попробовать преобразователь ржавчины с ортофосфорной кислотой. Нужно нанести его на область, которую требуется очистить, и оставить на 15-20 мин. Затем тщательно вытереть мокрой тряпкой и просушить. Иногда после этого на обработанной поверхности начинают проступать цифры ВИН-кода.
  3. Если эффекта ортофосфорной кислоты тоже недостаточно, остается вариант с наждачной бумагой. Только нужно быть очень осторожным. С помощью наждачки можно удалить не только ржавчину, но и цифры. Поэтому не стоит сильно тереть.

Воздействовать на ржавчину более агрессивными веществами не рекомендуется. Останутся четкие царапины и другие следы, которые сотрудники ГИБДД могут принять за попытки изменить VIN-код. Это чревато даже заведением уголовного дела.

Если раньше при нечитаемом номере совершать какие-либо действия с авто было нельзя, то с 10 июля 2017 г. правила изменились.

Вступил в силу , который разрешил постановку на учет даже при сгнившем VIN-коде, если машину можно идентифицировать.

Чтобы узаконить авто в таком случае, потребуется криминалистическая экспертиза номера. Ее результаты станут основанием для отказа в возбуждении уголовного дела, а в регистрационных данных будет сделана пометка об утрате ВИН-номера.

Направление на экспертизу выдает инспектор ГИБДД, обнаруживший повреждения кода при проверке машины для постановки на учет.

Документы на авто у владельца изымаются. Ему придется посетить место проведения экспертизы и взять талон, где указывается время и дата процедуры.

В назначенный срок владелец оставляет машину специалистам, после чего ему нужно дождаться результатов.

В ходе экспертизы с машины снимают части, перекрывающие доступ к ВИН-номеру, иногда доходит даже до снятия двигателя. Демонтажные работы оплачивает владелец. Затем нечитаемый код вытравливают агрессивными химсредствами.

Примеси других металлов, которые всегда появляются при переваривании номера, окрашиваются в другой цвет и становятся видны.

На основании результатов криминалистической экспертизы заводится уголовное дело, затем выясняется, кто и в каких целях демонтировал VIN.

Параллельно проводится проверка ТС на предмет того, не числится ли оно в . В таком случае зарегистрировать машину будет практически невозможно, ГИБДД не вернет документы.

Автомобиль останется лишь разобрать или продать целиком на запчасти. Цена будет минимальная, но пользоваться и совершать какие-либо сделки с машиной все равно нельзя.

Ожидание официального отчета экспертов может занять до 15 дней. Затем бумаги можно подавать в МРЭО во второй раз и снова пытаться поставить машину на учет.

В ПТС будет внесена отметка о том, что ВИН-номер разрушился естественным образом и не подвергался переделкам.

Стоит ли покупать такую машину

Поскольку постановка на учет при нечитаемом VIN-коде сейчас разрешена, приобретать такую машину можно. Только вначале нужно провести криминалистическую экспертизу, которая должна подтвердить, что заводской номер не был изменен.

После этого можно быть уверенным, что автомобиль не был задействован в преступных схемах, его можно использовать, дарить, продавать и покупать.

Если же специалисты установят, что под слоем ржавчины перебитый код, машину останется только сдать на металлолом. Ездить на таком авто противозаконно. При покупке машины с рук есть риск попасть в подобную ситуацию, поэтому и рекомендуется проверять ВИН-номер перед приобретением.

Если новый владелец только после покупки выяснит, что код нечитаемый, ему придется самому заказывать экспертизу для дальнейшей постановки авто на учет.

Однако он может обвинить продавца в мошенничестве, умышленном сокрытии дефектов, изменении номера авто.

Если экспертиза установила, что VIN был перебит, нельзя будет поставить ТС на учет и вообще пользоваться им. В такой ситуации нужно требовать у продавца возвращения денег, уплаченных за автомобиль.

Вначале стоит озвучить устную просьбу, попытаться решить спор мирным путем. На практике договориться удается далеко не всегда. Если не получилось вернуть деньги, можно требовать их через суд.

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

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

Важный момент: вернуть получится только сумму, указанную в договоре купли-продажи. Если сверх нее были уплачены какие-то средства, взыскать их не удастся.

Также крайне малы шансы на возврат денег в случае покупки по гендоверенности, если нет дополнительных документов, которые могут подтвердить оплату.

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

В каких еще случаях нарушается читаемость кода

Начнем с того, что о различных трудностях при регистрации ТС с нечитаемым или несовпадающим слышали или сталкивались многие водители из разных стран, однако сегодня еще не все в полной мере компетентны в данном вопросе.

Более того, достаточно неоднозначная ситуация сложилась в РФ, то есть указанная проблема напрямую коснулась именно российских автолюбителей. Дело в том, что несколько лет назад на законодательном уровне было закреплено отсутствие необходимости сверять номер двигателя в рамках постановки транспортного средства на учет или при прохождении ТО.

Другими словами, в ГИБДД не могли отказать в регистрации (постановке на учет) по причине отсутствия или несоответствия номера двигателя в ПТС. Автолюбители с радостью приняли эту инициативу, так как, фактически, двигатель можно было считать обычной запчастью и при необходимости свободно менять сильно изношенный или сломанный агрегат на аналогичный .

Однако на практике все оказалось несколько иначе. Частой ситуацией стала такая, когда владельцы сталкиваются с отказом при попытках зарегистрировать авто в ГИБДД, а причиной выступает именно несоответствие номера двигателя. В этой статье мы поговорим о том, какими проблемами и сложностями может обернуться покупка машины, у которой нет номера двигателя в ПТС, номер мотора не совпадает, номер двигателя спилен, проржавел или сильно поврежден.

Читайте в этой статье

Прежде всего, важно понимать, что установка так называемого «нештатного» двигателя является самостоятельной переделкой транспортного средства. Естественно, после такой замены мотора для в регистрации ТС может быть отказано на вполне законных основаниях.

Если просто, с новым мотором, который обычно сознательно подбирается мощнее стандартного, также изменяется целый ряд важнейших технических характеристик автомобиля. При этом такой транспорт и его системы должны быть специально доработаны, в противном случае зарегистрировать и выезжать на этом ТС на дороги общего пользования не получится.

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

В 2011 году был издан приказ МВД РФ №28. Если не вдаваться в подробности, в указанном приказе содержались изменения, которые предусматривали отказ от необходимости сверять при постановке авто на учет номера двигателя. Затем в 2013 году вышел приказ МВД РФ №605, который утвердил новый Административный регламент Министерства внутренних дел РФ по предоставлению услуги госрегистрации транспортных средств.

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

В результате с 2011 по 2013 год все автомобили, на которых был заменен ДВС, не получается поставить на учет, то есть официально зарегистрировать. Итак, если приобретается б/у автомобиль, на котором производилась замена двигателя, однако соответствующих отметок в ПТС нет, возникают сложности. Еще усугубляет ситуацию тот факт, что в разных областях требования отличаются.

На практике это выглядит следующим образом. В одной области РФ Управление ГИБДД не видит никакой проблемы при регистрации ТС с замененным двигателем (при условии того, что замена произведена на такой же мотор). Соответственно, в ПТС отметки не ставятся, никаких дополнительных документов не требуется, на процедуру госрегистрации ТС несовпадающий номер двигателя не влияет.

Однако если обратиться в ГИБДД в другой области для перерегистрации ТС, можно получить отказ по причине замены двигателя. Сотрудники ссылаются на п.24 админрегламента (приложение №1 к приказу №605). Примечательно еще и то, что во многих случаях в действительном свидетельстве о регистрации ТС номер двигателя не указан, также в заявлении на регистрацию раздел сведений о ТС также не имеет графы для указания номера двигателя (указывается только мощность мотора).

Не менее сложной ситуацией является такая, когда двигатель заменен, но номер двигателя в ПТС другой. Казалось бы, достаточно написать заявление в ГИБДД, чтобы в ПТС были внесены соответствующие изменения в виде нового номера ДВС. На практике это реально, но для таких действий нужно в обязательном порядке предоставить документы на новый двигатель.

Другими словами, законность приобретения мотора-донора должна быть подтверждена документально. Если таких документов нет, тогда изменить номер силового агрегата в ПТС не получится, а на основании несоответствия номера в дальнейшей регистрации ТС будет отказано.

Еще добавим, что утверждения многих владельцев о том, что при регистрации эксперт не смотрел номер двигателя и машину поставили на учет, еще не значит, что так происходит в 100% случаев. Да, на современных автомобилях добраться до номера не всегда просто, иногда приходится снимать часть навесного оборудования и т.п.

Если учесть, что владелец ТС делать это самостоятельно не обязан, а эксперт попросту не хочет заниматься такими работами, тогда понятно, как регистрируют машины без сверки номера двигателя.

Однако нельзя рассчитывать исключительно на везение. На многих авто не нужно ничего разбирать, то есть сверить номер ДВС не составляет особого труда. Простыми словами, если в одном регионе номер силовой установки не проверяют, в другом вполне могут возникнуть трудности, на одном авто до номера легко добраться, на другом доступ к номерной панели затруднен.

Хотелось бы отметить, что если принято решение купить контрактный двигатель и сделать свап, сначала необходимо написать соответствующее заявление и уточнить информацию касательно того, какие документы будут нужны для дальнейшей регистрации нового двигателя.

Затем можно приобрести и поставить на машину контрактный агрегат с учетом сохранения всех необходимых документов. После этого следует повторно обратиться в ГИБДД, чтобы зарегистрировать новый мотор. Конечно, если этого не сделать, тогда у владельца при дальнейшей эксплуатации может и не возникать никаких проблем. Однако при попытках пересечь границу или перерегистрировать такой автомобиль ситуация часто меняется.

Еще раз отметим, свап мотора для тюнинга и увеличения мощности делается на авто, которые участвуют в спортивных соревнованиях. Как правило, по дорогам общего пользования такие ТС не передвигаются. Если же подобные изменения в конструкции авто зарегистрировать официально, тогда с учетом рекомендуемых комплексных доработок общая стоимость такого тюнинга может быть очень высокой.

Что в итоге

Изучив реальные ситуации, которые возникают у российских автовладельцев на практике, можно сделать несколько важных выводов. Главное, нужно четко понимать, что хотя номер мотора может быть нигде не указан, в базе ГИБДД он все же есть. С учетом вышесказанного становится понятно, что еще перед покупкой подержанного авто нужно знать, если нет номера двигателя, что делать в этом случае. Вполне очевидно, что от приобретения такого ТС лучше сразу отказаться.

То же самое можно сказать и о тех случаях, когда в ПТС номер мотора один, а на машине стоит агрегат с другим номером. Даже если продавец будет ссылаться на то, что регистрационные действия с этим автомобилем ранее уже осуществлялись несколько раз и проблем не было, это не значит, что они не возникнут при попытке поставить авто на учет в другой области.

Напоследок отметим, что одним из способов для выхода из сложившейся ситуации для тех, кто уже купил проблемный автомобиль, становится официальное приобретение еще одного контрактного мотора. Затем производится так называемый «официальный» свап, когда в ГИБДД подаются все необходимы документы на новый двигатель, вносятся соответствующие изменения в ПТС и т.д.

Читайте также

Как найти номер двигателя на самом силовом агрегате или в других местах под капотом автомобиля. Место расположения номера мотора на популярных моделях авто.

Окислительные процессы оказывают негативное влияние на разные участки кузова, ДВС и другие элементы транспортного средства. В такой ситуации могут затрагиваться поверхности с нанесённой идентификационной информацией, где располагается VIN-код или номер двигателя.

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

Дуализм автомобильного законодательства

Практика невнесения номера двигателя в ПТС не всегда влечёт за собой позитив. Теоретически автовладелец имеет право заменить устаревший ДВС на новый. Причины для этого могут быть разные:

  • автомобиль и получил физические повреждения мотора;
  • движок износился и выработал свой ресурс;
  • собственник машины желает получить более мощный автомобиль.


Основным нормативным документом, на который ссылаются инспекторы ГИБДД при регистрации или перерегистрации машин, является Приказ Министерства внутренних дел №1001 от 29.06.2017 г. В нём расширен перечень оснований для отказов на выполнение регистрационных действий. Сложности проявятся в следующих случаях:

  • сотрудниками ГИБДД выявлены явные признаки изменений, переделки или сокрытия номеров;
  • присутствует доказательство уничтожение идентификационных номеров ТС, включая физические идентификаторы агрегатов или узлов, к которым относятся рама, кабина, кузов, ДВС;
  • имеются признаки подделки документов;
  • выявлены несоответствия установленных агрегатов с регистрационными данными;
  • установлены агрегаты с угнанных, похищенных, утраченных или находящихся .


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

  • на номерных агрегатах маркировка повреждена вследствие естественного износа, ;
  • авто подвергалось ремонту;
  • транспортное средство возвращено владельцу после угона (хищения), но после проведения обязательной процедуры идентификации.

ВАЖНО! Обоснованным основанием для отказа в регистрационных мероприятиях служит невозможность идентификации машины после замены номерных элементов рамы или кузова, когда были утрачены идентификационные номера, нанесённые производителем во время выпуска авто.

В трактовке нормативных документов ГИБДД касательно безоговорочного отказа регистрации машины отсутствует пункт, в котором блокируется процесс из-за проблем с номером ДВС. Имеется возможность отправки на дополнительную экспертизу.

Стоит ли покупать машину с проблемным номером ДВС

Практика автомобилистов свидетельствует о том, что в разных регионах страны инспекторы ГИБДД могут неодинаково относиться к машинам с изменёнными номерами ДВС. В отдельных случаях инспектор не видит явной угрозы в том, что маркировка несчитываемая либо проводилась замена двигателя. Даже отметки в дополнительной графе ПТС могут отсутствовать, а процедура перерегистрации в пределах региона пройдёт в штатном режиме.


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

Сложности могут возникнуть во время регистрационных мероприятий в других областях. Может проводиться более тщательная проверка по электронным базам данных, в которых указывается, кроме прочих параметров, например, мощности, номер двигателя. И для движка с нечитаемым номером могут возникнуть проблемы при регистрации.

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

Во время покупки машины с усложнённым прочтением номера двигателя необходимо знать, что делать. Рекомендуем попросить у продавца подтверждающие документы, по которым есть возможность идентифицировать узел. Также стоит проконсультироваться с экспертом-криминалистом, а при необходимости провести экспертизу и получить соответствующий талон от специалиста о подтверждении «чистоты» автомобиля. Оставьте комментарий о вашем опыте с проблемными номерами на ДВС.

Назначение экспертизы.

Назначают экспертизу инспектор, когда, по каким-то причинам, не может прочитать номер. Это может быть из-за механических повреждений некоторых цифр номера или из-за ржавчины. С годами любой номер подвержен воздействию коррозии, а на некоторых автомобилях площадки с номером находятся в таких местах и подвержены настолько сильным воздействиям окружающей среды (соль, вода и т.д.), что сохранить номер в целости становится очень не простой задачей. Инспектор, видя всю эту ржавую картину выписывает Вам направление на экспертизу. При этом документы на автомобиль изымаются по подозрению в том, что номер был перебит. Если у инспектора хорошее настроение он может еще и выписать Вам доверенность на получение результатов экспертизы. Это сэкономит Вам несколько дней.

Прохождение экспертизы.

Далее Вам нужно явится на указанный в направлении пункт, где Вам дадут талон. В талоне будет назначена дата прохождения экспертизы. Далее ждете заветного числа и в нужный день являетесь. Сама экспертиза выглядит таким образом: из моторного отсека будет снято и удалено всю, что по мнению экспертов мешает нормальному рассмотрению номера. Надо заметить, что сама экспертиза вроде как бесплатная, но работа сервесмена по снятию-установке мешающего оборудования – платна. После этого эксперт будет мазать различными составами остатки Вашего несчастного номера, ждать какое-то время, затем тереть, снова мазать и снова ждать… Это может продолжатся несколько часов. После этого эксперт сфотографирует то, что у него в результате получилось несколько раз под разным ракурсом. Затем облезает всю машину за поиском еще каких либо номеров, спишет номера нужных ему запчастей, кпп, рамы и т.д. Будет искать места возможной сварки или места шпаклевки. Далее возможно два варианта: либо номер все таки прочитается под воздействиями всех этих химических растворов, либо нет. Если да — можно с результатами экспертизы смело ехать в мрэо и продолжать постановку. Если номер не прочитался – ждем результатов экспертизы. Результаты будут готовы в течении 15 рабочих дней.

P.S. Если номер все таки прочитался, то нужно обратить внимание на следующее: после того как эксперт намазал всеми возможными химическими реагентами Ваш несчастный номер он сгниет ОЧЕНЬ быстро. Красить его ничем нельзя, так как на любом посту гаишник завернет вас с подозрением не перебитые номера. Лучшим выходом будет намазать его какой-нибудь смазкой, графитом или литолом. А при следующей постановки\снятии насухо вытереть тряпкой с растворителем.

После экспертизы.

Готовы ли результаты экспертизы можно узнать по телефону. Телефон будет указан у Вас на талоне. Ну можно на всякий случай уточнить его когда будете проходить экспертизу. Когда результаты готовы Вы можете либо (если у Вас есть доверенность на получение результатов) поехать и получить их самостоятельно, либо ждать пересылки их в ГАИ по почте. По почто результаты будут идти около двух недель. Результаты должны попасть в ГАИ к инспектору по розыску. Если они у Вас на руках – вручите лично. Если нет – периодически заезжайте в Гаи, чтоб узнать пришли они, или нет. Можно, конечно, звонить и спрашивать по телефону, но по телефону инспектора не особо горят желанием «помогать всем гражданам». Как только результаты у инспектора он назначит Вам день встречи для рассмотрения Вашего дела.

Встреча с инспектором по розыску.

В назначенный день инспектор знакомится с результатами и составляет материалы для возбуждения уголовного дела. Вам же нужно будет написать объяснительную по образцу, где вы укажите, что номер на двигателе вы не перебивали, двигатель не ремонтировали и т.д. Инспектор же сделает ксерокопии вашего ПТС и свидетельства о регистрации и, заверив их печатями, отдаст вам. По ним можно ездить 30 дней. А дело направит для расследования в прокуратуру. Расследоваться ваше дело должно не более 30 дней.

Прокуратура.

Если экспертиза установила, что номер не был перебит, а просто сгнил естественным путем, а в угон не была подана аналогичная машина с VIN номером, совпадающим с читаемыми буквами Вашего номера, то дается постановление об отказе в возбуждении уголовного дела. В этом случае результаты расследования отдадут наконец Вам и вы можете ехать в МРЭО заканчивать свою постановку или снятие. При этом в ПТС будет вклеена фотография вашего сгнившего номера и сделана пометка, что номер сгнил естественным путем. Если же экспертиза установила, что номер перебит то дело обстоит намного хуже. В лучшем случае Вам придется поменять двигатель (если перебит номер двигателя), а в худшем придется распродать машину на запчасти, так как документы Гаи не вернет, поставить или снять с учета эту машину нельзя (можно только выбраковать) и ездить на ней при этом тоже нельзя. Дела обстоят печально.

Что нужно знать?

Политика конфиденциальности сайта www.avtosprobegom21.ru

Мы признаем важность конфиденциальности информации. В этом документе описывается, какую личную информацию мы получаем и собираем, когда Вы пользуетесь сайтом www.avtosprobegom21.ru. Мы надеемся, что эти сведения помогут Вам принимать осознанные решения в отношении предоставляемой нам личной информации.

Политика конфиденциальности объясняет:

  • какие данные мы собираем и зачем;
  • как мы используем собранные данные;
  • какие существуют варианты доступа к данным и их обновления.

Общедоступная информация

Если Вы просто просматриваете сайт, информация о Вас не собирается и не публикуется на сайте.

Какую информацию мы собираем?

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

Как мы используем собранные данные

Ваше добровольное согласие оставить имя, телефон и адрес электронной почты подтверждается путем ввода вашего имени, телефона и/или адреса электронной почты в соответствующую форму. Информация, собранная после отправки формы на сайте (а именно: имя, телефон и e-mail адрес) нигде не публикуется и не доступна другим посетителям сайта. Имя используется для личного обращения к Вам, а телефон и адрес электронной почты — для уточнения вопросов. При необходимости использовать ваши данные для целей, не упомянутых в настоящей политике конфиденциальности, мы всегда запрашиваем предварительное согласие на это.

Условия обработки и её передачи третьим лицам

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

Протоколирование

При каждом посещении сайта наши серверы автоматически записывают информацию, которую Ваш браузер передает при посещении веб-страниц. Как правило эта информация включает запрашиваемую веб-страницу, IP-адрес компьютера, тип браузера, языковые настройки браузера, дату и время запроса, а также один или несколько файлов cookie, которые позволяют точно идентифицировать Ваш браузер.

Куки (Cookie)

На сайте используются куки (Cookies), происходит сбор данных о посетителях с помощью сервисов Яндекс Метрика. Эти данные служат для сбора информации о действиях посетителей на сайте, для улучшения качества его содержания и возможностей. В любое время Вы можете изменить параметры в настройках Вашего браузера таким образом, чтобы браузер перестал сохранять все файлы cookie, а так же оповещал их об отправке. При этом следует учесть, что в этом случае некоторые сервисы и функции могут перестать работать.

Изменение Политики конфиденциальности

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

Устранение неполадок при подключении к ядру СУБД SQL Server — SQL Server

  • 14 минут на чтение

В этой статье

Применимо к: SQL Server (все поддерживаемые версии)

В этой статье перечислены методы устранения неполадок, которые следует использовать, когда не удается подключиться к экземпляру ядра СУБД SQL Server на одном сервере.

Примечание

Для других сценариев см .:

Эти шаги не относятся к наиболее вероятным проблемам, которые вы, вероятно, уже пробовали. Эти шаги идут в порядке от самых основных проблем к более сложным. Эти шаги предполагают, что вы подключаетесь к экземпляру SQL Server с другого компьютера, используя протокол TCP / IP, что является наиболее распространенной ситуацией.

Эти инструкции полезны при устранении ошибки « Connect to Server », которая может быть Номер ошибки: 11001 (или 53), уровень серьезности: 20, состояние: 0 .Ниже приведен пример сообщения об ошибке:

Ошибка, связанная с сетью или конкретным экземпляром, при установке соединения с SQL Server. Сервер не найден или не был доступен. Убедитесь, что имя экземпляра правильное и что SQL Server настроен на разрешение удаленных подключений.

(поставщик: поставщик именованных каналов, ошибка: 40 - не удалось открыть соединение с SQL Server) (Microsoft SQL Server, ошибка: 53)

(поставщик: поставщик TCP, ошибка: 0 - такой хост не известен.) (Microsoft SQL Server, ошибка: 11001)

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

  • Имя компьютера, на котором размещен SQL Server
  • .
  • Экземпляр не разрешает правильный IP-адрес
  • Номер порта TCP указан неправильно

Не включено

Получить имя экземпляра из диспетчера конфигураций

На сервере, на котором размещен экземпляр SQL Server, проверьте имя экземпляра.Используйте диспетчер конфигурации SQL Server.

Configuration Manager автоматически устанавливается на компьютер при установке SQL Server. Инструкции по запуску Configuration Manager незначительно различаются в зависимости от версии SQL Server и Windows. Подробные сведения о версии см. В разделе Диспетчер конфигурации SQL Server.)

  1. Войдите на компьютер, на котором размещен экземпляр SQL Server.

  2. Запустите диспетчер конфигурации SQL Server.

  3. На левой панели выберите Службы SQL Server .

  4. На правой панели проверьте имя экземпляра ядра базы данных.

    • SQL SERVER (MSSQLSERVER) обозначает экземпляр SQL Server по умолчанию. Имя экземпляра по умолчанию — <имя компьютера> .
    • SQL SERVER (<имя экземпляра>) обозначает именованный экземпляр SQL Server. Имя экземпляра имени: <имя компьютера> \ <имя экземпляра>

Проверить — экземпляр работает

Чтобы убедиться, что экземпляр запущен, в Configuration Manager посмотрите на символ у экземпляра SQL Server.

  • Зеленая стрелка указывает на то, что экземпляр запущен.
  • Красный квадрат указывает, что экземпляр остановлен.

Если экземпляр остановлен, щелкните его правой кнопкой мыши и выберите Запустить . Экземпляр сервера запускается, и индикатор становится зеленой стрелкой.

Проверка — служба обозревателя SQL Server работает

Для подключения к именованному экземпляру должна быть запущена служба обозревателя SQL Server. В Configuration Manager найдите службу обозревателя SQL Server и убедитесь, что она работает.Если не работает, запустите. Служба обозревателя SQL Server не требуется для экземпляров по умолчанию.

Экземпляр SQL Server по умолчанию не требует службы обозревателя SQL Server.

Тестирование локального соединения

Прежде чем устранять неполадки с подключением с другого компьютера, сначала проверьте свою способность подключаться из клиентского приложения, установленного локально на компьютере, на котором выполняется SQL Server. Локальное подключение позволяет избежать проблем с сетями и брандмауэрами.

В этой процедуре используется SQL Server Management Studio.Если у вас не установлена ​​среда Management Studio, см. Раздел Загрузка SQL Server Management Studio (SSMS). Если вы не можете установить Management Studio, вы можете проверить соединение с помощью утилиты sqlcmd.exe . sqlcmd.exe устанавливается вместе с компонентом Database Engine. Дополнительные сведения о sqlcmd.exe см. В служебной программе sqlcmd.)

  1. Войдите на компьютер, на котором установлен SQL Server, используя имя входа, имеющее разрешение на доступ к SQL Server. (Во время установки SQL Server требует, чтобы по крайней мере один логин был указан как администратор SQL Server.Если вы не знаете администратора, см. Подключение к SQL Server, когда системные администраторы заблокированы.)

  2. На начальной странице введите SQL Server Management Studio или в более старых версиях Windows в меню «Пуск» выберите Все программы , укажите Microsoft SQL Server , а затем щелкните SQL Server Management Studio .

  3. В диалоговом окне Connect to Server в поле типа Server выберите Database Engine .В поле Authentication выберите Windows Authentication . В поле Имя сервера введите один из следующих типов подключения:

    Подключение к Тип Пример
    Экземпляр по умолчанию <имя компьютера> ACCNT27
    Именованный экземпляр <имя компьютера \ имя экземпляра> ACCNT27 \ PAYROLL

    Примечание

    При подключении к SQL Server из клиентского приложения на том же компьютере используется протокол общей памяти.Общая память — это тип локального именованного канала, поэтому иногда возникают ошибки, касающиеся каналов.

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

    Примечание

    Некоторые сообщения об ошибках, переданные клиенту намеренно, не содержат достаточно информации для устранения проблемы. Это функция безопасности, позволяющая избежать предоставления злоумышленнику информации о SQL Server.Чтобы просмотреть полную информацию об ошибке, просмотрите журнал ошибок SQL Server. Подробности указаны там.

  4. Если вы получаете сообщение об ошибке 18456 Ошибка входа для пользователя , раздел электронной документации MSSQLSERVER_18456 содержит дополнительную информацию о кодах ошибок. А в блоге Аарона Бертрана есть обширный список кодов ошибок в разделе Устранение неполадок при ошибке 18456. Вы можете просмотреть журнал ошибок с помощью SSMS (если вы можете подключиться) в разделе «Управление» обозревателя объектов.В противном случае вы можете просмотреть журнал ошибок с помощью программы Windows Notepad. Местоположение по умолчанию зависит от вашей версии и может быть изменено во время установки. Расположение по умолчанию для SQL Server 2019 (15.x) — C: \ Program Files \ Microsoft SQL Server \ MSSQL15.MSSQLSERVER \ MSSQL \ Log \ ERRORLOG .

  5. Если вы можете подключиться с использованием общей памяти, протестируйте подключение с помощью TCP. Вы можете принудительно установить TCP-соединение, указав перед именем tcp: . Например:

    Подключение к: Тип: Пример:
    Экземпляр по умолчанию tcp: <имя компьютера> tcp: ACCNT27
    Именованный экземпляр tcp: <имя компьютера / имя экземпляра> tcp: ACCNT27 \ PAYROLL
  6. Если вы можете подключиться к общей памяти, но не к TCP, то вы должны исправить проблему TCP.Скорее всего, проблема в том, что TCP не включен. Чтобы включить TCP, см. Действия по включению протоколов выше.

  7. Если ваша цель — подключиться с учетной записью, отличной от учетной записи администратора, как только вы сможете подключиться как администратор, попробуйте подключение еще раз, используя имя входа для проверки подлинности Windows или имя входа для проверки подлинности SQL Server, которое использует клиентское приложение.

Получить IP-адрес сервера

Получите IP-адрес компьютера, на котором размещен экземпляр SQL Server.

  1. В меню «Пуск» выберите Выполнить . В окне Выполнить введите cmd , а затем нажмите ОК .
  2. В окне командной строки введите ipconfig и нажмите клавишу ВВОД. Запишите адрес IPv4 и адрес IPv6 .

SQL Server может подключаться по протоколу IP версии 4 или IP версии 6. Ваша сеть может разрешить одно или то и другое. Большинство людей начинают с поиска неисправностей в адресе IPv4 .Это короче и легче набирать.

Получить TCP-порт экземпляра SQL Server

В большинстве случаев вы подключаетесь к компоненту Database Engine с другого компьютера по протоколу TCP.

  1. Используя SQL Server Management Studio на компьютере, на котором запущен SQL Server, подключитесь к экземпляру SQL Server. В обозревателе объектов разверните Management , разверните Журналы SQL Server , а затем дважды щелкните текущий журнал.
  2. В средстве просмотра журнала нажмите кнопку Фильтр на панели инструментов.В поле Сообщение содержит текст введите сервер прослушивает , щелкните Применить фильтр , а затем щелкните ОК .
  3. Должно быть указано сообщение, подобное Сервер прослушивает ['any' 1433] .

Это сообщение указывает, что этот экземпляр SQL Server прослушивает все IP-адреса на этом компьютере (для IP версии 4) и прослушивает TCP-порт 1433 (TCP-порт 1433 обычно является портом, используемым компонентом Database Engine или сервером). экземпляр SQL Server по умолчанию.Только один экземпляр SQL Server может использовать порт, поэтому, если установлено несколько экземпляров SQL Server, некоторые экземпляры должны использовать другие номера портов.) Запишите номер порта, используемый экземпляром SQL Server, который вы пытаетесь чтобы подключиться к.

Примечание

IP-адрес 127.0.0.1 , вероятно, указан. Он называется адресом адаптера обратной связи. Только процессы на одном компьютере могут использовать его для подключения. Это может быть полезно для устранения неполадок, но вы не можете использовать его для подключения с другого компьютера.

Включить протоколы

В некоторых установках SQL Server подключение к ядру СУБД с другого компьютера невозможно, если администратор не использует Configuration Manager для его включения. Чтобы разрешить соединения с другого компьютера:

  1. Откройте диспетчер конфигурации SQL Server, как описано ранее.
  2. С помощью Configuration Manager на левой панели разверните Сетевая конфигурация SQL Server , а затем выберите экземпляр SQL Server, к которому вы хотите подключиться.На правой панели перечислены доступные протоколы подключения. Общая память обычно включена. Его можно использовать только с одного компьютера, поэтому в большинстве установок общая память остается включенной. Для подключения к SQL Server с другого компьютера обычно используется TCP / IP. Если TCP / IP не включен, щелкните правой кнопкой мыши TCP / IP , а затем щелкните Включить .
  3. Если вы изменили включенный параметр для любого протокола, перезапустите компонент Database Engine. На левой панели выберите Службы SQL Server .На правой панели щелкните правой кнопкой мыши экземпляр компонента Database Engine и выберите Перезапустить .

Тестирование подключения TCP / IP

Для подключения к SQL Server с помощью TCP / IP требуется, чтобы Windows могла установить соединение. Используйте инструмент ping для проверки TCP.

  1. В меню «Пуск» выберите Выполнить . В окне Выполнить введите cmd , а затем нажмите ОК .

  2. В окне командной строки введите ping , а затем IP-адрес компьютера, на котором работает SQL Server.Например:

    • IPv4: пинг 192.168.1.101
    • IPv6: эхо-запрос fe80 :: d51d: 5ab5: 6f09: 8f48% 11
  3. Если ваша сеть настроена правильно, ping возвращает Reply from , за которым следует некоторая дополнительная информация. Если ping возвращает Целевой хост недоступен или Истекло время ожидания запроса , то TCP / IP настроен неправильно. Ошибки на этом этапе могут указывать на проблему с клиентским компьютером, серверным компьютером или что-то в сети, например маршрутизатор.Чтобы устранить неполадки в сети, см. Расширенное устранение неполадок TCP / IP.

  4. Затем, если проверка связи с использованием IP-адреса прошла успешно, проверьте, может ли имя компьютера быть преобразовано в адрес TCP / IP. На клиентском компьютере в окне командной строки введите ping , а затем имя компьютера, на котором работает SQL Server. Например, ping newofficepc .

  5. Если ping на IP-адрес завершается успешно, но ping на компьютер возвращает Destination host unreachable or Request timed out , возможно, на клиентском компьютере кэширована старая (устаревшая) информация о разрешении имен.Введите ipconfig / flushdns , чтобы очистить кеш DNS (динамическое разрешение имен). Затем снова пропингуйте компьютер по имени. При пустом кэше DNS клиентский компьютер проверяет наличие самой последней информации об IP-адресе серверного компьютера.

  6. Если ваша сеть настроена правильно, ping возвращает Reply from , за которым следует некоторая дополнительная информация. Если вы можете успешно проверить связь с серверным компьютером по IP-адресу, но получите сообщение об ошибке, например, Целевой хост недоступен. или Истекло время ожидания запроса. при проверке связи по имени компьютера, разрешение имен настроено неправильно. (Дополнительные сведения см. В ранее упомянутой статье 2006 г. Как устранить основные проблемы TCP / IP.) Успешное разрешение имени не требуется для подключения к SQL Server, но если имя компьютера не может быть преобразовано в IP-адрес, тогда соединения должны быть выполнены с указанием IP-адреса. Разрешение имени может быть исправлено позже.

Открыть порт в брандмауэре

По умолчанию брандмауэр Windows включен и блокирует соединения с другим компьютером.Чтобы подключиться с помощью TCP / IP с другого компьютера, на компьютере с SQL Server необходимо настроить брандмауэр, чтобы разрешить подключения к порту TCP, используемому компонентом Database Engine. Экземпляр по умолчанию по умолчанию прослушивает TCP-порт 1433. Если вы присвоили экземплярам имена или изменили порт экземпляра по умолчанию, TCP-порт SQL Server может прослушивать другой порт. См. Раздел Получение TCP-порта экземпляра SQL Server.

Если вы подключаетесь к именованному экземпляру или к порту, отличному от TCP-порта 1433, необходимо также открыть UDP-порт 1434 для службы браузера SQL Server.Пошаговые инструкции по открытию порта в брандмауэре Windows см. В разделе Настройка брандмауэра Windows для доступа к ядру СУБД.

Проверить соединение

Как только вы сможете подключиться с помощью TCP на том же компьютере, самое время попробовать подключиться с клиентского компьютера. Теоретически вы можете использовать любое клиентское приложение, но, чтобы избежать дополнительных сложностей, установите на клиенте инструменты управления SQL Server и попробуйте использовать SQL Server Management Studio.

  1. На клиентском компьютере с помощью SQL Server Management Studio попытайтесь подключиться, используя IP-адрес и номер порта TCP в формате IP-адрес номер порта запятой.Например, 192.168.1.101,1433 . Если это соединение не удается, возможно, у вас одна из следующих проблем:

  2. После того, как вы сможете подключиться, используя IP-адрес и номер порта, попытайтесь подключиться, используя IP-адрес без номера порта. Для экземпляра по умолчанию просто используйте IP-адрес. Для именованного экземпляра используйте IP-адрес и имя экземпляра в формате IP-адрес обратная косая черта имя экземпляра, например 192.168.1.101 \ <имя экземпляра> Если это не сработает, возможно, у вас есть одна из следующих проблем. :

    • Если вы подключаетесь к экземпляру по умолчанию, возможно, он прослушивает порт, отличный от TCP-порта 1433, и клиент не пытается подключиться к правильному номеру порта.
    • Если вы подключаетесь к именованному экземпляру, номер порта не возвращается клиенту.

    Обе эти проблемы связаны со службой обозревателя SQL Server, которая предоставляет номер порта клиенту. Решения:

    • Запустите службу обозревателя SQL Server. См. Инструкции по запуску браузера в диспетчере конфигурации SQL Server.
    • Служба обозревателя SQL Server блокируется брандмауэром. Откройте UDP-порт 1434 в брандмауэре.Вернитесь в раздел Открыть порт в брандмауэре. Убедитесь, что вы открываете порт UDP, а не порт TCP.
    • Информация о UDP-порте 1434 заблокирована маршрутизатором. Связь UDP (протокол пользовательских дейтаграмм) не предназначена для прохождения через маршрутизаторы. Это предохраняет сеть от заполнения низкоприоритетным трафиком. Вы можете настроить маршрутизатор для пересылки UDP-трафика или всегда указывать номер порта при подключении.
    • Если на клиентском компьютере используется Windows 7 или Windows Server 2008 (или более поздняя операционная система), трафик UDP может быть сброшен клиентской операционной системой, поскольку ответ от сервера возвращается с IP-адреса, отличного от запрошенного. .Это функция безопасности, блокирующая «неплотное сопоставление источников». Дополнительные сведения см. В разделе IP-адреса нескольких серверов в электронной документации по устранению неполадок: истекло время ожидания. Это статья из SQL Server 2008 R2, но принципы все еще применяются. Вы можете настроить клиент на использование правильного IP-адреса или всегда указывать номер порта при подключении.
  3. После того, как вы сможете подключиться, используя IP-адрес (или IP-адрес и имя экземпляра для именованного экземпляра), попытайтесь подключиться, используя имя компьютера (или имя компьютера и имя экземпляра для именованного экземпляра).Поместите tcp: перед именем компьютера, чтобы установить TCP / IP-соединение. Например, для экземпляра по умолчанию на компьютере с именем ACCNT27 используйте tcp: ACCNT27 Для именованного экземпляра с именем PAYROLL на этом компьютере используйте tcp: ACCNT27 \ PAYROLL Если вы можете подключиться, используя IP-адрес, но Если вы не используете имя компьютера, то у вас проблема с разрешением имени. Вернитесь к разделу Тестирование соединения TCP / IP , раздел 4.

  4. После того, как вы сможете подключиться, используя имя компьютера с принудительной установкой TCP, попробуйте подключиться, используя имя компьютера, но не принудительно.Например, для экземпляра по умолчанию используйте только имя компьютера, такое как CCNT27 Для именованного экземпляра используйте имя компьютера и имя экземпляра, например ACCNT27 \ PAYROLL . Если вы можете подключиться с принудительным использованием TCP, но не без принудительного TCP, тогда клиент, вероятно, использует другой протокол (например, именованные каналы).

    1. На клиентском компьютере с помощью диспетчера конфигурации SQL Server на левой панели разверните Собственный клиент SQL версия Конфигурация , а затем выберите Клиентские протоколы .
    2. Убедитесь, что на правой панели включен TCP / IP. Если TCP / IP отключен, щелкните правой кнопкой мыши TCP / IP , а затем щелкните Включить .
    3. Убедитесь, что порядок протоколов для TCP / IP меньше, чем для именованных каналов (или VIA в более старых версиях). Обычно следует оставлять общую память в порядке 1, а TCP / IP — в порядке 2. Общая память используется только тогда, когда клиент и SQL Server работают на одном компьютере. Все включенные протоколы проверяются по порядку до тех пор, пока один из них не завершится успешно, за исключением того, что общая память пропускается, если соединение не с одним и тем же компьютером.

Обнаружение сетевых ошибок и их влияния на услуги

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

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

TCP — протокол вашего выбора с 1981 г.

Набор протоколов TCP / IP, который мы все так хорошо знаем, существует уже почти 40 лет. Хотя на протяжении многих лет были разработаны некоторые альтернативы, TCP / IP по-прежнему хорошо работает и является основой почти всех сетей, которые мы знаем сегодня.Одна из причин, по которой этот стек протоколов все еще существует, заключается в том, что он способен самостоятельно компенсировать многие ошибки. Соответствующий сезону TCP — это Дед Мороз протоколов. Он знает, находится ли ваша служба в спящем режиме, он знает, активен ли он, он знает, работают ли соединения плохо или хорошо, поэтому [внимательно слушайте, что он говорит] . Вашим сервисам не нужно беспокоиться о повторных передачах или перегрузке сети. TCP / IP делает все возможное, чтобы ваши соединения с отслеживанием состояния были надежными и хорошо работающими.Тем не менее, любой, кто запускает приложения в производственной среде, должен понимать TCP и его основы.

Пять самых распространенных сетевых ошибок

Сетевые коллизии

Это старая, но полезная вещь, которая сейчас почти не актуальна из-за полнодуплексных коммутаторов и технологических достижений. Раньше, если два устройства в одной сети Ethernet (например, подключенные через концентратор) пытались передать данные одновременно, сеть обнаруживала конфликт и отбрасывала оба пакета.Протокол CSMA / CD, который следил за тем, чтобы никто не передавал данные до того, как устройство начало передавать свои собственные данные, был шагом в правильном направлении. В полнодуплексных коммутаторах, где конечные точки связи могут общаться друг с другом одновременно, эта потенциальная ошибка устарела. Даже в беспроводных сетях, которые по-прежнему работают в основном как концентраторы, сетевыми коллизиями можно пренебречь, поскольку существуют процедуры, позволяющие в первую очередь избегать коллизий (например, CSMA / CA или RTS / CTS).

Ошибки контрольной суммы

Когда вы загружаете файлы из Интернета, у вас часто есть возможность проверить целостность файла с помощью хэша MD5 или SHA-1. С помощью контрольных сумм на сетевом уровне мы можем определить, был ли бит переключен, пропущен или дублирован при передаче данных по сети. Контрольные суммы гарантируют, что полученные данные идентичны переданным.

Контрольные суммы используются в заголовках Ethernet, IP и TCP.

. Пакеты с неправильными контрольными суммами не обрабатываются принимающим узлом.Если контрольная сумма Ethernet (CRC) неверна, кадр Ethernet незаметно отбрасывается сетевым интерфейсом и никогда не виден операционной системой, даже средствами захвата пакетов. С контрольной суммой IP и контрольной суммой TCP в соответствующих заголовках есть два дополнительных контролирующих органа, которые могут обнаруживать ошибки целостности. Имейте в виду, что, несмотря на попытки подсчета контрольных сумм, есть некоторые ошибки, которые невозможно обнаружить.

Полные очереди

Если очередь обработки на коммутаторе или маршрутизаторе перегружена, входящие пакеты будут отброшены.Также, если очередь для входящих пакетов на хосте, к которому вы пытаетесь подключиться, заполнена, пакеты также будут отброшены. Такое поведение активно используется во время DoS / DDoS-атак. Таким образом, хотя на самом деле это хорошо, что хост принимает только то количество пакетов, которое он может обработать, такое поведение можно использовать для отключения вашей службы.

Срок жизни превысил

Поле времени жизни (TTL) в заголовке IPv4 имеет неверное имя. Каждый маршрутизатор, пересылающий IP-пакет, уменьшает значение поля на единицу — на самом деле это не имеет никакого отношения ко времени.В заголовке IPv6 это поле называется «предел прыжка». Если значение TTL достигает 0, диспетчеру пакета отправляется ICMP-сообщение «время жизни превышено». Между тем, некоторые сетевые компоненты незаметно отбрасывают пакеты с нулевым TTL. Этот механизм полезен для предотвращения попадания пакетов в бесконечный цикл маршрутизации в вашей сети. Наблюдательный читатель и ветеран сети знаком с этой техникой, потому что traceroute использует ее для идентификации всех переходов, которые пакет делает на своем пути к месту назначения.

Повторная передача пакетов

Во-первых, повторные передачи необходимы для обеспечения надежной сквозной связи в сетях. Повторные передачи — верный признак того, что возможности самовосстановления протокола TCP работают — они являются симптомом проблемы, а не проблемой сами по себе. Общие причины повторных передач включают перегрузку сети, когда пакеты отбрасываются (либо сегмент TCP теряется на пути к месту назначения, либо связанный ACK теряется на обратном пути к отправителю), жесткие правила QoS маршрутизатора, которые дают предпочтение определенным протоколы и сегменты TCP, которые прибывают в пункт назначения не по порядку, обычно из-за того, что порядок сегментов изменился на пути от отправителя к месту назначения.Скорость ретрансляции трафика из и в Интернет не должна превышать 2%. Если ставка выше, это может повлиять на удобство использования вашего сервиса.

Три команды, которые необходимо знать для сбора информации о сетевых ошибках

Теперь мы знаем о типичных ошибках — давайте взглянем на устранение неполадок в сети. Хорошая новость заключается в том, что большинство проблем можно найти с помощью стандартных инструментов, которые обычно являются частью вашей операционной системы.

ifconfig

Первое место, где можно найти основную информацию о ваших сетевых интерфейсах, — это старый добрый ifconfig .

ifconfig показывает подробную информацию об указанном сетевом интерфейсе.

Помимо MAC-адреса и информации IP-адреса для v4 и v6 вы найдете подробную статистику о полученных и переданных пакетах. Строка, начинающаяся с RX, содержит информацию о полученных пакетах. Строки TX содержат информацию о переданных пакетах.

Информация о приеме
Подробная информация о полученных пакетах
  • пакетов показывает количество успешно принятых пакетов.
  • Ошибки могут возникать в результате неисправных сетевых кабелей, неисправного оборудования (например, сетевых адаптеров, портов коммутатора), ошибок CRC или несоответствия скорости или дуплексного режима между компьютером и коммутатором, что также может проявляться в большом количестве конфликтов (CSMA / CD передает привет). Вы можете проверить конфигурацию на своем компьютере с помощью ethtool , чтобы узнать, с какой скоростью работает ваш сетевой интерфейс и является ли соединение полнодуплексным или нет.
  • сброшено может указывать на то, что ваша система не может обрабатывать входящие пакеты или отправлять исходящие пакеты достаточно быстро, вы получаете или отправляете пакеты с плохими тегами VLAN, вы используете неизвестные протоколы или получаете пакеты IPv6 и ваш компьютер не поддерживает IPv6.Вы можете противостоять первой ошибке, увеличив кольцевой буфер. Это буфер, в который сетевая карта передает кадры, прежде чем поднимать IRQ в ядре, для RX вашего сетевого интерфейса с использованием ethtool .
  • переполнений отображает количество переполнений FIFO, что указывает на то, что ядро ​​не успевает за скоростью очищаемого кольцевого буфера.
  • Кадр подсчитывает количество полученных неправильно выровненных кадров Ethernet.
Информация о передаче
Подробная информация о переданных пакетах
  • пакетов показывает количество успешно переданных пакетов.
  • ошибок показывает количество ошибок, которые произошли при передаче пакетов из-за ошибок несущей (несоответствие дуплексного режима, неисправный кабель), ошибок FIFO, ошибок периодического сигнала и ошибок окна.
  • сброшено указывает на перегрузку сети, например, очередь на порту коммутатора, к которому подключен ваш компьютер, заполнена, а пакеты отбрасываются, поскольку он не может передавать данные достаточно быстро.
  • переполнений указывает, что кольцевой буфер сетевого интерфейса заполнен, и сетевой интерфейс, похоже, не получает времени ядра для отправки кадров, застрявших в кольцевом буфере.Опять же, может помочь увеличение буфера передачи с помощью ethtool .
  • несущая показывает количество ошибок несущей, указывающих на несоответствие дуплексного режима или неисправное оборудование.
  • коллизий показывает количество коллизий, возникших при передаче пакетов, которое в современных сетях должно быть равно нулю.
  • txqueuelen управляет длиной буфера передачи сетевого интерфейса. Этот параметр актуален только для некоторых дисциплин организации очереди и может быть перезаписан с помощью команды tc .Для получения дополнительной информации о дисциплинах организации очередей ознакомьтесь с этим подробным описанием организации очередей в сетевом стеке Linux и на главной странице tc-pfifo.

netstat

Чтобы увидеть более подробную сетевую статистику для протоколов TCP, UDP, IP и ICMP, вы можете использовать netstat -s . Это возвращает много информации, а выходной формат находится в удобочитаемом формате, например, количество повторно переданных и отброшенных пакетов, отсортированных по протоколу. Если вы хотите сосредоточиться на повторных передачах TCP, вы можете отфильтровать соответствующую информацию.

netstat показывает подробную информацию о повторных передачах TCP.

netstat показывает, что существует 54 повторно переданных сегмента. Это означает, что для 54 сегментов TCP соответствующий ACK не был получен в течение тайм-аута. Три сегмента TCP были «быстро повторно переданы» в соответствии с алгоритмом быстрой повторной передачи в RFC 2581. Повторная передача TCP SYN может произойти, если вы хотите подключиться к удаленному узлу, а порт на удаленном узле не открыт (см. Пример ниже).

Попытка подключиться к закрытому порту увеличивает счетчик повторной передачи TCP SYN

ethtool

Этот инструмент позволяет запрашивать и контролировать настройки сетевого интерфейса и сетевого драйвера, как было показано ранее.Он показывает вам подробный список всех ошибок, которые могут возникнуть на уровне сетевого интерфейса, таких как ошибки CRC и ошибки оператора связи. Если у вас нет повторных передач на уровне TCP, но ifconfig по-прежнему показывает много ошибочных пакетов, это то место, где нужно искать особенности. Если в выводе ethtool отображается много ошибок, это обычно означает, что что-то не так с оборудованием (сетевой адаптер, кабель, порт коммутатора).

ethtool знает все, что нужно знать о вашем сетевом интерфейсе, включая ошибки

Некоторые могут захотеть копнуть глубже, чтобы узнать все об этих ошибках.Следующим шагом будет чтение книги драйверов устройств Linux, ее переваривание, а затем начало чтения исходного кода ядра (например, linux / netdevice.h) и кода сетевого драйвера (например, драйвера Intel e1000).

tcpretrans

tcpretrans является частью пакета perf-tools. Он предлагает вам текущий тикер повторно переданных сегментов TCP, включая адрес и порт источника и назначения, а также информацию о состоянии TCP. Если вы подозреваете, что за повторную передачу TCP отвечает более одного приложения или службы, tcpretrans позволяет вам отлаживать сетевые соединения, если вы вызываете свои службы изолированно друг от друга и наблюдаете за выводом tcpretrans .

netstat показывает подробную информацию о повторных передачах TCP

tcpdump

tcpdump — это сетевой анализатор командной строки, который показывает трафик, указанный фильтрами, непосредственно в командной строке. С помощью параметра командной строки вы можете записать вывод в файл для дальнейшего анализа. tcpdump доступен практически в каждом дистрибутиве * nix из коробки и поэтому является предпочтительным инструментом для быстрого прагматического анализа сети.

Wireshark

Wireshark , ранее известный как Ethereal, — это швейцарский армейский нож инструментов анализа сетей и протоколов для Windows и Unix, когда дело доходит до анализа сеансов TCP, выявления сбойных подключений и просмотра всего сетевого трафика, который идет на ваш компьютер и с него.Вы можете настроить его для прослушивания определенного сетевого интерфейса, указать фильтры, чтобы, например, сконцентрироваться на определенном протоколе, хосте или порте, и вы можете выгружать захваченный трафик в файл для будущего анализа. Кроме того, Wireshark может читать файлов tcpdump , поэтому вы можете захватывать трафик на одном хосте в командной строке и открывать файл для анализа в Wireshark на своем компьютере для анализа. Еще одна особенность WireShark заключается в том, что он знает множество распространенных протоколов приложений (например, HTTP и FTP).Таким образом, вы можете увидеть, что происходит над уровнем 4, и получить представление о полезных нагрузках, которые отправляются с использованием TCP.

Wireshark показывает полезную нагрузку MySQL

. Ниже приводится обзор, который показывает, какие уровни OSI охватывают упомянутые выше инструменты и на каком уровне OSI возникают упомянутые выше сетевые ошибки.

Сетевые ошибки и инструменты анализа, назначенные уровням OSI

Теперь вы знаете, как и где найти информацию о сетевых ошибках. Но что вы можете узнать из этой информации? Для начала вы можете узнать, с какими типами ошибок вы сталкиваетесь, что поможет вам в дальнейшем расследовании.Хотя разве вам вообще нужно что-то расследовать? В конце концов, исследовать каждый повторно переданный или отброшенный пакет бессмысленно — стек сетевых протоколов обладает способностью самовосстановления, а некоторые из предполагаемых ошибок являются просто частью игры.

Что действительно важно

Обычно в сети задействовано несколько компьютеров, коммутаторов и маршрутизаторов. Когда у вас несколько хостов и вы обнаруживаете проблему в своей сети, неэффективно использовать ssh на каждом компьютере и выполнять все эти упражнения, чтобы выяснить, что происходит.В конечном счете, в более сложных средах вам нужна поддержка инструментов, чтобы всегда быть в курсе событий.

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

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

Существует ряд показателей, связанных с сетью и услугами, которые вы можете измерить и оценить. Следующие три являются хорошей отправной точкой.

Сетевой трафик
Измерение сетевого трафика дает хорошее представление об общем использовании и производительности вашего сервиса. Это также хороший индикатор того, нужно ли вам масштабировать вашу инфраструктуру (например, вашего одного сервера может быть недостаточно для обработки всей нагрузки).

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

Возможности подключения
Связь показывает процент правильно установленных TCP-соединений по сравнению с TCP-соединениями, которые были отклонены или истекло время ожидания. Он показывает, когда услуги были доступны клиентам, а когда нет, с течением времени.

Мой любимый инструмент для сетевого анализа в центре обработки данных — Dynatrace, но я, очевидно, немного пристрастен.Анализируя состояние сети одного из моих серверов Tomcat (см. Пример ниже), я обнаружил, что время отклика моей службы составляло около 3 мс, не было большого трафика и 100% доступность за последние два часа.

Переход от smartscape к метрикам процесса

Теперь самое интересное — как связать сетевые ошибки с фактическим временем отклика службы. Если время отклика или доступность службы отклоняются от базового значения, вы увидите сводку возникших проблем, в которой показано, сколько пользователей затронуто и какова основная причина проблемы.Что действительно интересно в Dynatrace, так это то, насколько хорошо он объединяет всю эту информацию, чтобы помочь мне оценить и исправить эту проблему.

Dynatrace показывает соответствующие детали для проблем.

Если вы внимательно посмотрите на представление проблемы, вы увидите, что эта проблема затронула реальных пользователей, а именно 688 пользовательских действий в минуту. Кроме того, вы можете видеть, что частота ошибок JavaScript увеличилась и что основной причиной этой проблемы является сбой процесса couchDB (то есть скорость подключения TCP для процесса снизилась до 0%).Если вы нажмете на имя процесса, вы увидите следующий экран, на котором ясно видно, что в TCP-соединениях было отказано, а возможность подключения упала до 0%, пока процесс был перезапущен. Так выглядит обычная сетевая ошибка с точки зрения сервисов.

Мониторинг сети Dynatrace показывает нарушение связи процессов

Заключение

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

Если вам интересно провести тест-драйв сетевого мониторинга Dynatrace, вам обязательно стоит это сделать. Существует уровень бесплатного использования, поэтому вы можете просмотреть все описанные здесь функции и убедиться, насколько хорошо они работают в вашей среде.

Ошибка устранения неполадок: «TCP / IP-соединение с хостом, порт не работает». (KBA1030)

Ошибка устранения неполадок «TCP / IP-соединение с хостом

, порт не удалось

При попытке связать MSSQL dSource отображается следующая ошибка при проверке учетных данных пользователя базы данных:

Соединение TCP / IP с хостом , порт не удалось. Ошибка: «null. Проверьте свойства подключения.Убедитесь, что экземпляр SQL Server запущен на узле и принимает соединения TCP / IP через порт. Убедитесь, что TCP-подключения к порту не блокируются брандмауэром. «.

* где и показывают определенное имя хоста сервера MSSQL и порт службы в вашем сообщении об ошибке.

Однако у этой ошибки может быть несколько причин, которые не сразу очевидны. Этот совет объясняет возможные причины и шаги, которые конечный пользователь может предпринять для самодиагностики и устранения этой ошибки.

Причина и решение

На самом деле ошибка может иметь одну или несколько из следующих причин:

  • Сбой при разрешении DNS имени сервера MSSQL, возвращенного самим MSSQL
  • Подключение к назначенному порту из механизма Delphix
  • Неверное имя пользователя и / или пароль
  • Гранулярные ограничения доступа MSSQL на основе хоста источника входа

Разобраться в этих вещах по порядку гораздо проще, начиная с MSSQL.Поскольку первые два элемента связаны с сетью, если они не являются основной причиной, то MSSQL должен что-то зарегистрировать с указанием причины сбоя. Если MSSQL не обнаружил попытки, внимание можно сосредоточить на сетевых проблемах. Логический подход мог бы быть таким:

1. Проверьте исходный хост Windows

Как пользователь в группе «Администраторы» войдите на хост Windows для нужного dSource и откройте средство просмотра событий. Любая попытка входа в систему на уровне MSSQL, которая фактически достигла хоста, должна привести к событию MSSQL, зарегистрированному в журнале приложения.Однако также рекомендуется проверять наличие событий в журналах системы и безопасности. Если была зарегистрирована неудачная попытка, MSSQL укажет, почему вход в систему был отклонен, в тексте события. Здесь должны быть четко видны неправильные имя пользователя и / или пароли или отдельные ограничения доступа.

2. Проверьте разрешение DNS для имени сервера MSSQL

Если MSSQL ничего не записал ни в один из журналов событий Windows, затем посмотрите на сеть. Имя хоста, отображаемое в сообщении об ошибке, возвращается MSSQL во время обнаружения среды и должно быть разрешено для любого хоста, который будет подключаться к экземпляру MSSQL.Чтобы убедиться, что разрешение DNS для этого имени хоста также работает для Delphix Engine, вы должны выполнить nslookup с другого хоста в той же подсети, что и Delphix Engine , и с использованием того же настроенного DNS-сервера. Например, механизм Delphix Engine находится в сети 172.10.200.23/16 и не может проверить учетные данные для сервера MSSQL « somehost.corp» и был настроен на использование DNS-сервера 172.10.0.3. Другой хост в подсети (например, 172.10.200.24) можно использовать для проверки DNS с помощью следующей команды:

Использование

$ nslookup <ИМЯ_ХОСТА>

Пример

$ nslookup somehost.corp 172.10.0.3

Если разрешение не удается, необходимо обновить DNS-серверы, чтобы разрешить имя сервера, возвращаемое MSSQL, или перенастроить MSSQL, чтобы предоставить имя сервера, которое разрешается всеми хостами, которым необходимо его достичь. В большинстве случаев проще и правильнее решить эту проблему на уровне конфигурации DNS.

Если разрешение DNS для имени сервера прошло успешно, необходимо также выполнить тест для возвращенного IP-адреса. Для правильного разрешения имен требуется как прямое (на основе имени), так и обратное (на основе IP-адреса) разрешение имен для правильной работы.

3. Проверьте настроенный порт экземпляра

Порт экземпляра, показанный в сообщении об ошибке, должен быть открыт и принимать соединения от механизма Delphix. Подобно тесту DNS выше, другой хост в той же подсети, что и Delphix Engine , должен использоваться для попытки проверить, открыт ли порт.Используя тот же пример, где движок Delphix находится в сети 172.10.200.23/16, можно использовать другой хост (например, 172.10.200.24) для выполнения telnet-соединения с определенным портом. В большинстве случаев это будет порт 1433.

Использование

$ telnet <ИМЯ ХОСТА> <ПОРТ>

Пример

$ telnet somehost.corp 1433

В случае успеха должно появиться сообщение, указывающее на то, что соединение открыто.

Если тестировать подключение с помощью telnet в Windows, об успешном выполнении может свидетельствовать то, что окно командной строки станет пустым.Сообщение об ошибке будет показано, если соединение не удастся.

Этот тест не может показать, существуют ли правила брандмауэра, которые специально блокируют доступ к порту сервера MSSQL из Delphix Engine. Тест является проверкой работоспособности, но может потребоваться сетевой администратор, чтобы точно подтвердить, что настроено, а что не настроено на каком-либо брандмауэры между движком Delphix и хостом MSSQL.

4. Убедитесь, что аутентифицированный вход MSSQL возможен с другого хоста через MSSQL Management Studio

Используя другой хост в той же подсети, что и Delphix Engine , выполните тест входа на сервер MSSQL, используя то же имя хоста и порт, которые указаны в сообщении об ошибке, и те же имя пользователя и пароль, которые были указаны в Add dSource. рабочий процесс.Убедитесь, что попытка входа настроена для проверки подлинности SQL Server , а не для проверки подлинности Windows.

Как настроить защиту TCP — продукты EPAM-B2BITS для рынков капитала

Эта статья применима к FIX Antenna C ++ /.Net (начиная с 2.24.0) и FIXEdge (начиная с 5.12.0).

Для настройки защиты TCP в FIXEdge следует использовать FIXEdge.properties, для настройки FIX Antenna C ++ /.Сеть — engine.properties.

Можно предотвратить одно из возможных последствий ненормального поведения пользователя — исчерпание ресурсов системы.

В качестве примера рассмотрим случай, когда клиент устанавливает соединение, не отправляет сообщение о входе в систему и повторяет шаги несколько раз.

В этом случае, как и для Linux , все файловые дескрипторы будут зарезервированы, поэтому новые подключения будут отклонены по следующей причине:

[ОШИБКА] 20160706-08: 04: 23 .778 [1401435104] [Engine] - Входящее TCP-соединение было исключением: невозможно принять соединение через порт 9105. Пожалуйста, проверьте настройки ulimits в ОС . Открыто слишком много файлов . (Код ошибки = 24)

Что касается Windows , диспетчер зависнет из-за увеличения количества подключений, которые необходимо обработать.

Этот случай можно решить, настроив определенные свойства в FIXEdge.properties (engine.properties), который отвечает за TCP-защиту .

  •  ProtectionTCP.WaitLogon = 30000 

    Свойство для указания тайм-аута соединения (в миллисекундах) ожидания входа в систему. Когда время истекает, соединение закрывается по соответствующей причине:

    [ИНФОРМАЦИЯ] 20160706-07: 40: 53.032 [1274500] [Engine] - Сообщение о входе не получено в заданный время интервал (1000 мс) от 127.0.0.1: 60376
    [ИНФОРМАЦИЯ] 20160706-07: 40: 53.032 [1274500] [Engine] - Входящее TCP-соединение было закрыто (с 127.0.0.1:60376).

    Отключить, если равно 0.

    Свойство будет включено, только если ProtectionTCP.Enabled = true

  •  ProtectionTCP.SizeWaitHostMax = 3 

    Свойство для указания максимального количества ожидающих соединений для входа с одного хоста. Когда количество подключений с одного и того же хоста превышает указанное значение свойства, новые подключения будут отклонены с соответствующей причиной.

    [ИНФОРМАЦИЯ] 20160706-07: 30: 21.566 [1271868] [Engine] - Входящее TCP-соединение отклонено (с 127.0.0.1:60300). Превышен лимит подключений (3) с одного хоста.

    Отключить, если равно 0.

    Свойство будет включено, только если ProtectionTCP.Enabled = true

  •  ProtectionTCP.SizeBufferMax = 262144 

    Задает максимальный размер (в байтах) буфера, чтобы можно было избежать ситуации, когда пользователь отправляет высоконагруженный мусор.Он указан в файле FIXEdge.properties (engine.properties):

    ProtectionTCP.SizeBufferMax = 10000000

    При превышении лимита соединение будет закрыто и соответствующая причина будет быть записанным в журнал.

    [ИНФОРМАЦИЯ] 20160706-07: 21: 19.809 [1271256] [Engine] - Обнаружено входящее TCP-соединение (из 127.0.0.1:60258).
    [INFO] 20160706-07: 21: 19.965 [1271896] [Engine] - Превышен буфер получен ограничен (1000000) от 127.0.0.1:60258
    [INFO] 20160706-07: 21: 19.966 [1271896] [ Engine] - входящее TCP-соединение было закрыто (с версии 127.0.0.1:60258).

    Когда соединение будет восстановлено после закрытия, Клиент отправит сообщение входа в систему с MsgSeqNum = <последний исходящий порядковый номер> +1. В результате FIXEdge (FIX Antenna C ++ /.Net) отправит ResendRequest и получит то же сообщение, которое вызвало отключение. Таким образом, соединение снова будет закрыто.

    Минимальный размер свойства, который можно указать, составляет 262144. Если в свойстве указано меньшее значение, оно будет заменено на 262144 в начале FIXEdge.

    Если указан 0, размер буфера не ограничен.

    Свойство будет включено, только если ProtectionTCP.Enabled = true.

     

Значения по умолчанию

00
Свойство FIXEdge FIX Antenna Protection C ++ /.Net
 false (отключено) 
 ProtectionTCP.WaitLogon 
 10000 
 0 (отключено) 
 ProtectionTCP.SizeWaitHostMax 
 5 
 0 (отключено) 
 ProtectionTCP.SizeBufferMax 
 0 (отключено) 
 0 (отключено) 
01

Как отключить TCP Chimney, TCPIP Offload Engine и / или TCP Segmentation Offload

Проблема

Периодические прерывания связи, заканчивающиеся потерей пакетов, могут привести к зависанию или сбою процессов.Хотя TCP Chimney, TCPIP Offload Engine и TCP Segmentation Offload предназначены для повышения производительности в сети, они часто вызывают больше проблем, чем решают. Всегда рекомендуется отключать эти технологии на сервере eDP / Clearwell.

Известные проблемы с двигателями разгрузки:

Ограничения оборудования - поскольку соединения буферизуются и обрабатываются на микросхеме TOE, ограничения ресурсов возникают чаще, чем если бы они обрабатывались обширными ресурсами ЦП и памяти, доступными операционной системе.Это ограничение ресурсов микросхемы TOE может вызвать проблемы со связью.

Сложность - такие проблемы, как память, используемая открытыми соединениями, недоступны для ОО. TOE также требует очень больших изменений в сетевом стеке для правильной поддержки, и даже когда это сделано, такие функции, как качество обслуживания и фильтрация пакетов, обычно не работают.

Собственный - TOE реализуется каждым поставщиком оборудования по-разному. Это означает, что необходимо переписать больше кода для работы с различными реализациями ОО за счет вышеупомянутой сложности и, возможно, безопасности.Кроме того, встроенное ПО TOE не может быть легко изменено, поскольку оно имеет закрытый исходный код.

Производительность - Каждая сетевая карта TOE имеет ограниченный срок полезного использования, поскольку системное оборудование быстро достигает уровней производительности TOE и в конечном итоге превышает уровни производительности TOE. TOE не увеличивает пропускную способность сети. Проще говоря, TOE снимает ответственность за стек протоколов с ЦП сервера, позволяя ЦП сервера быстрее обрабатывать информацию. По мере увеличения производительности оборудования процессы могут выполнять свою задачу до подтверждения ОО получения передачи; что вызывает проблемы со связью.

Сообщение об ошибке

Произошла ошибка транспортного уровня при отправке запроса на сервер (поставщик: поставщик TCP, ошибка 0 - существующее соединение было принудительно закрыто удаленным хостом.)
ИЛИ
INFO [common.filetransfer.transferError] ( Клиентский считыватель CLEARWELL1.cwlab.local / 192.168.1.101: 53826 D: \ CW \ V811 \ data \ esadb_TestCase \ dataStore_index_ara8sh2zsj_00101188 \ $ 12 $ extensionft -> /192.168.1.101:57156 D: \ CWjara_data_data_s_data_s_data_data_s_data_282_v8111 консолидация :) Клиент отменил перевод

Причина

Эта проблема может возникнуть, если включены TCP Chimney Offload, TCP / IP Offload Engine (TOE) или TCP Segmentation Offload (TSO).

TCP Chimney, TCPIP Offload Engine (TOE) и TCP Segmentation Offload (TSO) выгружает стек протокола TCP на карту сетевого интерфейса (NIC).

  • TCP Chimney - усовершенствование программного обеспечения Microsoft.
  • TOE - это аппаратное усовершенствование производителя сетевых карт.
  • TSO эквивалентен TOE для некоторых конфигураций виртуальной среды.


Функция разгрузки TCP Chimney включена по умолчанию в Windows Server 2003 Scalable Networking Pack.
Это обновление входит в состав Windows Server 2003 с пакетом обновления 2 (SP2), а также может быть установлено на сервере под управлением Windows 2003 с пакетом обновления 1 (SP1).

Решение

Важное примечание для серверов в кластерной среде или использующих объединение сетевых карт

Чрезвычайно важно определить, является ли сервер членом кластера. ДО того, как внесет какие-либо изменения в параметры TCP Offload Engine, описанные в этой статье.Примеры включают узлы отказоустойчивого кластера Windows Server и реплики групп доступности AlwaysOn SQL. Некоторые кластерные приложения требуют включения TCP Offload Engine на каждом узле кластера или реплике для правильной работы. Отключение любых параметров TCP Offload Engine на узлах или репликах кластера может отрицательно повлиять на производительность сети для приложений и / или операционных систем, поддерживающих кластер. Таким образом, не рекомендуется изменять какие-либо параметры TCP Offload Engine для серверов, которые являются узлами или репликами в кластерной среде, без предварительной консультации с документацией по кластерному приложению.Если в документации кластера четко указано, что параметры TCP Offload Engine можно изменить без каких-либо негативных последствий, продолжайте вносить изменения после создания плана отката изменений, если это необходимо. Если есть сомнения, не делайте НЕ , чтобы вносить какие-либо изменения в настройки TCP Offload Engine.

Аналогичное внимание следует уделить серверам, использующим объединение карт сетевого интерфейса (NIC). Некоторым приложениям объединения сетевых адаптеров требуется, чтобы на каждом сетевом адаптере был включен механизм разгрузки TCP для правильной работы.Отключение любых параметров TCP Offload Engine на объединенных сетевых адаптерах может отрицательно повлиять на производительность сети для приложений и / или операционных систем, поддерживающих кластер. Таким образом, рекомендуется не редактировать какие-либо параметры TCP Offload Engine для серверов, использующих объединение сетевых карт, без предварительной консультации с документацией по объединению сетевых адаптеров. Если документация по объединению сетевых адаптеров четко подтверждает, что параметры TCP Offload Engine можно изменить без каких-либо негативных последствий, продолжайте вносить изменения после создания плана отката изменений, если это необходимо. Если есть сомнения, не делайте НЕ , чтобы вносить какие-либо изменения в настройки TCP Offload Engine.

Выполните следующие действия и описанный ниже обходной путь, чтобы лучше решить проблему:

  • Получите последнее обновление базовой системы ввода / вывода (BIOS) для сервера
  • Получите последнее обновление прошивки для сетевого адаптера
  • Получите последнее обновление драйвера для сетевого адаптера


РЕШЕНИЕ:
На серверах Clearwell и Enterprise Vault необходимо внести следующие изменения.

  • Отключить функцию разгрузки TCP Chimney

Сервер Windows 2003:

Если установлена ​​операционная система Microsoft Windows Server 2003, выполните следующие действия:

Предупреждение. Неправильное использование редактора реестра Windows может помешать нормальной работе операционной системы. При внесении изменений в реестр Windows следует проявлять особую осторожность. Модификации реестра должны выполняться только лицами, имеющими опыт использования приложения-редактора реестра.Перед внесением каких-либо изменений в реестр рекомендуется сделать полную резервную копию реестра и рабочей станции.

1. Щелкните Запустите , нажмите Пробег , тип Regedit и нажмите кнопку ОК.

2. Найдите следующий подраздел реестра:

HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Parameters

* Если какой-либо из перечисленных ниже ключей отсутствует, создайте их.

3. Дважды щелкните значок EnableTCPChimney запись реестра.

4. В диалоговом окне «Изменить значение DWORD» введите 0 в поле «Значение» и нажмите кнопку «ОК».

5. Дважды щелкните значок EnableRSS запись реестра.

6. В диалоговом окне «Изменить значение DWORD» введите 0 в поле «Значение» и нажмите кнопку «ОК».

7. Дважды щелкните значок EnableTCPA запись реестра.

8. В диалоговом окне «Изменить значение DWORD» введите 0 в поле «Значение» и нажмите кнопку «ОК».

9. Перезагрузите сервер.

Сервер Windows 2008/2012:

Если установлена ​​операционная система Microsoft Windows Server 2008 или 2012, запустите в командной строке следующее:

1. netsh int tcp set global chimney = disabled

2. netsh int tcp set global rss = disabled

3. netsh int tcp set global netdma = отключено

Примечание. Чтобы отобразить текущие глобальные настройки TCP, используйте команду net shell:

netsh int tcp показать global

4. Перезагрузите сервер.

Примечание. Microsoft выявила проблему при запуске команды netsh для установки глобальных параметров TCP на компьютерах с Windows Server 2008 и Vista.Некоторые глобальные параметры, такие как TCPTimedWaitDelay, можно изменить с их значений по умолчанию или вручную установить значения на 0xffffffff. Перед запуском указанной выше команды Veritas рекомендует ознакомиться со статьей 967224 базы знаний Майкрософт (support.microsoft.com/kb/967224). По завершении выполнения указанной выше команды Veritas также рекомендует просмотреть параметры TCP, указанные в статье базы знаний, и при необходимости применить исправление из статьи.

  • Отключить масштабирование на стороне приема и TOE

Внимание! Инструкции в следующих двух наборах шагов приведут к тому, что плата сетевого интерфейса (NIC) будет заменена и перезапустится.Такой сброс вызовет кратковременную потерю связи через этот сетевой адаптер. Если сетевая карта является единственной сетевой картой в системе или основной сетевой картой, через которую устанавливаются удаленные подключения, Veritas рекомендует запланировать время простоя для выполнения этих шагов с консоли машины.


1. На панели управления откройте «Сетевые подключения».

2. Откройте страницу свойств используемого сетевого подключения.

3. Нажмите «Настроить» (см. Рис. 1).

фигура 1


4. На вкладке «Дополнительно» измените значение все настройки «Разгрузка» и масштабирование на принимающей стороне 0 , г. Отключено или Выкл. (см. Рисунок 2)

фигура 2


5. Нажмите ОК, чтобы сохранить изменения.

  • Отключить TSO (только виртуальные сетевые адаптеры)

1. На панели управления откройте «Сетевые подключения».

2. Откройте страницу свойств используемого сетевого подключения.

3. Нажмите «Настроить» (см. Рис. 3).

Рисунок 3


4. На вкладке «Дополнительно» измените значение TSO Включено с на 0 . (См. Рисунок 4)

Рисунок 4


5. Нажмите ОК, чтобы сохранить изменения.



Дополнительные сведения см. В следующей статье базы знаний Майкрософт

Дополнительные сведения об этих параметрах в Windows 2008 см. В следующей статье базы знаний Майкрософт.

https: // support.microsoft.com/kb/951037

Анализируйте снимки межсетевого экрана Firepower для эффективного устранения сетевых проблем

Введение

В этом документе описываются различные методы анализа перехвата пакетов, направленные на эффективное устранение неполадок в сети. Все сценарии, представленные в этом документе, основаны на реальных пользовательских случаях, замеченных в Центре технической поддержки Cisco (TAC). Документ охватывает захват пакетов с точки зрения межсетевого экрана Cisco следующего поколения (NGFW), но те же концепции применимы и к другим типам устройств.

Предпосылки

Требования

Cisco рекомендует ознакомиться со следующими темами:

  • Архитектура платформы Firepower
  • Журналы NGFW
  • Трассировщик пакетов NGFW

Кроме того, перед началом анализа перехвата пакетов настоятельно рекомендуется выполнить следующие требования:

  • Знать работу протокола - Бесполезно начинать проверку захвата пакета, если вы не понимаете, как работает захваченный протокол
  • Знать топологию - Вы должны знать транзитные устройства.В идеале сквозной. Если это невозможно, вы должны хотя бы знать восходящие и нисходящие устройства
  • .
  • Знать устройство - Вы должны знать, как ваше устройство обрабатывает пакеты, каковы задействованные интерфейсы (например, вход / выход), какова архитектура устройства и каковы различные точки захвата
  • Знать конфигурацию - Вы должны знать, как устройство должно обрабатывать поток пакетов с точки зрения:
    • Интерфейс маршрутизации / выхода
    • Примененных политик
    • Трансляция сетевых адресов (NAT)
  • Знать доступные инструменты - Наряду с захватами рекомендуется также быть готовым применять другие инструменты и методы устранения неполадок, такие как ведение журнала и трассировщики, и при необходимости соотносить их с захваченными пакетами

Используемые компоненты

Информация в этом документе основана на следующих версиях программного и аппаратного обеспечения:

  • Большинство сценариев основано на FP4140 с программным обеспечением FTD 6.5.x.
  • FMC с программным обеспечением 6.5.x.

Информация в этом документе была создана на устройствах в определенной лабораторной среде. Все устройства, используемые в этом документе, были запущены с очищенной (по умолчанию) конфигурацией. Если ваша сеть работает, убедитесь, что вы понимаете потенциальное влияние любой команды.

Справочная информация

Захват пакетов - один из наиболее часто игнорируемых инструментов устранения неполадок, доступных сегодня. Центр технической поддержки Cisco TAC ежедневно решает множество проблем клиентов путем анализа собранных данных.Цель этого документа - помочь сетевым инженерам и специалистам по безопасности выявлять и устранять общие сетевые проблемы, в основном на основе анализа перехвата пакетов.

Как собирать и экспортировать снимки по семейству продуктов NGFW?

В случае устройства Firepower (1xxx, 21xx, 41xx, 93xx) и приложения Firepower Threat Defense (FTD) обработка пакетов может быть визуализирована, как показано на изображении.

  1. Пакет поступает на входящий интерфейс и обрабатывается внутренним коммутатором шасси.
  2. Пакет поступает в механизм FTD Lina, который в основном выполняет проверки L3 / L4.
  3. Если политика требует, пакет проверяется механизмом Snort (в основном проверка L7).
  4. Механизм Snort возвращает вердикт для пакета.
  5. Механизм LINA отбрасывает или пересылает пакет на основе вердикта Snort.
  6. Пакет выходит на шасси через внутренний коммутатор шасси.

Исходя из показанной архитектуры, захваты FTD могут быть сняты в 3 разных местах:

  • FXOS
  • Двигатель FTD Lina
  • Двигатель FTD Snort

Собирать захваты FXOS

Процесс описан в этом документе:

https: // www.cisco.com/c/en/us/td/docs/security/firepower/fxos/fxos271/web-guide/b_GUI_FXOS_ConfigGuide_271/troubleshooting.html#concept_E8823CC63C934A909BBC0DF12F301DED

Захваты FXOS могут быть сделаны только во входном направлении с точки зрения внутреннего коммутатора, как показано на изображении здесь.

Как показано на изображении, это две точки захвата в каждом направлении (из-за внутренней архитектуры коммутатора).

Перехваченные пакеты в точках 2, 3 и 4 имеют виртуальный сетевой тег (VNTag).

Примечание : Захваты FXOS на уровне шасси доступны только на платформах FP41xx и FP93xx. FP1xxx и FP21xx не предоставляют такой возможности.

Включить и собрать FTD Lina Capture

Основные точки захвата:

  • Входящий интерфейс
  • Выходной интерфейс
  • Ускоренный путь безопасности (ASP)

Вы можете использовать пользовательский интерфейс Центра управления огневой мощью (FMC UI) или FTD CLI, чтобы включить и собрать захваты FTD Lina.

Включить захват из CLI на интерфейсе INSIDE:

 firepower #  захват интерфейса CAPI ВНУТРИ соответствие хосту icmp 192.168.103.1 хост 192.168.101.1  

Этот захват соответствует трафику между IP-адресами 192.168.103.1 и 192.168.101.1 в обоих направлениях.

Включите захват ASP, чтобы увидеть все пакеты, отброшенные движком FTD Lina:

 огневая мощь #  захват ASP тип asp-drop все  

Экспорт захвата FTD Lina на FTP-сервер:

 firepower #  copy / pcap capture: CAPI ftp: // ftp_username: ftp_password @ 192.168.78.73 / CAPI.pcap  

Экспорт захвата FTD Lina на сервер TFTP:

 firepower #  copy / pcap capture: CAPI tftp: //192.168.78.73  

Начиная с версии FMC 6.2.x, вы можете включать и собирать захваты FTD Lina из пользовательского интерфейса FMC.

Другой способ сбора данных FTD от межсетевого экрана, управляемого FMC, - это.

Шаг 1

В случае захвата LINA или ASP скопируйте захват на диск FTD, например.

 firepower #  copy / pcap capture: capin disk0: capin.pcap 

Имя захвата источника [capin]?

Целевое имя файла [capin.pcap]?
!!!!
 

Шаг 2

Перейдите в экспертный режим, найдите сохраненный снимок и скопируйте его в / ngfw / var / common location:

 огневая мощь #

Консольное соединение отключено.

>  эксперт
  админ @ огневая мощь: ~ $  sudo su 
Пароль:
корень @ огневая мощь: / home / admin #  cd / mnt / disk0 
root @ firepower: / mnt / disk0 #  ls -al | grep pcap 
-rwxr-xr-x 1 корень root 24 апр 26 18:19 CAPI.pcap
-rwxr-xr-x 1 корневой корень 30110 8 апреля 14:10  capin.pcap 
-rwxr-xr-x 1 корневой корень 6123 8 апр, 14:11 capin2.pcap
корень @ firepower: / mnt / disk0 #  cp capin.pcap / ngfw / var / common
  

Шаг 3

Войдите в FMC, который управляет FTD, и перейдите к Devices> Device Management. Найдите устройство FTD и выберите значок Устранение неполадок :

Шаг 4

Выберите Расширенный поиск неисправностей:

Укажите имя файла захвата и выберите Загрузить:

Дополнительные примеры включения / сбора снимков из пользовательского интерфейса FMC см. В этом документе:

https: // www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/212474-working-with-firepower-threat-defense-f.html

Включение и сбор перехватов FTD Snort

Точка захвата показана на изображении здесь.

Включить захват уровня Snort:

>  захват трафика 

Выберите домен для захвата трафика:
  0 - br1
  1 - Маршрутизатор

Выбор?  1 

Укажите желаемые параметры tcpdump.
(или введите "?" для получения списка поддерживаемых опций)
Опции:  -n хост 192.168.101.1
  

Чтобы записать захват в файл с именем capture.pcap и скопировать его через FTP на удаленный сервер:

>  захват трафика 

Выберите домен для захвата трафика:
  0 - br1
  1 - Маршрутизатор

Выбор?  1 

Укажите желаемые параметры tcpdump.
(или введите "?" для получения списка поддерживаемых опций)
Параметры:  -w capture.pcap host 192.168.101.1 
   CTRL + C <- для остановки захвата  
 
> копия файла 10.229.22.136 ftp / capture.pcap Введите пароль для [email protected]: Копирование capture.pcap Копирование выполнено успешно. >

Для получения дополнительных примеров захвата уровня Snort, которые включают различные фильтры захвата, проверьте этот документ:

https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/212474-working-with-firepower-threat-defense-f.html

Устранение неполадок

Случай 1. Нет TCP SYN на исходящем интерфейсе

Топология показана на изображении здесь:

Описание проблемы: HTTP не работает

Затрагиваемый поток:

Src IP: 192.168.0.100

Dst IP: 10.10.1.100

Протокол: TCP 80

Анализ захвата

Включить захват на движке FTD LINA:

 firepower #  захват CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100 
firepower #  захват CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100
  

Захваты - Функциональный сценарий:

В качестве основы всегда очень полезно иметь захваты из функционального сценария.

Захват, сделанный на интерфейсе NGFW INSIDE, как показано на изображении:

Ключевые точки:

  1. TCP 3-стороннее рукопожатие.
  2. Двунаправленный обмен данными.
  3. Нет задержек между пакетами (в зависимости от разницы во времени между пакетами)
  4. MAC-адрес источника - это правильное нисходящее устройство.

Захват, сделанный на ВНЕШНЕМ интерфейсе NGFW, показан на изображении здесь:

Ключевые точки:

  1. Те же данные, что и в захвате CAPI.
  2. MAC-адрес назначения - это правильное восходящее устройство.

Захваты - нефункциональный сценарий

Из интерфейса командной строки устройства снимки выглядят следующим образом:

 огневая мощь #  показать захват 
захват интерфейса необработанных данных типа CAPI INSIDE  [захват - 484 байта] 
  сопоставить IP-хост 192.168.0.100 хост 10.10.1.100
захват интерфейса необработанных данных типа CAPO ВНЕШНИЙ  [захват - 0 байт] 
  сопоставить IP-хост 192.168.0.100 хост 10.10.1.100
 

Содержание CAPI:

 огневой мощи #  показать захват CAPI 

Захвачено 6 пакетов

   1: 11:47:46.

2 192.168.0.100.3171> 10.10.1.100.80: S 1089825363: 1089825363 (0) win 8192 2: 11: 47: 47.161902 192.168.0.100.3172> 10.10.1.100.80: S 3981048763: 3981048763 (0) win 8192 3: 11: 47: 49.

  • 3 192.168.0.100.3171> 10.10.1.100.80: S 1089825363: 1089825363 (0) win 8192 4: 11: 47: 50.162757 192.168.0.100.3172> 10.10.1.100.80: S 3981048763: 3981048763 (0) win 8192 5: 11: 47: 55.0 192.168.0.100.3171> 10.10.1.100.80: S 1089825363: 1089825363 (0) win 8192 6: 11: 47: 56.164710 192.168.0.100.3172> 10.10.1.100.80: S 3981048763: 3981048763 (0) win 8192
  •  огневая мощь #  показать захват CAPO 
    
      0 пакет захвачен 
    
    Показано 0 пакетов
     

    Это изображение захвата CAPI в Wireshark:

    Ключевые точки:

    1. Видны только пакеты TCP SYN (трехстороннее подтверждение TCP отсутствует).
    2. Невозможно установить 2 сеанса TCP (порт источника 3171 и 3172). Исходный клиент повторно отправляет пакеты TCP SYN. Эти повторно переданные пакеты идентифицируются Wireshark как повторные передачи TCP.
    3. Повторные передачи TCP происходят каждые ~ 3, затем 6 и т.д. секунд
    4. MAC-адрес источника получен от правильного нисходящего устройства.

    На основании 2 снимков можно сделать вывод, что:

    • Пакет из пяти кортежей (src / dst IP, src / dst порт, протокол) поступает на межсетевой экран на ожидаемом интерфейсе (INSIDE).
    • Пакет не покидает межсетевой экран на ожидаемом интерфейсе (ВНЕШНИЙ).
    Рекомендуемые действия

    Действия, перечисленные в этом разделе, направлены на дальнейшее сужение проблемы.

    Действие 1. Проверьте трассировку эмулируемого пакета.

    Используйте средство отслеживания пакетов, чтобы увидеть, как пакет должен обрабатываться межсетевым экраном. В случае, если пакет отбрасывается политикой доступа брандмауэра, трассировка эмулированного пакета выглядит примерно так:

     firepower #  вход для отслеживания пакетов INSIDE tcp 192.168.0.100 11111 10.10.1.100 80 
    
    Фаза 1
    Тип: ЗАХВАТ
    Подтип:
    Результат: РАЗРЕШИТЬ
    Конфиг:
    Дополнительная информация:
    Список доступа MAC
    
    Фаза 2
    Тип: СПИСОК ДОСТУПА
    Подтип:
    Результат: РАЗРЕШИТЬ
    Конфиг:
    Неявное правило
    Дополнительная информация:
    Список доступа MAC
    
    Фаза: 3
      Тип: МАРШРУТ-ПРОСМОТР
    Подтип: Resolve Egress Interface 
    Результат: РАЗРЕШИТЬ
    Конфиг:
    Дополнительная информация:
    найден следующий переход 192.168.2.72 с использованием исходящего сигнала  ifc OUTSIDE 
    
    Фаза: 4
      Тип: СПИСОК ДОСТУПА 
    Подтип: журнал
      Результат: DROP 
    Конфиг:
    группа доступа CSM_FW_ACL_ global
    список доступа CSM_FW_ACL_ расширенный запретить IP любой любой идентификатор правила 268439946 журнал событий начало потока
    список доступа CSM_FW_ACL_ идентификатор правила примечания 268439946: ПОЛИТИКА ДОСТУПА: FTD_Policy - По умолчанию
    список доступа CSM_FW_ACL_ идентификатор правила примечания 268439946: ПРАВИЛО L4: ПРАВИЛО ДЕЙСТВИЯ ПО УМОЛЧАНИЮ
    Дополнительная информация:
    
    Результат:
    интерфейс ввода: ВНУТРИ
    вход-статус: вверх
    вход-линия-статус: вверх
    выходной интерфейс: ВНЕШНИЙ
    статус вывода: вверх
    статус строки вывода: вверх
    Действие: падение
      Причина отбрасывания: (acl-drop) Поток запрещен настроенным правилом, Расположение отбрасывания: кадр 0x00005647a4f4b120 поток (NA) / NA
      

    Действие 2.Проверьте следы живых пакетов.

    Включите трассировку пакетов, чтобы проверить, как настоящие пакеты TCP SYN обрабатываются межсетевым экраном. По умолчанию отслеживаются только первые 50 входящих пакетов:

     огневая мощь #  захват трассировки CAPI  

    Очистить буфер захвата:

     огневая мощь #  четкий захват / все  


    В случае, если пакет отбрасывается политикой доступа брандмауэра, трассировка выглядит примерно так:

     firepower #  показать трассировку номера 1 пакета CAPI
     
    Захвачено 6 пакетов
    
       1: 12:45:36.279740 192.168.0.100.3630> 10.10.1.100.80: S 2322685377: 2322685377 (0) win 8192 
    Фаза 1
    Тип: ЗАХВАТ
    Подтип:
    Результат: РАЗРЕШИТЬ
    Конфиг:
    Дополнительная информация:
    Список доступа MAC
    
    Фаза 2
    Тип: СПИСОК ДОСТУПА
    Подтип:
    Результат: РАЗРЕШИТЬ
    Конфиг:
    Неявное правило
    Дополнительная информация:
    Список доступа MAC
    
    Фаза: 3
    Тип: МАРШРУТ-ПРОСМОТР
    Подтип: Разрешить исходящий интерфейс
    Результат: РАЗРЕШИТЬ
    Конфиг:
    Дополнительная информация:
    найден следующий переход 192.168.2.72 с использованием исходящего сигнала  ifc OUTSIDE 
    
    Фаза: 4
      Тип: СПИСОК ДОСТУПА 
    Подтип: журнал
      Результат: DROP 
    Конфиг:
    группа доступа CSM_FW_ACL_ global
    список доступа CSM_FW_ACL_ расширенный запретить IP любой любой идентификатор правила 268439946 журнал событий начало потока
    список доступа CSM_FW_ACL_ идентификатор правила примечания 268439946: ПОЛИТИКА ДОСТУПА: FTD_Policy - По умолчанию
    список доступа CSM_FW_ACL_ идентификатор правила примечания 268439946: ПРАВИЛО L4: ПРАВИЛО ДЕЙСТВИЯ ПО УМОЛЧАНИЮ
    Дополнительная информация:
    
    Результат:
    интерфейс ввода: ВНУТРИ
    вход-статус: вверх
    вход-линия-статус: вверх
    выходной интерфейс: ВНЕШНИЙ
    статус вывода: вверх
    статус строки вывода: вверх
    Действие: падение
      Причина отбрасывания: (acl-drop) Поток запрещен настроенным правилом, местоположение отбрасывания: кадр 0x00005647a4f4b120 поток (NA) / NA 
    
    Показан 1 пакет
     

    Действие 3.Проверьте логи FTD Lina.

    Чтобы настроить системный журнал на FTD через FMC, проверьте этот документ:

    https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/200479-Configure-Logging-on-FTD-via-FMC.html

    Настоятельно рекомендуется настроить внешний сервер системного журнала для журналов FTD Lina. Если удаленный сервер системного журнала не настроен, включите локальные буферные журналы на брандмауэре во время устранения неполадок. Конфигурация журнала, показанная в этом примере, является хорошей отправной точкой:

     firepower #  показ пробега 
    …
    ведение журнала включить
    отметка времени регистрации
    размер буфера регистрации 1000000
    логирование буферизованной информации
     


    Установите пейджер терминала на 24 линии для управления пейджером терминала:

     firepower #  терминальный пейджер 24  


    Очистить буфер захвата:

     firepower #  очистить буфер регистрации  

    Протестируйте соединение и проверьте логи с помощью фильтра синтаксического анализатора.В этом примере пакеты отбрасываются политикой доступа брандмауэра:

     огневая мощь № выставка лесозаготовок | включает 10.10.1.100 
    09 октября 2019 12:55:51:% FTD-4-106023: Запретить tcp src ВНУТРИ: 192.168.0.100/3696 dst ВНЕШНИЙ: 10.10.1.100/80 группой доступа "CSM_FW_ACL_" [0x97aa021a, 0x0]
    09 октября 2019 12:55:51:% FTD-4-106023: Запретить tcp src ВНУТРИ: 192.168.0.100/3697 dst ВНЕШНИЙ: 10.10.1.100/80 группой доступа "CSM_FW_ACL_" [0x97aa021a, 0x0]
    09 октября 2019 12:55:54:% FTD-4-106023: Запретить tcp src ВНУТРИ: 192.168.0.100 / 3696 dst ВНЕШНИЙ: 10.10.1.100/80 по группе доступа "CSM_FW_ACL_" [0x97aa021a, 0x0]
    09 октября 2019 12:55:54:% FTD-4-106023: Запретить tcp src ВНУТРИ: 192.168.0.100/3697 dst ВНЕШНИЙ: 10.10.1.100/80 группой доступа "CSM_FW_ACL_" [0x97aa021a, 0x0]
     

    Действие 4. Проверьте, что ASP брандмауэра отбрасывается.

    Если вы подозреваете, что пакет отброшен брандмауэром, вы можете увидеть счетчики всех пакетов, отброшенных брандмауэром на программном уровне:

     firepower #  показать asp drop 
    
    Падение кадра:
      Нет маршрута к хосту (нет маршрута) 234
      Поток запрещен настроенным правилом (acl-drop) 71
    
    Последняя очистка: 07:51:52 UTC, 10 октября 2019 г., enable_15
    
    Падение потока:
    
    Последняя очистка: 07:51:52 UTC, 10 октября 2019 г., enable_15
     

    Вы можете включить записи, чтобы увидеть все сбросы на уровне программного обеспечения ASP:

     firepower #  захват типа ASP asp-drop all buffer 33554432 только заголовки  

    Совет : Если вас не интересует содержимое пакета, вы можете захватить только заголовки пакета (опция только заголовков).Это позволяет захватывать гораздо больше пакетов в буфер захвата. Кроме того, вы можете увеличить размер буфера захвата (по умолчанию 500 Кбайт) до 32 Мбайт (опция буфера). Наконец, начиная с FTD версии 6.3, опция размера файла позволяет вам конфигурировать файл захвата размером до 10 ГБ. В этом случае вы можете видеть только захваченное содержимое в формате pcap.

    Чтобы проверить содержимое захвата, вы можете использовать фильтр, чтобы сузить область поиска:

     огневой мощи #  показать захват ASP | включить 10.10.1.100 
      18: 07: 51: 57.823672 192.168.0.100.12410> 10.10.1.100.80: S 1870382552: 1870382552 (0) win 8192 
      19: 07: 51: 58.074291 192.168.0.100.12411> 10.10.1.100.80: S 2006489005: 2006489005 (0) win 8192 
      26: 07: 52: 00.830370 192.168.0.100.12410> 10.10.1.100.80: S 1870382552: 1870382552 (0) win 8192 
      29: 07: 52: 01.080394 192.168.0.100.12411> 10.10.1.100.80: S 2006489005: 2006489005 (0) win 8192 
      45: 07: 52: 06.824282 192.168.0.100.12410> 10.10.1.100.80: S 1870382552: 1870382552 (0) win 8192 
      46: 07: 52: 07.074230 192.168.0.100.12411> 10.10.1.100.80: S 2006489005: 2006489005 (0) win 8192 
     

    В этом случае, поскольку пакеты уже отслеживаются на уровне интерфейса, причина отбрасывания не упоминается в захвате ASP.Помните, что пакет можно отследить только в одном месте (входящий интерфейс или отбрасывание ASP). В этом случае рекомендуется выполнить несколько сбросов ASP и установить конкретную причину сброса ASP. Вот рекомендуемый подход:

    1. Очистить текущие счетчики сбросов ASP:

     огневая мощь #  чистая гадюка  

    2. Отправьте поток, который вы устраняете, через брандмауэр (запустите тест).

    3. Еще раз проверьте счетчики падений ASP и отметьте увеличившиеся, например.грамм.

     firepower #  показать asp drop 
    Падение кадра:
      Нет маршрута к хосту ( нет маршрута ) 234
      Поток запрещен настроенным правилом ( acl-drop ) 71
     


    4. Включите захват ASP для определенных видимых отбрасываний:

     огневая мощь #  захват ASP_NO_ROUTE тип asp-drop no-route 
    firepower #  захват ASP_ACL_DROP тип asp-drop acl-drop
      

    5.Отправьте поток, который вы устраняете, через брандмауэр (запустите тест).

    6. Проверьте записи ASP. В этом случае пакеты были отброшены из-за отсутствия маршрута:

     огневая мощь #  показать захват ASP_NO_ROUTE | включают 192.168.0.100. * 10.10.1.100 
      93: 07: 53: 52.381663 192.168.0.100.12417> 10.10.1.100.80: S 34515: 34515 (0) win 8192 
      95: 07: 53: 52.632337 192.168.0.100.12418> 10.10.1.100.80: S 16

    448: 16

    448 (0) win 8192 101: 07:53:55.375392 192.168.0.100.12417> 10.10.1.100.80: S 34515: 34515 (0) win 8192 102: 07: 53: 55.626386 192.168.0.100.12418> 10.10.1.100.80: S 16

    448: 16

    448 (0) win 8192 116: 07: 54: 01.376231 192.168.0.100.12417> 10.10.1.100.80: S 34515: 34515 (0) выигрыш 8192 117: 07: 54: 01.626310 192.168.0.100.12418> 10.10.1.100.80: S 16

    448: 16

    448 (0) win 8192

    Действие 5.Проверьте таблицу соединений FTD Lina.

    Могут быть случаи, когда вы ожидаете, что пакет будет исходить через интерфейс «X», но по каким-либо причинам он выходит из интерфейса «Y». Определение выходного интерфейса межсетевого экрана основано на следующем порядке операций:

    1. Поиск установленного соединения
    2. Поиск трансляции сетевых адресов (NAT) - этап UN-NAT (NAT назначения) имеет приоритет над PBR и поиском маршрута.
    3. Маршрутизация на основе политик (PBR)
    4. Поиск в таблице маршрутизации

    Для проверки таблицы соединений FTD:

     firepower #  показать conn 
    2 используются, 4 наиболее часто используются
    Осмотрите Snort:
            preserve-connection: 2 включено, 0 активно, 4 наиболее активно, 0 наиболее активно
    
    TCP  DMZ  10.10.1.100:  80   INSIDE  192.168.0.100:  11694 , бездействие 0:00:01, 0 байтов, флаги  aA N1 
    TCP  DMZ  10.10.1.100:80  INSIDE  192.168.0.100:  11693 , ожидание 0:00:01, байты 0, флаги  aA N1
      

    Ключевые точки:

    • На основании флагов (Aa) соединение находится в зачаточном состоянии (полуоткрытое - межсетевой экран видел только TCP SYN).
    • На основе портов источника / назначения входной интерфейс - ВНУТРЕННИЙ, а выходной интерфейс - DMZ.

    Это можно визуализировать на изображении здесь:

    Примечание : Поскольку все интерфейсы FTD имеют уровень безопасности 0, порядок интерфейсов в выводе show conn основан на номере интерфейса. В частности, интерфейс с более высоким vpif-num (номер интерфейса виртуальной платформы) выбирается как внутренний, а интерфейс с меньшим vpif-num выбирается как внешний. Вы можете увидеть значение vpif интерфейса с помощью команды show interface detail .Связанное усовершенствование, CSCvi15290 ENH: FTD должен показывать направленность соединения в выходных данных FTD 'show conn'

     огневая мощь №  показать детали интерфейса | i Номер интерфейса | Интерфейс [P | E]. * is up 
    ...
    Интерфейс Ethernet1 / 2 "INSIDE", включен, протокол линии включен
            Номер интерфейса  19 
    Интерфейс Ethernet1 / 3.202 "OUTSIDE", включен, протокол линии включен
            Номер интерфейса  20 
    Интерфейс Ethernet1 / 3.203 "DMZ", включен, протокол линии включен
            Номер интерфейса  22  

    Примечание : Начиная с версии программного обеспечения Firepower 6.5, выпуск 9.13.x ASA, выходные данные команд show conn long и show conn detail предоставляют информацию об инициаторе соединения и ответчике

    Выход 1:

     firepower #  показать conn long 
    ...
    TCP ВНЕШНИЙ: 192.168.2.200/80 (192.168.2.200/80) ВНУТРИ: 192.168.1.100/46050 (192.168.1.100/46050), флаги aA N1, простоя 3 секунды, время безотказной работы 6 секунд, таймаут 30 секунд, байты 0
        Инициатор: 192.168.1.100, Ответчик: 192.168.2.200 
      Идентификатор ключа поиска подключения: 228982375 

    Выход 2:

     firepower #  показать деталь коннектора 
    ...
    TCP ВНЕШНИЙ: 192.168.2.200/80 ВНУТРИ: 192.168.1.100/46050,
        флаги aA N1, простоя 4 с, время безотказной работы 11 с, тайм-аут 30 с, байты 0
        Инициатор: 192.168.1.100, Ответчик: 192.168.2.200 
      Идентификатор ключа поиска подключения: 228982375 

    Кроме того, show conn long отображает IP-адреса с NAT в круглых скобках в случае преобразования сетевых адресов:

     firepower #  показать conn long 
    ...
    TCP ВНЕШНИЙ: 192.168.2.222/80 (192.168.2.222/80) ВНУТРИ: 192.168.1.100/34792 ( 192.168.2.150 /34792), флаги aA N1, idle 0s, uptime 0s, timeout 30s, bytes 0, xlate id 0x2b5a8a4314c0
      Инициатор: 192.168.1.100, Ответчик: 192.168.2.222
      Идентификатор ключа поиска соединения: 262895
     

    Действие 6. Проверьте кэш протокола разрешения адресов (ARP) межсетевого экрана.

    Если брандмауэр не может разрешить следующий переход, брандмауэр молча отбрасывает исходный пакет (в данном случае TCP SYN) и непрерывно отправляет запросы ARP, пока не разрешит следующий переход.

    Чтобы увидеть кеш ARP брандмауэра, используйте команду:

     firepower #  показать arp  

    Дополнительно, чтобы проверить наличие неразрешенных хостов, вы можете использовать команду:

     firepower #  показать статистику arp 
            Количество записей ARP в ASA: 0
    
            Выпало блоков в ARP: 84
            Максимальное количество блоков в очереди: 3
            Блоки в очереди: 0
            Получено ARP-сообщений о конфликте интерфейсов: 0
            ARP-защита Отправлено бесплатных ARPS: 0
            Общее количество попыток ARP:  182 <указывает на возможную проблему для некоторых хостов 
            Неразрешенные хосты:  1   <это текущий статус 
            Максимальное количество неразрешенных хостов: 2
     

    Если вы хотите дополнительно проверить работу ARP, вы можете включить захват, специфичный для ARP:

     firepower #  захват ARP интерфейс ARP Ethernet-типа ВНЕ 
    огневая мощь #  показать захват ARP 
    ...
       4: 07: 15: 16.877914 802.1Q vlan # 202 P0 arp  у кого есть 192.168.2.72 сказать 192.168.2.50 
       5: 07: 15: 18.020033 802.1Q vlan # 202 P0 arp у кого есть 192.168.2.72 сказать 192.168.2.50
     

    В этих выходных данных межсетевой экран (192.168.2.50) пытается разрешить следующий переход (192.168.2.72), но нет ответа ARP

    Выходные данные здесь показывают функциональный сценарий с правильным разрешением ARP:

     огневой мощи #  показать захват ARP 
    
    2 пакета захвачены
    
       1: 07:17:19.495595 802.1Q vlan # 202 P0  arp у кого есть 192.168.2.72 скажите 192.168.2.50 
       2: 07: 17: 19.495946 802.1Q vlan # 202 P0  ответ arp 192.168.2.72 is-at 4c: 4e: 35: fc: fc: d8 
    Показано 2 пакета
     
     firepower #  показать arp 
            ВНУТРИ 192.168.1.71 4c4e.35fc.fcd8 9
            ВНЕШНИЙ 192.168.2.72 4c4e.35fc.fcd8 9
     

    В случае, если запись ARP отсутствует, трассировка активного пакета TCP SYN показывает:

     firepower #  показать трассировку номера пакета CAPI 1 
    
    Захвачено 6 пакетов
    
       1: 07:03:43.270585  192.168.0.100.11997> 10.10.1.100.80 : S 4023707145: 4023707145 (0) win 8192 
    Фаза 1
    Тип: ЗАХВАТ
    Подтип:
    Результат: РАЗРЕШИТЬ
    Конфиг:
    Дополнительная информация:
    Список доступа MAC
    
    Фаза 2
    Тип: СПИСОК ДОСТУПА
    Подтип:
    Результат: РАЗРЕШИТЬ
    Конфиг:
    Неявное правило
    Дополнительная информация:
    Список доступа MAC
    
    Фаза: 3
      Тип: МАРШРУТ-ПРОСМОТР 
    Подтип: Разрешить исходящий интерфейс
    Результат: РАЗРЕШИТЬ
    Конфиг:
    Дополнительная информация:
      найден следующий переход 192.168.2.72 с использованием egress ifc OUTSIDE 
    …
    Фаза: 14
    Тип: ПОТОК-СОЗДАНИЕ
    Подтип:
    Результат: РАЗРЕШИТЬ
    Конфиг:
    Дополнительная информация:
    Новый поток создан с идентификатором 4814, пакет отправлен следующему модулю
    …
    Фаза: 17
    Тип: МАРШРУТ-ПРОСМОТР
    Подтип: Разрешить исходящий интерфейс
    Результат: РАЗРЕШИТЬ
    Конфиг:
    Дополнительная информация:
      обнаружил следующий переход 192.168.2.72 с использованием исходящего ifc OUTSIDE 
    
    Результат:
      интерфейс ввода: INSIDE 
    вход-статус: вверх
    вход-линия-статус: вверх
      выходной интерфейс: ВНЕШНИЙ 
    статус вывода: вверх
    статус строки вывода: вверх
      Действие: разрешить
      

    Как видно из выходных данных, трассировка показывает действие : разрешить , даже если следующий прыжок недоступен и пакет автоматически отбрасывается брандмауэром! В этом случае необходимо также проверить средство отслеживания пакетов, поскольку оно обеспечивает более точный вывод:

     firepower #  вход для отслеживания пакетов INSIDE tcp 192.168.0.100 1111 10.10.1.100 80
     
    Фаза 1
    Тип: ЗАХВАТ
    Подтип:
    Результат: РАЗРЕШИТЬ
    Конфиг:
    Дополнительная информация:
    Список доступа MAC
    
    Фаза 2
    Тип: СПИСОК ДОСТУПА
    Подтип:
    Результат: РАЗРЕШИТЬ
    Конфиг:
    Неявное правило
    Дополнительная информация:
    Список доступа MAC
    
    Фаза: 3
    Тип: МАРШРУТ-ПРОСМОТР
    Подтип: Разрешить исходящий интерфейс
    Результат: РАЗРЕШИТЬ
    Конфиг:
    Дополнительная информация:
    найден следующий переход 192.168.2.72 с использованием egress ifc OUTSIDE
    …
    
    Фаза: 14
    Тип: ПОТОК-СОЗДАНИЕ
    Подтип:
    Результат: РАЗРЕШИТЬ
    Конфиг:
    Дополнительная информация:
    Новый поток создан с идентификатором 4816, пакет отправлен следующему модулю
    …
    Фаза: 17
    Тип: МАРШРУТ-ПРОСМОТР
    Подтип: Разрешить исходящий интерфейс
    Результат: РАЗРЕШИТЬ
    Конфиг:
    Дополнительная информация:
    найден следующий переход 192.168.2.72 с использованием egress ifc OUTSIDE
    
    Результат:
    интерфейс ввода: ВНУТРИ
    вход-статус: вверх
    вход-линия-статус: вверх
    выходной интерфейс: ВНЕШНИЙ
    статус вывода: вверх
    статус строки вывода: вверх
    Действие: падение
      Причина отбрасывания: (no-v4-смежность) Нет допустимой смежности V4, Расположение отбрасывания: кадр 0x00005647a4e86109 поток (NA) / NA
      

    В последних версиях ASA / Firepower указанное выше сообщение было оптимизировано до:

     Причина отбрасывания: (no-v4-смежность) Нет допустимой смежности V4.  Проверить таблицу ARP (показать arp) имеет запись для nexthop ., Место сброса: f 
    Сводка возможных причин и рекомендуемых действий

    Если вы видите только пакет TCP SYN на входных интерфейсах, но не пакет TCP SYN, отправленный из ожидаемого выходного интерфейса, возможны следующие причины:

    Возможная причина

    Рекомендуемые действия

    Пакет отброшен политикой доступа межсетевого экрана.

    • Используйте трассировщик пакетов или захват с трассировкой , чтобы увидеть, как межсетевой экран обрабатывает пакет.
    • Проверьте журналы брандмауэра.
    • Проверьте, что брандмауэр отбрасывает ASP (покажите asp drop или захват типа asp-drop).
    • Проверьте события подключения FMC. Это предполагает, что для правила включено ведение журнала.

    Неправильный фильтр захвата.

    • Используйте трассировщик пакетов или захват с трассировкой , чтобы увидеть, есть ли трансляция NAT, которая изменяет исходный или целевой IP.В этом случае настройте фильтр захвата.
    • В выходных данных команды show conn long показаны IP-адреса с NAT.

    Пакет отправлен на другой выходной интерфейс.

    • Используйте трассировщик пакетов или захват с трассировкой , чтобы увидеть, как межсетевой экран обрабатывает пакет. Помните порядок операций, касающихся определения выходного интерфейса, существующего соединения, UN-NAT, PBR и поиска в таблице маршрутизации.
    • Проверьте журналы брандмауэра.
    • Проверьте таблицу соединений межсетевого экрана ( show conn ).

    Если пакет отправлен на неправильный интерфейс, потому что он соответствует существующему соединению, используйте команду clear conn address и укажите 5-кортеж соединения, которое вы хотите очистить.

    Нет маршрута к пункту назначения.

    • Используйте трассировщик пакетов или захват с трассировкой , чтобы увидеть, как межсетевой экран обрабатывает пакет.
    • Проверьте, что брандмауэр отбрасывает ASP (показать asp drop) на предмет no-route drop cause.

    Нет записи ARP на исходящем интерфейсе.

    • Проверьте кэш ARP брандмауэра ( show arp ).
    • Используйте трассировщик пакетов , чтобы проверить, есть ли допустимая смежность.

    Выходной интерфейс не работает.

    Проверьте выходные данные команды show interface iprief на брандмауэре и проверьте состояние интерфейса.

    Случай 2. TCP SYN от клиента, TCP RST от сервера

    На этом изображении показана топология:

    Описание проблемы: HTTP не работает

    Затрагиваемый поток:

    Src IP: 192.168.0.100

    Dst IP: 10.10.1.100

    Протокол: TCP 80

    Анализ захвата

    Включить захват на движке FTD LINA.

     firepower #  захват CAPI int INSIDE match ip host 192.168.0.100 хост 10.10.1.100 
    firepower #  захват CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100
      

    Захваты - нефункциональный сценарий:

    Из интерфейса командной строки устройства снимки выглядят следующим образом:

     огневая мощь #  показать захват 
    захват интерфейса трассировки необработанных данных типа CAPI ВНУТРИ [захват -  834 байта ]
      сопоставить IP-хост 192.168.0.100 хост 10.10.1.100
    захват интерфейса необработанных данных типа CAPO ВНЕШНИЙ [захват -  878 байт ]
      сопоставьте ip host 192.168.0.100 хост 10.10.1.100
     

    Содержание CAPI:

     огневой мощи #  показать захват CAPI 
       1: 05: 20: 36.654217 192.168.0.100.22195> 10.10.1.100.80:  S  1397289928: 1397289928 (0) win 8192 
       2: 05: 20: 36.

    1 192.168.0.100.22196> 10.10.1.100.80: S 2171673258: 2171673258 (0) win 8192 3: 05: 20: 36.3 10.10.1.100.80> 192.168.0.100.22196: R 1850052503: 1850052503 (0) ack 2171673259 win 0 4: 05:20:37.414132 192.168.0.100.22196> 10.10.1.100.80: S 2171673258: 2171673258 (0) win 8192 5: 05: 20: 37.414803 10.10.1.100.80> 192.168.0.100.22196: R 31997177: 31997177 (0) ack 2171673259 win 0 6: 05: 20: 37.

    3 192.168.0.100.22196> 10.10.1.100.80: S 2171673258: 2171673258 (0) win 8192 ...

    Состав CAPO:

     огневая мощь #  показать захват CAPO 
       1: 05:20:36.654507 802.1Q vlan # 202 P0 192.168.0.100.22195> 10.10.1.100.80:  S  2866789268: 2866789268 (0) win 8192 
       2: 05: 20: 36.8 802.1Q vlan # 202 P0 192.168.0.100.22196> 10.10.1.100.80:  S  4785344: 4785344 (0) win 8192 
       3: 05: 20: 36.7 802.1Q vlan # 202 P0 10.10.1.100.80> 192.168.0.100.22196:  R  0: 0 (0) ack 4785345 win 0
       4: 05: 20: 37.414269 802.1Q vlan # 202 P0 192.168.0.100.22196> 10.10.1.100.80:  S  4235354730: 4235354730 (0) win 8192 
       5: 05: 20: 37.414758 802.1Q vlan # 202 P0 10.10.1.100.80> 192.168.0.100.22196:  R  0: 0 (0) ack 4235354731 win 0
       6: 05: 20: 37.

    5 802.1Q vlan # 202 P0 192.168.0.100.22196> 10.10.1.100.80: S 4118617832: 4118617832 (0) win 8192

    На этом изображении показан захват CAPI в Wireshark.

    Ключевые точки:

    1. Источник отправляет пакет TCP SYN.
    2. Источнику отправляется TCP RST.
    3. Источник повторно передает пакеты TCP SYN.
    4. MAC-адреса верны (для входящих пакетов MAC-адрес источника принадлежит нисходящему маршрутизатору, MAC-адрес назначения принадлежит интерфейсу INSIDE межсетевого экрана).

    На этом изображении показан захват CAPO в Wireshark:

    Ключевые точки:

    1. Источник отправляет пакет TCP SYN.
    2. TCP RST поступает на ВНЕШНИЙ интерфейс.
    3. Источник повторно передает пакеты TCP SYN.
    4. MAC-адреса верны (на исходящих пакетах брандмауэр OUTSIDE является MAC-адресом источника, восходящий маршрутизатор является MAC-адресом назначения).

    На основании 2 снимков можно сделать вывод, что:

    • Трехстороннее установление связи TCP между клиентом и сервером не завершено
    • Имеется TCP RST, который поступает на выходной интерфейс межсетевого экрана
    • Межсетевой экран «разговаривает» с соответствующими устройствами восходящего и нисходящего потоков (на основе MAC-адресов)
    Рекомендуемые действия

    Действия, перечисленные в этом разделе, направлены на дальнейшее сужение проблемы.

    Действие 1. Проверьте исходный MAC-адрес, который отправляет TCP RST.

    Убедитесь, что MAC-адрес назначения в пакете TCP SYN совпадает с MAC-адресом источника в пакете TCP RST.

    Эта проверка имеет целью подтвердить 2 вещи:

    • Убедитесь, что нет асимметричного потока.
    • Убедитесь, что MAC принадлежит ожидаемому восходящему устройству.

    Действие 2. Сравните входящие и исходящие пакеты.

    Визуально сравните 2 пакета в Wireshark, чтобы убедиться, что брандмауэр не изменяет / не повреждает пакеты.Выделены некоторые ожидаемые различия.

    Ключевые точки:

    1. Отметки времени разные. С другой стороны, разница должна быть небольшой и разумной. Это зависит от функций и проверок политики, применяемых к пакету, а также от нагрузки на устройство.
    2. Длина пакетов может отличаться, особенно если брандмауэр добавляет / удаляет заголовок dot1Q только с одной стороны.
    3. MAC-адреса разные.
    4. Заголовок dot1Q может быть на месте, если захват был сделан на подинтерфейсе.
    5. IP-адрес (а) различаются, если к пакету применяется NAT или преобразование адресов порта (PAT).
    6. Порты источника и назначения различаются в случае, если к пакету применяется NAT или PAT.
    7. Если вы отключите параметр Wireshark Relative Sequence Number , вы увидите, что порядковые номера TCP / номера подтверждения изменяются брандмауэром из-за рандомизации начального порядкового номера (ISN).
    8. Некоторые параметры TCP могут быть перезаписаны.Например, межсетевой экран по умолчанию изменяет максимальный размер сегмента TCP (MSS) на 1380, чтобы избежать фрагментации пакетов на пути передачи.

    Действие 3. Сделайте снимок в пункте назначения.

    Если возможно, сделайте снимок в самом пункте назначения. Если это невозможно, сделайте снимок как можно ближе к месту назначения. Цель здесь - проверить, кто отправляет TCP RST (целевой сервер или какое-то другое устройство на пути?).

    Кейс 3.Трехстороннее установление связи TCP + RST от одной конечной точки

    На этом изображении показана топология:

    Описание проблемы: HTTP не работает

    Затрагиваемый поток:

    Src IP: 192.168.0.100

    Dst IP: 10.10.1.100

    Протокол: TCP 80

    Анализ захвата

    Включить захват на движке FTD LINA.

     firepower #  захват CAPI int INSIDE соответствует IP-хосту 192.168.0.100 хосту 10.10.1.100
      firepower #  захват CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100
      

    Захваты - нефункциональный сценарий:

    Эта проблема может проявляться в захватах несколькими способами.

    3.1 - Трехстороннее установление связи TCP + отложенный RST от клиента

    Оба брандмауэра перехватывают CAPI и CAPO содержат одни и те же пакеты, как показано на изображении.

    Ключевые точки:

    1. Трехстороннее подтверждение TCP проходит через брандмауэр.
    2. Сервер повторно передает SYN / ACK.
    3. Клиент повторно передает ACK.
    4. Через ~ 20 секунд клиент отказывается и отправляет TCP RST.
    Рекомендуемые действия

    Действия, перечисленные в этом разделе, направлены на дальнейшее сужение проблемы.

    Действие 1. Сделайте захваты как можно ближе к двум конечным точкам.

    Записи брандмауэра показывают, что клиентский ACK не был обработан сервером. Это основано на следующих фактах:

    • Сервер повторно передает SYN / ACK.
    • Клиент повторно передает ACK.
    • Клиент отправляет TCP RST или FIN / ACK перед любыми данными.

    Захват на сервере показывает проблему. Клиентский ACK из трехстороннего установления связи TCP так и не поступил:

    3.2 - Трехстороннее квитирование TCP + отложенный FIN / ACK от клиента + отложенный RST от сервера

    Оба брандмауэра перехватывают CAPI и CAPO содержат одни и те же пакеты, как показано на изображении.

    Ключевые точки:

    1. Трехстороннее подтверждение TCP проходит через брандмауэр.
    2. Через ~ 5 секунд клиент отправляет FIN / ACK.
    3. Через ~ 20 секунд сервер отказывается и отправляет TCP RST.

    На основании этого захвата можно сделать вывод, что, несмотря на трехстороннее квитирование TCP через брандмауэр, кажется, что оно никогда не завершается на одной конечной точке (повторные передачи указывают на это).

    Рекомендуемые действия

    То же, что и в случае 3.1

    3.3 - Трехстороннее квитирование TCP + отложенный RST от клиента

    Оба брандмауэра перехватывают CAPI и CAPO содержат одни и те же пакеты, как показано на изображении.

    Ключевые точки:

    1. Трехстороннее подтверждение TCP проходит через брандмауэр.
    2. Через ~ 20 секунд клиент отказывается и отправляет TCP RST.

    На основании этих снимков можно сделать вывод, что:

    • Через 5-20 секунд одна конечная точка отказывается и решает разорвать соединение.
    Рекомендуемые действия

    То же, что и в случае 3.1

    3.4 - Трехстороннее установление связи TCP + немедленное RST с сервера

    Оба брандмауэра перехватывают CAPI и CAPO содержат эти пакеты, как показано на изображении.

    Ключевые точки:

    1. Трехстороннее подтверждение TCP проходит через брандмауэр.
    2. Через несколько миллисекунд после пакета ACK от сервера идет TCP RST.
    Рекомендуемые действия

    Действие: Делайте снимки как можно ближе к серверу.

    Немедленное TCP RST от сервера может указывать на неисправный сервер или устройство на пути, которое отправляет TCP RST. Сделайте снимок на самом сервере и определите источник TCP RST.

    Случай 4. TCP RST от клиента

    На этом изображении показана топология:

    Описание проблемы: HTTP не работает.

    Затрагиваемый поток:

    Src IP: 192.168.0.100

    Dst IP: 10.10.1.100

    Протокол: TCP 80

    Анализ захвата

    Включить захват на движке FTD LINA.

     firepower #  захват CAPI int INSIDE соответствует IP-хосту 192.168.0.100 хосту 10.10.1.100 
    firepower #  захват CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100
      

    Захваты - нефункциональный сценарий:

    Это содержимое CAPI.

     огневой мощи #  показать захват CAPI 
    
    14 пакетов захвачено
    
       1: 12: 32: 22.860627 192.168.0.100.47078> 10.10.1.100.80: S 4098574664: 4098574664 (0) win 8192 
       2: 12: 32: 23.111307 192.168.0.100.47079> 10.10.1.100.80: S 2486

    1: 2486

    1 (0) win 8192 3: 12: 32: 23.112390 192.168.0.100.47079> 10.10.1.100.80: 3000518858 рэнд: 3000518858 (0) выигрыш 0 4: 12: 32: 25.858109 192.168.0.100.47078> 10.10.1.100.80: S 4098574664: 4098574664 (0) win 8192 5: 12: 32: 25.868698 192.168.0.100.47078> 10.10.1.100.80: 1386249853 рэнд: 1386249853 (0) выигрыш 0 6: 12: 32: 26.108118 192.168.0.100.47079> 10.10.1.100.80: S 2486

    1: 2486

    1 (0) win 8192 7: 12:32:26.109079 192.168.0.100.47079> 10.10.1.100.80: 3000518858 рэндов: 3000518858 (0) выигрыш 0 8: 12: 32: 26.118295 192.168.0.100.47079> 10.10.1.100.80: 3000518858 рэнд: 3000518858 (0) выигрыш 0 9: 12: 32: 31.859925 192.168.0.100.47078> 10.10.1.100.80: S 4098574664: 4098574664 (0) win 8192 10: 12: 32: 31.860902 192.168.0.100.47078> 10.10.1.100.80: 1386249853 рэнд: 1386249853 (0) выигрыш 0 11: 12: 32: 31.875229 192.168.0.100.47078> 10.10.1.100.80: 1386249853 рэнд: 1386249853 (0) выигрыш 0 12: 12:32:32.140632 192.168.0.100.47079> 10.10.1.100.80: 3000518858 рэнд: 3000518858 (0) выигрыш 0 13: 12: 32: 32.159995 192.168.0.100.47079> 10.10.1.100.80: S 2486

    1: 2486

    1 (0) win 8192 14: 12: 32: 32.160956 192.168.0.100.47079> 10.10.1.100.80: 3000518858 рэнд: 3000518858 (0) выигрыш 0 Показано 14 пакетов

    Это содержимое CAPO:

     огневая мощь #  показать захват CAPO 
    
    Захвачено 11 пакетов
    
       1: 12: 32: 22.860780 802.1Q vlan # 202 P0 192.168.0.100.47078> 10.10.1.100.80: S 1386249852: 1386249852 (0) win 8192 
       2: 12: 32: 23.111429 802.1Q vlan # 202 P0 192.168.0.100.47079> 10.10.1.100.80: S 3000518857: 3000518857 (0) win 8192 
       3: 12: 32: 23.112405 802.1Q vlan # 202 P0 192.168.0.100.47079> 10.10.1.100.80: R 35140

    : 35140

    (0) выигрыш 0 4: 12: 32: 25.858125 802.1Q vlan # 202 P0 192.168.0.100.47078> 10.10.1.100.80: S 1386249852: 1386249852 (0) win 8192 5: 12:32:25.868729 802.1Q vlan # 202 P0 192.168.0.100.47078> 10.10.1.100.80: R 29688: 29688 (0) выигрыш 0 6: 12: 32: 26.108240 802.1Q vlan # 202 P0 192.168.0.100.47079> 10.10.1.100.80: S 3822259745: 3822259745 (0) win 8192 7: 12: 32: 26.109094 802.1Q vlan # 202 P0 192.168.0.100.47079> 10.10.1.100.80: R 40865466: 40865466 (0) выигрыш 0 8: 12: 32: 31.860062 802.1Q vlan # 202 P0 192.168.0.100.47078> 10.10.1.100.80: S 42

    752: 42
    752 (0) win 8192 9: 12:32:31.860917 802.1Q vlan # 202 P0 192.168.0.100.47078> 10.10.1.100.80: R 1581733941: 1581733941 (0) выигрыш 0 10: 12: 32: 32.160102 802.1Q vlan # 202 P0 192.168.0.100.47079> 10.10.1.100.80: S 4284301197: 4284301197 (0) win 8192 11: 12: 32: 32.160971 802.1Q vlan # 202 P0 192.168.0.100.47079> 10.10.1.100.80: R 502

    8: 502

    8 (0) выигрыш 0 Показано 11 пакетов

    Журналы брандмауэра показывают:

     огневая мощь №  журнал событий | я 47741 
    13 октября 2019 13:57:36:% FTD-6-302013: Построено входящее TCP-соединение 4869 для INSIDE: 192.168.0.100 / 47741 (192.168.0.100/47741) ВНЕШНИЙ: 10.10.1.100/80 (10.10.1.100/80)
    13 октября 2019 13:57:36:% FTD-6-302014: Разрыв TCP-соединения 4869 для ВНУТРИ: 192.168.0.100/47741 на ВНЕШНИЙ: 10.10.1.100/80 продолжительность 0:00:00 байт 0  TCP Reset-O от ВНУТРИ 
    13 октября 2019 13:57:39:% FTD-6-302013: Построено входящее TCP-соединение 4870 для INSIDE: 192.168.0.100/47741 (192.168.0.100/47741) для OUTSIDE: 10.10.1.100/80 (10.10.1.100/80) )
    13 октября 2019 13:57:39:% FTD-6-302014: Разрыв TCP-соединения 4870 для INSIDE: 192.168.0.100 / 47741 к ВНЕШНЕМУ: 10.10.1.100/80 длительность 0:00:00 байт 0  Сброс TCP-O из ВНУТРИ 
    13 октября 2019 13:57:45:% FTD-6-302013: Построено входящее TCP-соединение 4871 для ВНУТРИ: 192.168.0.100/47741 (192.168.0.100/47741) для ВНЕШНЕГО: 10.10.1.100/80 (10.10.1.100/80) )
    13 октября 2019 13:57:45:% FTD-6-302014: Разрыв TCP-соединения 4871 для ВНУТРИ: 192.168.0.100/47741 для ВНЕШНЕГО: 10.10.1.100/80 продолжительность 0:00:00 байт 0 TCP Reset-O из ВНУТРИ
     

    Эти журналы указывают на наличие TCP RST, поступающего на ВНУТРЕННИЙ интерфейс межсетевого экрана.

    Захват CAPI в Wireshark:

    Следуйте первому потоку TCP, как показано на изображении.

    В Wireshark перейдите к Edit> Preferences> Protocols> TCP и отмените выбор параметра Relative sequence numbers , как показано на изображении.

    На этом изображении показано содержимое первого потока в захвате CAPI:

    Ключевые точки:

    1. Клиент отправляет пакет TCP SYN.
    2. Клиент отправляет пакет TCP RST.
    3. Пакет TCP SYN имеет значение порядкового номера, равное 4098574664.

    Тот же поток в захвате CAPO содержит:

    Ключевые точки:

    1. Клиент отправляет пакет TCP SYN. Брандмауэр рандомизирует ISN.
    2. Клиент отправляет пакет TCP RST.

    На основании двух отловов можно сделать вывод, что:

    • Нет трехстороннего установления связи TCP между клиентом и сервером.
    • Существует TCP RST, который исходит от клиента. Значение порядкового номера TCP RST в захвате CAPI - 1386249853.
    Рекомендуемые действия

    Действия, перечисленные в этом разделе, направлены на дальнейшее сужение проблемы.

    Действие 1. Сделайте снимок на клиенте.

    На основе захватов, собранных на межсетевом экране, есть явное указание на асимметричный поток. Это основано на том факте, что клиент отправляет TCP RST со значением 1386249853 (рандомизированный ISN):

    Ключевые точки:

    1. Клиент отправляет пакет TCP SYN.Порядковый номер 4098574664 и такой же, как на ВНУТРЕННЕМ интерфейсе межсетевого экрана (CAPI)
    2. .
    3. Имеется TCP SYN / ACK с номером ACK 1386249853 (что ожидается из-за рандомизации ISN). Этот пакет не был замечен в захватах брандмауэра
    4. Клиент отправляет TCP RST, поскольку он ожидал SYN / ACK со значением номера ACK 4098574665, но получил значение 1386249853

    Это можно представить как:

    Действие 2. Проверьте маршрутизацию между клиентом и межсетевым экраном.

    Подтвердите, что:

    • MAC-адреса, отображаемые в захватах, являются ожидаемыми.
    • Убедитесь, что маршрутизация между межсетевым экраном и клиентом симметрична.

    Существуют сценарии, в которых RST исходит от устройства, которое находится между брандмауэром и клиентом, в то время как во внутренней сети существует асимметричная маршрутизация. Типичный случай показан на изображении:

    В этом случае захват имеет это содержимое. Обратите внимание на разницу между MAC-адресом источника пакета TCP SYN и MAC-адресом источника TCP RST и MAC-адресом назначения пакета TCP SYN / ACK:

     огневой мощи #  показать захват CAPI деталь 
       1: 13:57:36.730217  4c4e.35fc.fcd8  00be.75f6.1dae 0x0800 Длина: 66
          192.168.0.100.47740> 10.10.1.100.80: S [tcp sum ok] 3045001876: 3045001876 (0) win 8192  (DF) (ttl 127, id 25661 )
       2: 13: 57: 36.981104 4c4e.35fc.fcd8 00be.75f6.1dae 0x0800 Длина: 66
          192.168.0.100.47741> 10.10.1.100.80: S [tcp sum ok] 380
    40: 380
    40 (0) win 8192 (DF) (ttl 127, id 25662 ) 3: 13: 57: 36.981776 00be.75f6.1dae a023.9f92.2a4d 0x0800 Длина: 66 10.10.1.100.80> 192.168.0.100.47741: S [tcp sum ok] 1304153587: 1304153587 (0) ack 380
    41 win 8192 (DF) (ttl 127, id 23339) 4: 13: 57: 36.982126 a023.9f92.2a4d 00be.75f6.1dae 0x0800 Длина: 54 192.168.0.100.47741> 10.10.1.100.80: R [tcp sum ok] 380
    41: 380
    41 (0) ack 1304153588 win 8192 (ttl 255, id 48501) ...

    Случай 5. Медленная передача TCP (сценарий 1)

    Описание проблемы:

    Передача SFTP между хостами 10.11.4.171 и 10.77.19.11 медленные. Хотя минимальная пропускная способность (BW) между двумя хостами составляет 100 Мбит / с, скорость передачи не превышает 5 Мбит / с.

    При этом скорость передачи между хостами 10.11.2.124 и 172.25.18.134 значительно выше.

    Теория предыстории:

    Максимальная скорость передачи для одного потока TCP определяется продуктом задержки полосы пропускания (BDP). Используемая формула показана на изображении:

    Более подробную информацию о BDP можно найти здесь:

    Сценарий 1.Медленная передача

    На этом изображении показана топология:

    Затрагиваемый поток:

    IP-адрес источника: 10.11.4.171

    Dst IP: 10.77.19.11

    Протокол: SFTP (FTP через SSH)

    Анализ захвата

    Включить захват на движке FTD LINA:

     firepower #  захват CAPI int INSIDE buffer 33554432 match ip host 10.11.4.171 host 10.77.19.11 
    firepower #  захват CAPO int OUTSIDE buffer 33554432 match ip host 10.11.4.171 хост 10.77.19.11
      

    Предупреждение : Захваты LINA на захватах FP1xxx и FP21xx влияют на скорость передачи трафика, проходящего через FTD. Не включайте перехваты LINA на платформах FP1xxx и FP21xxx при устранении проблем с производительностью (медленная передача через FTD). Вместо этого используйте SPAN или устройство HW Tap в дополнение к захватам на исходном и целевом хостах. Проблема задокументирована в CSCvo30697.

     firepower #  захват интерфейса трассировки необработанных данных типа CAPI внутри соответствует icmp любой любой 
    ПРЕДУПРЕЖДЕНИЕ. Выполнение перехвата пакетов может отрицательно сказаться на производительности.
    Рекомендуемые действия

    Действия, перечисленные в этом разделе, направлены на дальнейшее сужение проблемы.

    Расчет времени туда и обратно (RTT)

    Сначала определите поток передачи и проследите за ним:

    Измените представление Wireshark, чтобы отобразить секунд с момента предыдущего отображаемого пакета . Это упрощает расчет RTT:

    RTT можно рассчитать путем сложения значений времени между двумя пакетами обмена (один по направлению к источнику, а другой по направлению к месту назначения).В этом случае пакет № 2 показывает RTT между межсетевым экраном и устройством, которое отправило пакет SYN / ACK (сервер). Пакет № 3 показывает RTT между межсетевым экраном и устройством, отправившим пакет ACK (клиентом). Сложение двух чисел дает хорошую оценку сквозного RTT:

    RTT ≈ 80 мс

    Расчет размера окна TCP

    Разверните пакет TCP, разверните заголовок TCP, выберите Расчетный размер окна и выберите Применить как столбец:

    Проверьте столбец Расчетное значение размера окна , чтобы узнать, какое максимальное значение размера окна было во время сеанса TCP.Вы также можете выбрать имя столбца и отсортировать значения.

    Если вы тестируете загрузку файла (сервер > клиент ), вы должны проверить значения, объявленные сервером. Максимальное значение размера окна, объявленное сервером, определяет максимальную скорость передачи.

    В данном случае размер окна TCP составляет ≈ 50000 байт

    На основе этих значений и с использованием формулы произведения на задержку полосы пропускания вы получаете максимальную теоретическую полосу пропускания, которая может быть достигнута в этих условиях: 50000 * 8/0.0 = 1 (без масштабирования окон). Это отрицательно сказывается на скорости передачи:

    На этом этапе необходимо выполнить захват на сервере, подтвердить, что это тот, кто объявляет масштаб окна = 0, и перенастроить его (вам может потребоваться проверить документацию сервера, как это сделать).

    Сценарий 2. Быстрая передача

    Теперь рассмотрим хороший сценарий (быстрая передача через ту же сеть):

    Топология:

    Поток интересов:

    Src IP: 10.11.2.124

    Dst IP: 172.25.18.134

    Протокол: SFTP (FTP через SSH)

    Включить захват на движке FTD LINA

     firepower #  захват CAPI int INSIDE buffer 33554432 сопоставление ip host 10.11.2.124 host 172.25.18.134 
    firepower #  захват CAPO int ВНЕШНИЙ буфер 33554432 сопоставление IP-хоста 10.11.2.124 хост 172.25.18.134
      

    Расчет времени кругового обхода (RTT): В этом случае RTT составляет ≈ 300 мсек.

    Расчет размера окна TCP: сервер объявляет коэффициент масштабирования окна TCP равный 7.

    Размер окна TCP сервера ≈ 1600000 Байт:

    На основе этих значений формула произведения на задержку полосы пропускания дает:

    1600000 * 8 / 0,3 = максимальная теоретическая скорость передачи 43 Мбит / с

    Случай 6. Медленная передача TCP (сценарий 2)

    Описание проблемы: Передача (загрузка) файлов по FTP через брандмауэр происходит медленно.

    На этом изображении показана топология:

    Затрагиваемый поток:

    Src IP: 192.168.2.220

    Dst IP: 192.168.1.220

    Протокол: FTP

    Анализ захвата

    Включить захват на движке FTD LINA.

     firepower #  захват буфера необработанных данных типа CAPI 33554432 интерфейс INSIDE соответствует хосту tcp 192.168.2.220 хосту 192.168.1.220 
    firepower #  cap Буфер необработанных данных типа CAPO 33554432 интерфейс ВНЕШНЕЕ соответствие хоста tcp 192.168.2.220 хост 192.168.1.220
      

    Выберите пакет FTP-DATA и следуйте каналу данных FTP при захвате FTD INSIDE (CAPI):

    Содержимое потока FTP-DATA:

    Содержимое захвата CAPO:

    Ключевые точки:

    1. Есть пакеты TCP Out-Of-Order (OOO).
    2. Идет повторная передача TCP.
    3. Имеется индикация потери пакета (отброшенные пакеты).

    Совет : Сохраните захваченные данные при переходе к Файл> Экспортировать указанные пакеты . Затем сохраните только Отображаемый диапазон пакетов

    Рекомендуемые действия

    Действия, перечисленные в этом разделе, направлены на дальнейшее сужение проблемы.

    Действие 1. Определите место потери пакета.

    В подобных случаях необходимо выполнять одновременный захват и использовать методологию «разделяй и властвуй» для определения сегмента (ов) сети, вызывающего потерю пакетов. С точки зрения межсетевого экрана существует 3 основных сценария:

    1. Потеря пакетов вызвана самим межсетевым экраном.
    2. Потеря пакета вызвана нисходящим потоком к устройству межсетевого экрана (направление от сервера к клиенту).
    3. Потеря пакета вызвана восходящим потоком к устройству межсетевого экрана (направление от клиента к серверу).

    Потеря пакетов, вызванная межсетевым экраном: Чтобы определить, вызвана ли потеря пакетов межсетевым экраном, необходимо сравнить входящий захват с исходящим захватом. Есть довольно много способов сравнить 2 разных снимка. В этом разделе показан один из способов решения этой задачи.

    Процедура сравнения 2 захватов для определения потери пакетов

    Шаг 1. Убедитесь, что 2 захвата содержат пакеты из одного и того же временного окна. Это означает, что в одном захвате не должно быть пакетов, которые были захвачены до или после другого захвата.Есть несколько способов сделать это:

    • Проверьте значения IP-идентификатора (ID) первого и последнего пакета.
    • Проверить значения отметок времени первого и последнего пакета.

    В этом примере вы можете видеть, что первые пакеты каждого захвата имеют одинаковые значения IP ID:

    Если они не совпадают, то:

    1. Сравните временные метки первого пакета каждого захвата.
    2. Из захвата с последней отметкой времени получите фильтр, измените фильтр отметки времени с == на > = (первый пакет) и <= (последний пакет), например.г:

    (frame.time> = "16 октября 2019 г. 16: 13: 43.2446") && (frame.time <= "16 октября 2019 г. 16: 20: 21.785130000")

    3. Экспортируйте указанные пакеты в новый захват, выберите Файл> Экспортировать указанные пакеты и затем сохраните Отображаемые пакеты . На этом этапе оба захвата должны содержать пакеты, охватывающие одно и то же временное окно. Теперь вы можете начать сравнение двух снимков.

    Шаг 2. Укажите, какое поле пакета используется для сравнения двух захватов.Пример полей, которые можно использовать:

    • IP-идентификация
    • Порядковый номер RTP
    • Порядковый номер ICMP

    Создайте текстовую версию каждого захвата, содержащую поле для каждого пакета, указанного на шаге 1. Для этого оставьте только интересующий столбец, например если вы хотите сравнить пакеты на основе IP-идентификации, измените захват, как показано на изображении.

    Результат:

    Шаг 3.Создайте текстовую версию захвата ( File> Export Packet Dissections> As Plain Text ...), как показано на изображении:

    Снимите отметку с заголовков столбцов I nclude и Сведения о пакете Параметры , чтобы экспортировать только значения отображаемого поля, как показано на изображении:

    Шаг 4. Отсортируйте пакеты в файлах. Для этого можно использовать команду Linux sort :

     #  сортировать CAPI_IDs> file1.отсортировано 
    #  sort CAPO_IDs> file2.sorted
      


    Шаг 5. Используйте инструмент сравнения текста (например, WinMerge) или команду Linux diff , чтобы найти различия между двумя захватами.

    В этом случае захват CAPI и CAPO для трафика данных FTP идентичен. Это доказывает, что потеря пакетов не была вызвана межсетевым экраном.

    Определить потерю пакетов в восходящем / нисходящем направлениях.

    Ключевые точки:

    1.Этот пакет является повторной передачей TCP. В частности, это пакет TCP SYN, отправленный от клиента к серверу для данных FTP в пассивном режиме. Поскольку клиент повторно отправляет пакет, и вы можете увидеть начальный SYN (пакет №1), пакет был потерян в восходящем направлении к межсетевому экрану.

    В этом случае может быть даже вероятность того, что пакет SYN попал на сервер, но пакет SYN / ACK был потерян на обратном пути:

    2. Есть пакет от сервера, и Wireshark определил, что предыдущий сегмент не был замечен / захвачен.Поскольку незахваченный пакет был отправлен с сервера на клиент и не был замечен в захвате брандмауэра, это означает, что пакет был потерян между сервером и брандмауэром.

    Это указывает на потерю пакетов между FTP-сервером и межсетевым экраном.

    Действие 2. Сделать дополнительные захваты.

    Сделайте дополнительные захваты вместе с захватами на конечных точках. Попробуйте применить метод «разделяй и властвуй», чтобы изолировать проблемный сегмент, вызывающий потерю пакетов.

    Ключевые точки:

    1. Получатель (в данном случае FTP-клиент) отслеживает входящие порядковые номера TCP. Если он обнаруживает, что пакет был пропущен (ожидаемый порядковый номер был пропущен), он генерирует пакет ACK с ACK = «ожидаемый порядковый номер, который был пропущен». В этом примере Ack = 2224386800.
    2. Dup ACK запускает быструю повторную передачу TCP (повторная передача в течение 20 мсек после получения дублированного ACK).

    Что означают повторяющиеся ACK?

    • Несколько дублированных ACK, но нет фактических повторных передач, указывают на то, что, скорее всего, есть пакеты, которые прибывают не по порядку.
    • Дублирующиеся ACK, за которыми следуют фактические повторные передачи, указывают на некоторую потерю пакетов.

    Действие 3. Рассчитайте время обработки межсетевым экраном транзитных пакетов.

    Применить один и тот же захват на 2 разных интерфейсах:

     firepower #  захват буфера CAPI 33554432 интерфейс INSIDE совпадение хоста tcp 192.168.2.220 хост 192.168.1.220 
    firepower #  захват интерфейса CAPI СНАРУЖИ  

    Экспорт захвата, проверка разницы во времени между входящими и исходящими пакетами

    Кейс 7.Проблема подключения TCP (повреждение пакета)

    Описание проблемы:

    Беспроводной клиент (192.168.21.193) пытается подключиться к целевому серверу (192.168.14.250 - HTTP), и существует 2 разных сценария:

    • Когда клиент подключается к точке доступа «A», HTTP-соединение не работает.
    • Когда клиент подключается к точке доступа «B», HTTP-соединение работает.

    На этом изображении показана топология:

    Затрагиваемый поток:

    Src IP: 192.168.21.193

    Dst IP: 192.168.14.250

    Протокол: TCP 80

    Анализ захвата

    Включить захват на движке FTD LINA:

     firepower #  захват CAPI int INSIDE match ip host 192.168.21.193 host 192.168.14.250 
    firepower #  захват CAPO int OUTSIDE соответствует IP-хосту 192.168.21.193 хосту 192.168.14.250
      

    Захваты - Функциональный сценарий:

    В качестве основы всегда очень полезно иметь захваты из рабочего сценария.

    На этом изображении показан снимок, сделанный на интерфейсе NGFW INSIDE

    На этом изображении показан снимок, сделанный на ВНЕШНЕМ интерфейсе NGFW.

    Ключевые точки:

    1. 2 захвата почти идентичны (учтите рандомизацию ISN).
    2. Нет признаков потери пакета.
    3. Пакеты без заказа (ООО)
    4. Имеется 3 запроса HTTP GET. Первый получает сообщение 404 «Не найдено», второй - 200 «ОК», а третий получает сообщение перенаправления 304 «Не изменено».

    Захваты - Нерабочий сценарий:

    Содержимое входящего захвата (CAPI).

    Ключевые точки:

    1. Имеется трехстороннее подтверждение TCP.
    2. Есть повторные передачи TCP и признаки потери пакета.
    3. Существует пакет (TCP ACK), который Wireshark идентифицирует как Malformed .

    На этом изображении показано содержимое исходящего захвата (CAPO).

    Ключевые точки:

    2 захвата почти идентичны (рассмотрим рандомизацию ISN):

    1. Имеется трехстороннее подтверждение TCP.
    2. Есть повторные передачи TCP и признаки потери пакета.
    3. Существует пакет (TCP ACK), который Wireshark идентифицирует как Malformed .

    Проверить неверно сформированный пакет:

    Ключевые точки:

    1. Пакет идентифицирован как неверно сформированный программой Wireshark.
    2. Имеет длину 2 байта.
    3. Имеется полезная нагрузка TCP размером 2 байта.
    4. Полезная нагрузка - 4 дополнительных нуля (00 00).
    Рекомендуемые действия

    Действия, перечисленные в этом разделе, направлены на дальнейшее сужение проблемы.

    Действие 1. Сделайте дополнительные перехваты, включая перехваты на конечных точках, и, если возможно, попробуйте применить метод «разделяй и властвуй», чтобы изолировать источник повреждения пакета, например

    В этом случае 2 дополнительных байта были добавлены драйвером интерфейса коммутатора «A», и решением было заменить коммутатор, вызывающий повреждение.

    Случай 8. Проблема с подключением UDP (отсутствующие пакеты)

    Описание проблемы: Сообщения системного журнала (UDP 514) не отображаются на целевом сервере системного журнала.

    На этом изображении показана топология:

    Затрагиваемый поток:

    Src IP: 192.168.1.81

    Dst IP: 10.10.1.73

    Протокол: UDP 514

    Анализ захвата

    Включить захват на движке FTD LINA:

     firepower #  захват CAPI int INSIDE trace match udp host 192.168.1.81 host 10.10.1.73 eq 514 
    firepower #  захват CAPO int OUTSIDE match udp host 192.168.1.81 host 10.10.1.73 eq 514
      

    Захваты FTD не показывают пакетов:

     огневая мощь #  показать захват 
    захват интерфейса трассировки необработанных данных типа CAPI ВНУТРИ [захват - 0 байт]
      соответствовать хосту udp 192.168.1.81 хост 10.10.1.73 eq syslog
    захват интерфейса необработанных данных типа CAPO ВНЕШНИЙ [захват - 0 байт]
      сопоставить хост udp 192.168.1.81 хост 10.10.1.73 eq syslog
     
    Рекомендуемые действия

    Действия, перечисленные в этом разделе, направлены на дальнейшее сужение проблемы.

    Действие 1. Проверьте таблицу соединений FTD.

    Чтобы проверить конкретное соединение, вы можете использовать этот синтаксис:

     firepower #  показать адрес соединения 192.168.1.81 порт 514 
    10 в использовании, 3627189 наиболее часто используемых
    Осмотрите Snort:
            preserve-connection: 6 включено, 0 активно, 74 наиболее активно, 0 наиболее активно
    
    UDP  ВНУТРИ  10.10.1.73: 514  INSIDE  192.168.1.81:514, idle 0:00:00, байты  480379697 , флаги -  o  N1
     

    Ключевые точки:

    1. Входящий и выходной интерфейсы одинаковы (разворот).
    2. Количество байтов имеет очень большое значение (~ 5 ГБ).
    3. Флаг «o» обозначает разгрузку потока (HW ускоренный поток). Это причина того, что захваты FTD не показывают никаких пакетов. Разгрузка потока поддерживается только на платформах 41xx и 93xx.В данном случае это устройство 41xx.

    Действие 2. Сделайте снимки на уровне шасси.

    Подключитесь к диспетчеру шасси Firepower и включите захват на входном интерфейсе (в данном случае E1 / 2) и интерфейсах объединительной платы (E1 / 9 и E1 / 10), как показано на изображении:

    Через несколько секунд:

    Совет : в Wireshark исключите пакеты с тегами VN, чтобы исключить дублирование пакетов на уровне физического интерфейса

    Раньше:

    После:

    Ключевые точки:

    1. Фильтр отображения применяется для удаления дубликатов пакетов и отображения только системных журналов.
    2. Разница между пакетами находится на уровне микросекунд. Это указывает на очень высокую скорость передачи пакетов.
    3. Время жизни (TTL) непрерывно уменьшается. Это указывает на пакетную петлю.

    Действие 3. Используйте трассировщик пакетов.

    Поскольку пакеты не проходят через механизм LINA брандмауэра, вы не можете выполнять трассировку в реальном времени (захват с трассировкой), но вы можете отслеживать эмулируемый пакет с помощью средства отслеживания пакетов:

     firepower #  вход для трассировщика пакетов ВНУТРИ udp 10.10.1.73 514 192.168.1.81 514
     
    Фаза 1
    Тип: ЗАХВАТ
    Подтип:
    Результат: РАЗРЕШИТЬ
    Конфиг:
    Дополнительная информация:
    Список доступа MAC
    
    Фаза 2
    Тип: СПИСОК ДОСТУПА
    Подтип:
    Результат: РАЗРЕШИТЬ
    Конфиг:
    Неявное правило
    Дополнительная информация:
    Список доступа MAC
    
    Фаза: 3
    Тип: ПОТОК-ПРОСМОТР
    Подтип:
    Результат: РАЗРЕШИТЬ
    Конфиг:
    Дополнительная информация:
      Найден поток с идентификатором 25350892 с использованием существующего потока 
    
    Фаза: 4
    Тип: SNORT
    Подтип:
    Результат: РАЗРЕШИТЬ
    Конфиг:
    Дополнительная информация:
    Snort Verdict: (перемотка вперед) перемотка вперед по этому потоку
    
    Фаза: 5
    Тип: МАРШРУТ-ПРОСМОТР
    Подтип: Разрешить исходящий интерфейс
    Результат: РАЗРЕШИТЬ
    Конфиг:
    Дополнительная информация:
    найден следующий переход 192.168.1.81 с использованием egress ifc INSIDE
    
    Фаза: 6
    Тип: ADJACENCY-LOOKUP
    Подтип: следующий переход и смежность
    Результат: РАЗРЕШИТЬ
    Конфиг:
    Дополнительная информация:
    смежность активна
    MAC-адрес следующего перехода a023.9f92.2a4d попадает в 1 ссылку 1
    
    Фаза: 7
    Тип: ЗАХВАТ
    Подтип:
    Результат: РАЗРЕШИТЬ
    Конфиг:
    Дополнительная информация:
    Список доступа MAC
    
    Результат:
      интерфейс ввода: INSIDE 
    вход-статус: вверх
    вход-линия-статус: вверх
     Выходной интерфейс : ВНУТРИ 
    статус вывода: вверх
    статус строки вывода: вверх
    Действие: разрешить
     

    Действие 4.Подтвердите маршрутизацию FTD.

    Проверьте таблицу маршрутизации брандмауэра на предмет проблем с маршрутизацией:

     firepower #  показать маршрут 10.10.1.73 
    
    Запись маршрутизации для 10.10.1.0 255.255.255.0
      Известен через "eigrp 1", расстояние 90, метрическая система 3072, тип внутренний
      Распространение через eigrp 1
      Последнее обновление от 192.168.2.72 на  СНАРУЖИ, 0:03:37 назад 
      Блоки дескриптора маршрутизации:
      * 192.168.2.72, из 192.168.2.72,  0:02:37 назад, через OUTSIDE 
          Метрика маршрута - 3072, доля трафика - 1.
          Общая задержка 20 микросекунд, минимальная пропускная способность 1000000 Кбит
          Надежность 255/255, минимальный MTU 1500 байт
          Загрузка 29/255, хмель 1
     

    Ключевые точки:

    1. Маршрут указывает на правильный выходной интерфейс.
    2. Маршрут был изучен несколько минут назад (0:02:37).

    Действие 5. Подтвердите время работы соединения.

    Проверьте время работы соединения, чтобы узнать, когда оно было установлено:

     firepower #  показать адрес соединения 192.168.1.81 порт 514 деталь 
    21 используется, 3627189 наиболее часто используется
    Осмотрите Snort:
            preserve-connection: 19 включено, 0 активно, 74 наиболее активно, 0 наиболее активно
    Флаги: A - ожидает ACK ответчика на SYN, a - ожидает ACK инициатора на SYN,
           b - TCP state-bypass или прибитый,
           C - CTIQBE media, c - кластер централизованный,
           D - DNS, d - дамп, E - внешнее обратное соединение, e - полураспределенное,
           F - инициатор FIN, f - ответчик FIN,
           G - группа, g - MGCP, H - H.323, h - H.225.0, I - данные инициатора,
           i - неполный, J - GTP, j - данные GTP, K - t3-ответ GTP
           k - тощий носитель, L - туннель без крышки, M - данные SMTP, m - носитель SIP
           N - проверено Snort (1 - сохранение соединения включено, 2 - сохранение соединения включено)
           n - GUP, O - данные респондента, o - выгружены,
           P - внутреннее заднее соединение, p - пассажирский поток
           q - данные SQL * Net, R - инициатор подтвердил FIN,
           R - UDP SUNRPC, r - ответчик подтвердил FIN,
           T - SIP, t - SIP переходный, U - вверх,
           V - сирота VPN, v - M3UA W - WAAS,
           w - резервная копия вторичного домена,
           X - проверяется сервисным модулем,
           x - на сеанс, Y - поток заглушки директора, y - поток заглушки резервного копирования,
           Z - Scansafe redirection, z - прямой поток пересылки
    
    UDP ВНУТРИ: 10.10.1.73 / 514 ВНУТРИ: 192.168.1.81/514,
        флаги -oN1, простоя 0 с,  время безотказной работы 3 мин 49 с , тайм-аут 2 мин 0 с, байты 4801148711
     

    Ключевой момент:

    1. Соединение было установлено ~ 4 минуты назад (это до установки маршрута EIGRP в таблице маршрутизации)

    Действие 6. Удалите существующее соединение.

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

    1. Поиск установленного соединения (имеет приоритет над поиском в глобальной таблице маршрутизации).
    2. Поиск трансляции сетевых адресов (NAT) - этап UN-NAT (NAT назначения) имеет приоритет над PBR и поиском маршрута.
    3. Маршрутизация на основе политик (PBR)
    4. Поиск в глобальной таблице маршрутизации

    Поскольку соединение никогда не прерывается (клиент системного журнала непрерывно отправляет пакеты, в то время как тайм-аут простоя соединения UDP составляет 2 минуты), необходимо вручную очистить соединение:

     firepower #  очистить адрес соединения 10.10.1.73 адрес 192.168.1.81 протокол UDP порт 514 
    1 соединение (а) удалено.


    Убедитесь, что установлено новое соединение:

     firepower #  показать адрес соединения 192.168.1.81 детали порта 514 | б 10.10.1.73. * 192.168.1.81 
    UDP  СНАРУЖИ : 10.10.1.73/514  ВНУТРИ : 192.168.1.81/514,
        флаги -oN1, простоя 1 мин. 15 сек., время безотказной работы 1 мин. 15 сек., тайм-аут 2 мин. 0 сек., байты 408
     

    Действие 7. Настройте таймаут плавающего соединения.

    Это правильное решение для решения проблемы и предотвращения неоптимальной маршрутизации, особенно для потоков UDP.Перейдите к Devices> Platform Settings> Timeouts и установите значение:

    Более подробную информацию о таймауте плавающего соединения можно найти в Справочнике по командам:

    https://www.cisco.com/c/en/us/td/docs/security/asa/asa-command-reference/T-Z/cmdref4/t1.html#pgfId-1649892

    Случай 9. Проблема подключения HTTPS (сценарий 1)

    Описание проблемы: HTTPS-связь между клиентом 192.168.201.105 и сервером 192.168.202.101 невозможно установить

    На этом изображении показана топология:

    Затрагиваемый поток:

    Src IP: 192.168.201.111

    Dst IP: 192.168.202.111

    Протокол: TCP 443 (HTTPS)

    Анализ захвата

    Включить захват на движке FTD LINA:

    IP-адрес, используемый во ВНЕШНЕМ захвате, отличается из-за конфигурации преобразования порта в адрес.

     firepower #  захват CAPI int INSIDE match ip host 192.168.201.111 хост 192.168.202.111 
    firepower #  захват CAPO int OUTSIDE соответствие IP-хост 192.168.202.11 хост 192.168.202.111
      


    На этом изображении показан снимок, сделанный на интерфейсе NGFW INSIDE:

    Ключевые точки:

    1. Имеется трехстороннее подтверждение TCP.
    2. Начинается согласование SSL. Клиент отправляет сообщение Client Hello.
    3. Клиенту отправлено TCP ACK.
    4. Клиенту отправлено TCP RST.

    На этом изображении показан снимок, сделанный на ВНЕШНЕМ интерфейсе NGFW.

    Ключевые точки:

    1. Имеется трехстороннее подтверждение TCP.
    2. Начинается согласование SSL. Клиент отправляет сообщение Client Hello.
    3. Брандмауэр отправляет на сервер повторные передачи TCP.
    4. На сервер отправлено TCP RST.
    Рекомендуемые действия

    Действия, перечисленные в этом разделе, направлены на дальнейшее сужение проблемы.

    Действие 1. Сделайте дополнительные снимки.

    Захват, сделанный на сервере, показывает, что сервер получил TLS Client Hellos с поврежденной контрольной суммой TCP и молча отбрасывает их (нет TCP RST или любого другого пакета ответа для клиента):

    Если собрать все вместе:

    В этом случае, чтобы понять, что происходит, необходимо включить в Wireshark опцию Проверить контрольную сумму TCP, если возможно, . Перейдите к Edit> Preferences> Protocols> TCP , как показано на изображении.

    В этом случае полезно расположить снимки рядом, чтобы получить полную картину:

    Ключевые точки:

    1. Имеется трехстороннее подтверждение TCP. Идентификаторы IP такие же. Это означает, что брандмауэр не проксировал поток.
    2. Приветствие клиента TLS исходит от клиента с IP-идентификатором 12083. Пакет передается через прокси-сервер межсетевым экраном (в данном случае межсетевой экран был настроен с использованием политики расшифровки TLS), а IP-идентификатор изменен на 52534.Кроме того, контрольная сумма TCP пакета повреждена (из-за дефекта программного обеспечения, который позже был исправлен).
    3. Брандмауэр находится в режиме TCP Proxy и отправляет ACK клиенту (подменяя сервер).

    4. Межсетевой экран не получает никаких пакетов TCP ACK от сервера и повторно передает приветственное сообщение клиента TLS. Это снова связано с режимом TCP Proxy, который активировал брандмауэр.
    5. Примерно через 30 секунд межсетевой экран отказывается и отправляет клиенту TCP RST.
    6. Межсетевой экран отправляет серверу TCP RST.

    Для справки:

    Firepower TLS / SSL Обработка квитирования

    Случай 10. Проблема подключения HTTPS (сценарий 2)

    Описание проблемы: Ошибка регистрации лицензии FMC Smart.

    На этом изображении показана топология:

    Затрагиваемый поток:

    Src IP: 192.168.0.100

    Dst: tools.cisco.com

    Протокол: TCP 443 (HTTPS)

    Анализ захвата

    Включить захват в интерфейсе управления FMC:

    Попробуйте зарегистрироваться еще раз.C захвачено 264 пакета <- CTRL-C 264 пакетов, полученных фильтром 0 пакетов отброшено ядром корень @ огневая мощь: / Том / главная / админ #


    Соберите снимок из FMC ( System> Health> Monitor, выберите устройство и выберите Advanced Troubleshooting ), как показано на изображении:

    На изображении показан захват FMC на Wireshark:

    Совет : Чтобы проверить все новые захваченные сеансы TCP, используйте tcp.flags == 0x2 фильтр отображения в Wireshark. Это фильтрует все захваченные TCP SYN-пакеты.

    Совет : примените в качестве столбца поле Server Name из сообщения SSL Client Hello.

    Совет : примените этот фильтр отображения, чтобы видеть только сообщения Client Hello ssl.handshake.type == 1

    Примечание : на момент написания этой статьи портал интеллектуального лицензирования (tools.cisco.com) использует эти IP-адреса: 72.163.4.38, 173.37.145.8

    Следуйте одному из TCP-потоков ( Follow> TCP Stream) , как показано на изображении.

    Ключевые точки:

    1. Имеется трехстороннее подтверждение TCP.
    2. Клиент (FMC) отправляет сообщение SSL Client Hello на портал Smart Licensing.
    3. Идентификатор сеанса SSL - 0. Это означает, что сеанс не возобновлен.
    4. Целевой сервер отвечает сообщениями Server Hello, Certificate и Server Hello Done.
    5. Клиент отправляет SSL Fatal Alert с жалобой на «Неизвестный ЦС».
    6. Клиент отправляет TCP RST, чтобы закрыть сеанс.
    7. Полная продолжительность сеанса TCP (от установления до закрытия) составляла ~ 0,5 секунды.

    Выберите Сертификат сервера и разверните поле эмитента , чтобы увидеть commonName. В этом случае Общее имя показывает устройство, которое выполняет функцию «Человек посередине» (MITM).

    Это показано на этом изображении:

    Рекомендуемые действия

    Действия, перечисленные в этом разделе, направлены на дальнейшее сужение проблемы.

    Действие 1. Сделайте дополнительные снимки.

    Сделать снимки на устройстве транзитного брандмауэра:

    CAPI показывает:

    CAPO показывает:

    Эти записи подтверждают, что транзитный межсетевой экран изменяет сертификат сервера (MITM)

    Действие 2. Проверьте журналы устройства.

    Вы можете получить комплект FMC TS, как описано в этом документе:

    https://www.cisco.com/c/en/us/support/docs/security/sourcefire-defense-center/117663-technote-SourceFire-00.HTML

    В этом случае файл /dir-archives/var-log/process_stdout.log показывает такие сообщения:

     SOUT: 10-23 05:45:14 2019-10-23 05:45:36 sla [10068]: * среда .967 UTC: CH-LIB-ERROR: ch_pf_curl_send_msg [494], 
    не удалось выполнить, ошибка код 60, строка ошибки "Сертификат узла SSL или удаленный ключ SSH не в порядке" ...
    SOUT: 10-23 05:45:14 2019-10-23 05:45:36 sla [10068]: * Ср. 967 UTC: CH-LIB-TRACE: ch_pf_curl_is_cert_issue [514],
    Проблема с сертификатом проверка, ret 60, url "https: // tools.cisco.com/its/

    Рекомендуемое решение

    Отключите MITM для определенного потока, чтобы FMC мог успешно зарегистрироваться в облаке Smart Licensing.

    Случай 11. Проблема подключения IPv6

    Описание проблемы: внутренние узлы (расположенные за ВНУТРЕННИМ интерфейсом межсетевого экрана) не могут взаимодействовать с внешними узлами (узлами, расположенными за ВНЕШНИМ интерфейсом межсетевого экрана).

    На этом изображении показана топология:

    Затрагиваемый поток:

    Src IP: fc00: 1: 1: 1 :: 100

    Dst IP: fc00: 1: 1: 2 :: 2

    Протокол: любой

    Анализ захвата

    Включить захват на движке FTD LINA.

     firepower #  захват CAPI int INSIDE match ip any6 any6 
    огневая мощь #  захват CAPO int OUTSIDE match ip any6 any6
      

    Захваты - нефункциональный сценарий

    Эти записи были сделаны параллельно с тестом подключения ICMP с IP fc00: 1: 1: 1 :: 100 (внутренний маршрутизатор) на IP fc00: 1: 1: 2 :: 2 (восходящий маршрутизатор).

    Захват на межсетевом экране ВНУТРИ интерфейса содержит:

    Ключевые точки:

    1. Маршрутизатор отправляет сообщение IPv6 Neighbor Solicitation с запросом MAC-адреса восходящего устройства (IP fc00: 1: 1: 1 :: 1).
    2. Брандмауэр отвечает объявлением о соседстве IPv6.
    3. Маршрутизатор отправляет эхо-запрос ICMP.
    4. Межсетевой экран отправляет сообщение IPv6 Neighbor Solicitation с запросом MAC-адреса нисходящего устройства (fc00: 1: 1: 1 :: 100).
    5. Маршрутизатор отвечает объявлением о соседстве IPv6.
    6. Маршрутизатор отправляет дополнительные эхо-запросы IPv6 ICMP.

    Захват на ВНЕШНЕМ интерфейсе межсетевого экрана содержит:

    Ключевые точки:

    1. Межсетевой экран отправляет сообщение IPv6 Neighbor Solicitation с запросом MAC-адреса восходящего устройства (IP fc00: 1: 1: 2 :: 2).
    2. Маршрутизатор отвечает объявлением о соседстве IPv6.
    3. Межсетевой экран отправляет эхо-запрос IPv6 ICMP.
    4. Устройство восходящего потока (маршрутизатор fc00: 1: 1: 2 :: 2) отправляет сообщение IPv6 Neighbor Solicitation с запросом MAC-адреса IPv6-адреса fc00: 1: 1: 1 :: 100.
    5. Межсетевой экран отправляет дополнительный эхо-запрос IPv6 ICMP.
    6. Маршрутизатор восходящего потока отправляет дополнительное сообщение IPv6 Neighbor Solicitation с запросом MAC-адреса IPv6-адреса fc00: 1: 1: 1 :: 100.

    Пункт 4 очень интересный. Обычно восходящий маршрутизатор запрашивает MAC-адрес ВНЕШНЕГО интерфейса межсетевого экрана (fc00: 1: 1: 2 :: 2), но вместо этого он запрашивает fc00: 1: 1: 1 :: 100. Это признак неправильной конфигурации.

    Рекомендуемые действия

    Действия, перечисленные в этом разделе, направлены на дальнейшее сужение проблемы.

    Действие 1. Проверьте таблицу соседей IPv6.

    Таблица IPv6-соседей межсетевого экрана заполнена правильно.

     firepower #  показать соседа по ipv6 | я fc00 
    fc00: 1: 1: 2 :: 2 58 4c4e.35fc.fcd8 СТАЛО ВНЕШНИЙ
    fc00: 1: 1: 1 :: 100 58 4c4e.35fc.fcd8 СТАЛО ВНУТРИ
     

    Действие 2. Проверьте конфигурацию IPv6.

    Это конфигурация брандмауэра.

     firewall #  show run int e1 / 2 
    !
    интерфейс Ethernet1 / 2
     nameif ВНУТРИ
     cts руководство
      распространять sgt preserve-untag
      политика статическая sgt отключена доверенная
     уровень безопасности 0
     IP-адрес 192.168.0.1 255.255.255.0
     IPv6-адрес  fc00: 1: 1: 1 :: 1/64 
     ipv6 включить
    
    брандмауэр #  показать запуск int e1 / 3.202 
    !
    интерфейс Ethernet1 / 3.202
     vlan 202
     nameif СНАРУЖИ
     cts руководство
      распространять sgt preserve-untag
      политика статическая sgt отключена доверенная
     уровень безопасности 0
     IP-адрес 192.168.103.96 255.255.255.0
     IPv6-адрес  fc00: 1: 1: 2 :: 1/64 
     ipv6 включить
     


    Конфигурация восходящего устройства обнаруживает неправильную конфигурацию:

     Маршрутизатор № показывает интерфейс запуска g0 / 0.202 
    !
    интерфейс GigabitEthernet0 / 0.202
     инкапсуляция dot1Q 202
     VRF переадресация VRF202
     IP-адрес 192.168.2.72 255.255.255.0
     IPv6-адрес FC00: 1: 1: 2 :: 2 /48
      

    Захваты - Функциональный сценарий

    Изменение маски подсети (с / 48 на / 64) устранило проблему. Это запись CAPI в функциональном сценарии.

    Ключевой момент:

    1. Маршрутизатор отправляет сообщение IPv6 Neighbor Solicitation с запросом MAC-адреса восходящего устройства (IP fc00: 1: 1: 1 :: 1).
    2. Брандмауэр отвечает объявлением о соседстве IPv6.
    3. Маршрутизатор отправляет эхо-запросы ICMP и получает эхо-ответы.

    Состав CAPO:

    Ключевые точки:

    1. Межсетевой экран отправляет сообщение IPv6 Neighbor Solicitation с запросом MAC-адреса восходящего устройства (IP fc00: 1: 1: 2 :: 2).
    2. Брандмауэр отвечает объявлением о соседстве IPv6.
    3. Межсетевой экран отправляет эхо-запрос ICMP.
    4. Маршрутизатор отправляет сообщение IPv6 Neighbor Solicitation с запросом MAC-адреса нисходящего устройства (IP fc00: 1: 1: 1 :: 1).
    5. Брандмауэр отвечает объявлением о соседстве IPv6.
    6. Межсетевой экран отправляет эхо-запросы ICMP и получает эхо-ответы.

    Случай 12. Непостоянная проблема подключения (отравление ARP)

    Описание проблемы: внутренние узлы (192.168.0.x / 24) периодически имеют проблемы с подключением к узлам в той же подсети

    На этом изображении показана топология:

    Затрагиваемый поток:

    Src IP: 192.168.0.x / 24

    Dst IP: 192.168.0.x / 24

    Протокол: любой

    Кажется, что кеш ARP внутреннего хоста отравлен:

    Анализ захвата

    Включить захват на движке FTD LINA

    Этот захват захватывает только пакеты ARP на интерфейсе INSIDE:

     firepower #  захват интерфейса CAPI_ARP INSIDE ethernet-type arp  

    Захваты - нефункциональный сценарий:

    Захват на межсетевом экране ВНУТРИ интерфейса содержит.

    Ключевые точки:

    1. Межсетевой экран получает различные запросы ARP для IP-адресов в сети 192.168.0.x / 24
    2. Межсетевой экран отвечает на все из них (прокси-ARP) своим собственным MAC-адресом
    Рекомендуемые действия

    Действия, перечисленные в этом разделе, направлены на дальнейшее сужение проблемы.

    Действие 1. Проверьте конфигурацию NAT.

    В зависимости от конфигурации NAT бывают случаи, когда ключевое слово no-proxy-arp может предотвратить вышеуказанное поведение:

     firepower #  выставка нац 
    nat (INSIDE, OUTSIDE) исходный статический NET_1.1.1.0 NET_2.2.2.0 назначения статический NET_192.168.0.0 NET_4.4.4.0  no-proxy-arp
      

    Действие 2. Отключите функцию proxy-arp в интерфейсе межсетевого экрана.

    Если ключевое слово «no-proxy-arp» не решает проблему, рассмотрите возможность отключения прокси-ARP на самом интерфейсе. В случае FTD на момент написания этой статьи вам нужно будет использовать FlexConfig и развернуть следующую команду (укажите соответствующее имя интерфейса).

     sysopt noproxyarp ВНУТРИ 

    Кейс 13.Определите идентификаторы объектов SNMP (OID), которые вызывают сбои ЦП

    Этот случай демонстрирует, как определенные идентификаторы SNMP OID для опроса памяти были определены как основная причина перегрузки ЦП (проблемы с производительностью) на основе анализа перехвата пакетов SNMP версии 3 (SNMPv3).

    Описание проблемы: Переполнение на интерфейсах данных постоянно увеличивается. Дальнейшее устранение неполадок показало, что есть также проблемы с ЦП (вызванные процессом SNMP), которые являются основной причиной переполнения интерфейса.

    Следующим шагом в процессе устранения неполадок было определение основной причины перегрузки ЦП, вызванной процессом SNMP, и, в частности, сужение области действия проблемы до определения идентификаторов объектов SNMP (OID), которые при опросе потенциально могут привести к в свиньях ЦП.

    В настоящее время механизм FTD LINA не предоставляет команду show для идентификаторов SNMP OID, которые опрашиваются в реальном времени. Список SNMP OID для опроса можно получить из инструмента мониторинга SNMP, однако в этом случае были следующие ограничивающие факторы:

    • Администратор FTD не имел доступа к инструменту мониторинга SNMP
    • SNMP версии 3 с аутентификацией и шифрованием данных для конфиденциальности был настроен на FTD
    Анализ захвата

    Поскольку администратор FTD имел учетные данные для аутентификации и шифрования данных SNMP версии 3, был предложен следующий план действий:

    1. Захват пакетов SNMP
    2. Сохраните записи и используйте настройки протокола Wireshark SNMP, чтобы указать учетные данные SNMP версии 3 для расшифровки пакетов SNMP версии 3.Расшифрованные записи используются для анализа и получения идентификаторов SNMP OID
    3. .

    Настроить захват пакетов SNMP на интерфейсе, который используется в конфигурации хоста snmp-server:

     огневой мощи #  показать запустить snmp-server | включить хост 
    управление хостом snmp-сервера 192.168.10.10 версия 3 netmonv3
    
    
    firepower #  показать управление IP-адресами 
    Системный IP-адрес:
    Имя интерфейса IP-адрес Маска подсети Метод
    Управление 0/0 Управление 192.168.5.254 255.255.255.0 КОНФИГУРАЦИЯ
    Текущий IP-адрес:
    Имя интерфейса IP-адрес Маска подсети Метод
    Управление 0/0 Управление 192.168.5.254 255.255.255.0 КОНФИГУРАЦИЯ
    
    firepower #  захват capsnmp интерфейс управления буфер 10000000 соответствие хоста udp 192.168.10.10 хост 192.168.5.254 eq snmp 
    
    firepower #  показать захват capsnmp 
    
    захватить тип capsnmp буфер необработанных данных 10000000 интерфейс вне [Capturing -  9512  bytes]
      соответствовать хосту udp 192.168.10.10 хост 192.168.5.254 eq snmp
     

    Ключевые точки:

    1. Адреса / порты источника и назначения SNMP.
    2. PDU протокола SNMP не может быть декодирован, потому что PrivKey неизвестен Wireshark.
    3. Значение примитива encryptedPDU.
    Рекомендуемые действия

    Действия, перечисленные в этом разделе, направлены на дальнейшее сужение проблемы.

    Действие 1. Расшифруйте записи SNMP.

    Сохраните записи и отредактируйте настройки протокола Wireshark SNMP, указав учетные данные SNMP версии 3 для расшифровки пакетов.

    Огневая мощь
     #  копирование / захват pcap: tftp: 
    Имя захвата источника [capsnmp]?
    
    Адрес или имя удаленного хоста []? 192.168.10.253
    
    Целевое имя файла [capsnmp]? capsnmp.pcap
      !!!!!!
    64 пакета скопировано за 0,40 секунды
      

    Откройте файл захвата в Wireshark, выберите пакет SNMP и перейдите к Настройки протокола> Таблица пользователей , как показано на изображении:

    В таблице пользователей SNMP были указаны имя пользователя SNMP версии 3, модель аутентификации, пароль аутентификации, протокол конфиденциальности и пароль конфиденциальности (фактические учетные данные не показаны ниже):

    После применения настроек пользователей SNMP Wireshark показал расшифрованные PDU SNMP:

    Ключевые точки:

    1. Инструменты мониторинга SNMP использовали SNMP getBulkRequest для запроса и обхода родительского OID 1.3.6.1.4.1.9.9.221.1 и связанные с ним OID.
    2. FTD отвечал на каждый запрос getBulkRequest получением ответа, содержащего OID, относящиеся к 1.3.6.1.4.1.9.9.221.1.

    Действие 2. Определите идентификаторы SNMP OID.

    Навигатор объектов SNMP показал, что OID 1.3.6.1.4.1.9.9.221.1 принадлежит базе управляющей информации (MIB) с именем CISCO-ENHANCED-MEMPOOL-MIB , как показано на изображении:

    Чтобы отобразить OID в удобочитаемом формате в Wireshark, выполните следующие действия:

    1. Загрузите MIB CISCO-ENHANCED-MEMPOOL-MIB и ее зависимости, как показано на изображении:

    2.В Wireshark в окне Edit> Preferences> Name Resolution установлен флажок Enable OID Resolution . В окне SMI (пути MIB и PIB) укажите папку с загруженными MIB, а в SMI (модули MIB и PIB). CISCO-ENHANCED-MEMPOOL-MIB автоматически добавляется в список модулей:

    3. После перезапуска Wireshark активируется разрешение OID:

    На основе расшифрованных выходных данных файла захвата инструмент мониторинга SNMP периодически (с интервалом 10 секунд) опрашивал данные об использовании пулов памяти на FTD.Как объяснено в статье TechNote, опрос ASA SNMP для статистики, связанной с памятью, при опросе использования глобального общего пула (GSP) с использованием SNMP приводит к загрузке ЦП. В этом случае из захватов было ясно, что использование глобального общего пула периодически опрашивалось как часть примитива SNMP getBulkRequest.

    Чтобы свести к минимуму нагрузку на ЦП, вызванную процессом SNMP, было рекомендовано выполнить шаги по снижению нагрузки на ЦП для SNMP, упомянутые в статье, и избегать опроса OID, связанных с GSP.Без опроса SNMP для идентификаторов OID, которые относятся к GSP, не наблюдалось никаких перегрузок ЦП, вызванных процессом SNMP, и частота переполнений значительно снизилась.

    Связанная информация

    Общие сведения об отброшенных пакетах и ​​непереданном трафике с помощью команд show | Обзор для Junos OS

    Начиная с Junos OS Release 14.2, пакеты, требующие для перенаправления на соседний сетевой элемент или соседнее устройство на пути маршрутизации может быть сброшено устройством из-за нескольких факторы.Некоторые из причин такой потери трафика или блокировки при передаче пакетов данных учитываются перегруженные системные условия, профили и политики, ограничивающие полосу пропускания или приоритет трафика, перебои в работе сети или сбой из-за физических повреждений кабеля. Ты можешь используйте ряд команд показа для определения и анализа статистических счетчики и метрики, относящиеся к любой потере трафика, и принимают соответствующие корректирующая мера. Поля, отображаемые в выводе шоу команды помогают в диагностике и отладке производительности сети и проблемы эффективности управления трафиком.

    Следующие показывают команды и связанные поля. применимо для отброшенных пакетов, позволяет просматривать и анализировать некоторые параметров системы на наличие ошибок или сбоев в переданных пакеты.

    Показать расширенные интерфейсы - Показать ввод и ошибки или отбрасывания выходных пакетов. Ниже приведены некоторые из интерфейсов , расширенные входные счетчики и их определения.

    Ниже приведены определения некоторых выходных счетчиков. для показать интерфейсы расширенные :

    Ниже приведены определения некоторых счетчиков очередей. для показать расширенные интерфейсы (как исходящие, так и входящие).Сюда входит номер очереди CoS и связанный с ним настроенный пользователем имя класса пересылки и отображается на интерфейсах IQ2.

    Ошибки

    Сумма входящей фрейм завершается и ошибки FCS.

    Капли

    Количество пакетов отброшен входной очередью ASIC диспетчера ввода-вывода. Если интерфейс насыщено, это число увеличивается один раз для каждого пакета, который сброшен КРАСНЫМ механизмом ASIC.

    Ошибки кадрирования

    Номер пакетов, полученных с неверной контрольной суммой кадра (FCS).

    Рунц

    Количество кадров полученные, которые меньше порогового значения.

    Отбрасывание с учетом политики

    Номер кадров, от которых входящий пакет соответствует коду, который отброшен, потому что они не были признаны или не представляли интереса. Обычно это поле сообщает протоколы, которые ОС Junos не обрабатывает.

    L3 незавершенный

    Номер входящих пакетов, отброшенных из-за того, что они не прошли уровень 3 (обычно IPv4) проверки заголовка.Например, рамка с меньшим более 20 байтов доступного IP-заголовка отбрасываются. L3 неполный ошибки можно игнорировать, настроив оператор ignore-l3-incompletes .

    Ошибки канала L2

    Номер иногда программное обеспечение не находило допустимый логический интерфейс для входящий кадр.

    Таймауты несоответствия L2

    Количество неправильно сформированных или коротких пакетов, вызвавших входящий пакет. обработчик, чтобы отбросить фрейм как нечитаемый.

    Ошибки FIFO

    Номер ошибок FIFO в направлении приема, о которых сообщает ASIC на ПОС. Если это значение ненулевое, возможно, PIC неисправен.

    Ошибки ресурсов

    Сумма капель передачи.

    Несущие переходы

    Количество переходов интерфейса из нижнего положения в верхнее положение. этот номер обычно не увеличивается быстро, увеличивается только тогда, когда кабель отключен, удаленная система выключается, а затем включается, или другое возникает проблема.Если количество переходов несущей быстро увеличивается (возможно, раз в 10 секунд), кабель, удаленная система, или PIC или PIM неисправны.

    Ошибки

    Сумма исходящей фрейм завершается и ошибки FCS.

    Капли

    Количество пакетов отброшен очередью вывода ASIC диспетчера ввода-вывода. Если интерфейс насыщено, это число увеличивается один раз для каждого пакета, который сброшен КРАСНЫМ механизмом ASIC.

    Столкновения

    Количество Коллизии Ethernet. PIC Gigabit Ethernet поддерживает только полнодуплексный режим. операции, поэтому для PIC Gigabit Ethernet этот номер всегда должен остается 0. Если он не равен нулю, это ошибка программного обеспечения.

    Старые пакеты

    Номер пакетов, которые оставались в SDRAM общего пакета так долго, что система автоматически очистил их. Значение в этом поле никогда не должно увеличиваться. Если это так, скорее всего, это ошибка программного обеспечения или, возможно, неисправность. аппаратное обеспечение.

    Ошибки FIFO

    Номер ошибок FIFO в направлении отправки, как сообщает ASIC на ПОС. Если это значение ненулевое, возможно, PIC неисправен.

    Ошибки CRC ссылки HS

    Количество ошибок на высокоскоростных каналах между ответственными ASIC для работы с интерфейсами маршрутизатора.

    Ошибки MTU

    Количество пакеты, размер которых превышает MTU интерфейса.

    Ошибки ресурсов

    Сумма капель передачи.

    Пакеты в очереди

    Номер пакетов в очереди.

    Переданных пакетов

    Количество переданных пакетов.

    Пакеты без упаковки

    Номер пакетов, отброшенных механизмом RED ASIC.

    показать очередь интерфейсов - Показать класс обслуживания (CoS) информация об очереди для физических интерфейсов.Ниже приведены некоторые из показывает поля вывода очереди интерфейсов и их определения.

    Пакеты в очереди

    Номер пакетов в очереди.

    Переданных пакетов

    Количество переданных пакетов.

    Пакеты без упаковки

    Номер пакетов, отброшенных механизмом RED ASIC.

    Пакеты с удаленным концом

    Количество пакетов, отброшенных из-за отбрасывания хвоста.

    RL-отброшенные пакеты

    Количество пакетов, отброшенных из-за ограничения скорости. Для ограниченных по скорости интерфейсы, размещенные только на MIC, MPC и DPC с расширенной очередью, это статистика не включается в статистику трафика в очереди.

    пакетов с КРАСНЫМ сбросом

    Количество пакетов, отброшенных из-за случайного раннего обнаружения (КРАСНЫЙ).

    На маршрутизаторах M320 и M120 и большинстве маршрутизаторов серии T только отображается общее количество отброшенных пакетов.Для другой серии M маршрутизаторы, а также маршрутизаторы серии MX с улучшенными DPC, серия T маршрутизаторы с улучшенными FPC и все маршрутизаторы серии J, выход классифицирует отброшенные пакеты по следующим категориям:

    • Низкий, не TCP - номер приоритета с низким уровнем потерь. байты, не относящиеся к TCP, отброшены из-за КРАСНОГО.

    • Низкий, TCP - номер приоритета с низким уровнем потерь. Пакеты TCP отброшены из-за КРАСНОГО.

    • Высокий, не TCP - номер приоритета с высокими потерями. пакеты, не относящиеся к TCP, отброшены из-за КРАСНОГО.

    • Высокий, TCP - номер приоритета с высокими потерями. Пакеты TCP отброшены из-за КРАСНОГО.

    показать сводку статистики фабрики класса обслуживания - показать статистику отбрасывания очереди коммутационной фабрики класса обслуживания (CoS). Ниже приводится статистика очереди фабрики для отброшенного трафика:

    Пакеты

    Упавший пакет подсчитывать для очередей с высоким и низким приоритетом.

    байтов

    Отброшенный байт подсчитывать для очередей с высоким и низким приоритетом.

    ппс

    Отброшенных пакетов в секунду подсчитывать для очередей с высоким и низким приоритетом.

    бит / с

    отброшенных бит в секунду подсчитывать для очередей с высоким и низким приоритетом.

    показать статистику трафика pfe fpc —Отображение отбрасывание пакетов, относящееся ко всему FPC. Ниже приведены уровни FPC. статистика отказов оборудования Packet Forwarding Engine:

    Следующая статистика относится к пересылке пакетов. Локальный трафик движка для показать статистику трафика pfe fpc :

    Тайм-аут

    Количество пакетов отклонено из-за тайм-аутов.

    Усеченный ключ

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

    Испытательные биты

    Номер бит для тестирования.

    Ошибка данных

    Количество пакеты отброшены из-за ошибок данных.

    Переполнение стека

    Номер пакетов, отброшенных из-за переполнения стека.

    Обычная браковка

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

    Расширенная утилизация

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

    Неверный интерфейс

    Номер пакетов, отброшенных из-за недопустимых входящих интерфейсов.

    Отпуск инфо-ячейки

    Номер капель информационной ячейки.

    Капли из ткани

    Номер капель ткани.

    Вход локальных пакетов

    Количество входящих пакетов из локальной сети.

    Вывод локальных пакетов

    Количество исходящих пакетов, отправленных на хост в локальной сети.

    Высокие падения программного ввода

    Количество отброшенных входящих пакетов ПО с высоким приоритетом во время передачи.

    Среда ввода программного обеспечения падает

    Количество входящих пакетов ПО среднего приоритета, отброшенных во время передачи.

    Низкое падение напряжения на входе программного обеспечения

    Количество входящих пакетов ПО с низким приоритетом, отброшенных во время коробка передач.

    Выходные данные программного обеспечения сбрасываются

    Количество исходящих пакетов программного обеспечения, которые были отброшены во время передачи.

    Отключение аппаратного ввода

    Количество входящих аппаратных пакетов, которые были отброшены во время передачи.

    Добавить комментарий

    Ваш адрес email не будет опубликован.