Кратко

  • RFC 4008 строила управление NAT вокруг интерфейсов, типов сервиса и настраиваемых параметров; RFC 7658 объяснила, почему эта схема не соответствовала многим реализациям.
  • NATV2-MIB сократила общий набор настраиваемых параметров, но расширила наблюдение за логическими экземплярами, адресными областями, абонентами, пулами и состоянием.

Сначала — строка интерфейса

В последовательности настройки, показанной в RFC 4008, менеджер SNMP сперва создаёт запись в natInterfaceTable, указывает уже существующий ifIndex и задаёт, относится ли интерфейс к частной или публичной области. После этого добавляются отображения адресов с тем же индексом, а затем настраиваются стандартные тайм-ауты. Отправной точкой модели становится не правило преобразования, а физический интерфейс, к которому привязывается управление.

В этой схеме есть практичная логика. Пакеты входят в устройство и выходят из него через интерфейсы, а оператор может описывать границы адресных областей именно там. RFC 4008 связала таблицу интерфейсов с таблицей отображений, производными таблицами адресных и портовых привязок и таблицей сессий, соединяющей представления одной сессии в частной и публичной областях. MIB включала статистику и тайм-ауты и предназначалась как для настройки, так и для наблюдения. RFC 4008, разделы 1 и 4

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

Что зафиксировала RFC 7658

RFC 7658 подробно объясняет, почему объекты RFC 4008 были объявлены устаревшими. Алгоритмы NAT и структуры данных заметно различались между реализациями, что приводило к несовместимым параметрам настройки. Лишь немногие реализации могли заявить о полном соответствии. Даже параметры в режиме чтения — например, тайм-ауты — мешали многим заявить хотя бы базовое соответствие. Указанный авторами урок: MIB следует по возможности делать доступной только для чтения и не использовать её для раскрытия всей конфигурации NAT. RFC 7658, раздел 3

Связь с интерфейсами была конкретной архитектурной проблемой. По RFC 7658, многие реализации не отслеживали интерфейс, связанный с преобразованием, либо относили отображение к нескольким интерфейсам. Но ifIndex лежал в основе таблиц интерфейсов, отображений, привязок и сессий в RFC 4008. Если внутренняя модель устройства не содержала такой связи, она не могла естественно заполнить ожидаемые строки. Поэтому авторы заключили, что NAT — логическая функция, которая может быть независимой от интерфейсов.

Категории услуг и список протоколов показывали похожие ограничения. RFC 4008 использовала basicNat, napt, bidirectionalNat и twiceNat; RFC 7658 называет эти категории нечетко определёнными, поскольку реализации могли применять другие категории или вовсе не классифицировать NAT таким образом. Это категории сервиса старой MIB, а не классификация NAT по RFC 3489. Преемник ссылается на термины поведения из RFC 4787. Закрытый список other, ICMP, UDP и TCP с собственными числовыми кодами также неудобен для протоколов вроде DCCP и SCTP. NATV2-MIB использует номера протоколов из реестра IANA.

Не дополнение таблицы, а смена модели

В 2015 году переход оформили двумя документами. RFC 7658 сохранила определения объектов RFC 4008, но присвоила им статус deprecated. RFC 7659 определила NATV2-MIB. Старые идентификаторы не получили новые значения под прежними именами. RFC 7658 RFC 7659

NATV2-MIB предназначалась прежде всего для наблюдения. Информация о конфигурации, доступная для чтения, ограничена тем, что нужно для интерпретации состояния и статистики. Записываемая конфигурация в основном убрана; исключения — управление отправкой уведомлений и квоты ресурсов NAT. Контроль не исчез полностью: защитные лимиты остаются. Но стандарт перестал обещать универсальную панель настройки для разных механизмов преобразования.

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

RFC 7659 также изменила индексацию портовых отображений, чтобы по параметрам пакета, видимым снаружи, было проще найти соответствующую внутреннюю конечную точку. Это средство управления и поиска, а не доказательство личности абонента, доставки пакета или успешной работы приложения. RFC 7659, разделы 2 и 3

RFC 6888 описывает контекст общих ресурсов: абоненты CGN конкурируют за порты и состояние, а ограничения на абонента могут сдерживать чрезмерное потребление общего ресурса. NATV2-MIB позволяет представить часть таких ограничений и связанных с ними показателей. Документы не устанавливают, какие операторы на самом деле использовали эти объекты, какие пороги задавали и к каким результатам это привело. RFC 6888, разделы 4 и 5

Что показывает смена NAT-MIB

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

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

Граница с межсетевым экраном тоже изложена прямо. RFC 4008 и RFC 7658 указывают, что эти MIB не охватывают функции firewall и не должны использоваться для их настройки или мониторинга. Строка NAT-отображения не заменяет правило фильтрации.

Запись управления также не равна результату обслуживания. Настроенный пул не доказывает наличие активного отображения; индекс абонента не подтверждает личность; счётчик требует учёта момента сброса или разрыва непрерывности; уведомление не показывает доставку пакета. NATV2-MIB делает представление состояния более связным, не объединяя конфигурацию, текущую работу, пересылку пакетов, идентификацию и результат приложения в один факт.

Исторический урок конкретен: стандарт управления может стать чрезмерно предписывающим, если выдать локальные настройки реализации за общий интерфейс. RFC 7658 ответила не добавлением полей к интерфейсной таблице, а пересмотром самой единицы моделирования. Преемник сделал меньше настроек универсальными и больше логического контекста наблюдаемым. Вопрос сменился с «какому интерфейсу принадлежит это отображение?» на «какой экземпляр NAT, область, абонент, пул и состояние описывает это наблюдение?»

Источники