Кратко

  • RFC 2012 определила tcpConnState как read-write. Единственное разрешённое для управляющей станции значение deleteTCB(12) удаляло TCB выбранного соединения и немедленно завершало его на управляемом узле.
  • IPv4-четвёрка и счётчики давали наблюдаемость, но не связывали оператора, разрешение и причину с реакцией приложений, удалённой стороны, длительностью и сервисным результатом.
  • RFC 4022 сохранила действие, добавила типы адресов, отдельную таблицу слушателей и PID, сделала запись необязательной для соответствия и прямо назвала риск отказа в обслуживании.

В одной ячейке сошлись наблюдение и управление

RFC 2012 перечисляла параметры и статистику TCP-движка: алгоритм и пределы таймера повторной передачи, максимум соединений, активные и пассивные открытия, неудачи, сбросы, текущие соединения, сегменты, повторные передачи, ошибки и исходящие RST. tcpConnTable показывала конкретную строку по локальному и удалённому IPv4-адресу и порту.

Но у tcpConnState был MAX-ACCESS read-write. Обычное состояние записать было нельзя; управляющая станция могла установить только deleteTCB(12). Это удаляло Transmission Control Block соответствующего соединения на хосте и немедленно прекращало локальное соединение.

Отправка RST другой стороне оставалась выбором реализации, а RST не доставляется надёжно. Поэтому локальное удаление, удалённое уведомление, реакция приложения, повторная попытка и пользовательский перерыв — разные события. Успешный SET не доказывает их все.

Удалялось содержимое, поддерживавшее соединение

По RFC 793 TCB хранит локальный и удалённый sockets, безопасность и приоритет, указатели на буферы, очередь повторной передачи, текущий сегмент и переменные последовательностей. CLOSED назван фиктивным состоянием: нет TCB — нет соединения.

deleteTCB менял не подпись на панели. Он стирал локальное протокольное состояние. Строка MIB при этом не содержала ID действия, заявку, причину, конкретного человека, владельца приложения или долговечный снимок до и после. После закрытия временная строка исчезала, а четвёрка могла использоваться вновь.

Такое право появилось ещё в RFC 1213. В 1991 году tcpConnState сделали записываемым именно для удаления TCB. RFC 2012 перенесла объекты в SMIv2. Во введении аутентификация, авторизация, контроль доступа и приватность отнесены к административной среде, но раздел безопасности не разобрал сам выключатель.

Изменение счётчика не подписывает причину

После действия может снизиться tcpCurrEstab, вырасти tcpEstabResets или tcpOutRsts. Но первая величина — текущий запас, вторая — набор определённых переходов в CLOSED, третья — отправленные сегменты с RST. Ни одна не является журналом управляющих действий.

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

RFC 4022 уточнила объект и границы возможности

Старая таблица была объявлена устаревшей: она поддерживала только IPv4 и смешивала слушающие точки с соединениями. Новая индексирует обе стороны через InetAddressType, адрес и порт. RFC 4001 вводит адреса с zone index для неоднозначных областей. Слушатели вынесены отдельно и различают wildcard, семейство адресов и конкретную привязку.

Поля процесса позволяют сопоставить соединение или listener с PID и другими MIB хоста. Это лучше отвечает на вопрос «какой процесс», но не «какой человек и какой бизнес-результат». PID может быть нулём, повторно использоваться или иметь только локальный смысл.

deleteTCB(12) остался. Однако заявление о соответствии RFC 4022 разрешает tcpConnectionState только для чтения: запись и deleteTCB не обязательны. Наличие схемы не доказывает capability; capability — полномочие; полномочие — выполнение.

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

Защита сообщения закрывает лишь часть разрыва

RFC 3414 связывает SNMPv3-сообщение с пользователем, защищает целостность и своевременность и допускает конфиденциальность. RFC 3415 отделяет read-, write- и notify-view по модели, имени и уровню безопасности, context и экземпляру.

Это укрепляет путь до агента, но не создаёт заявку, причину, подтверждение приложения, получение RST, клиентский эффект или длительность. Аутентифицируется пользователь, от имени которого создано сообщение, а не обязательно конкретный человек.

Аварийный рычаг может быть нужен. Исторический вывод в другом: наблюдение, разрешение, исполнение и доказанный результат нельзя сводить к одному зелёному ответу. Документ задаёт рычаг; последствия принимает работающая система.

Источники

Границы доказательств

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