Кратко

  • REQ-7 RFC 5382 запрещает TCP NAT одновременно выдавать одно отображение внешнего адреса и порта разным внутренним конечным точкам.
  • Перегрузка работает лишь пока удалённые цели различаются. При одной общей цели публичные четырёхкомпонентные идентификаторы совпадают, а при failover или утрате журнала скрытый различитель может исчезнуть ещё раньше.

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

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

При обычном TCP-отображении внутренний адрес и порт получают внешний адрес и порт. Обратный пакет по публичному tuple сопоставляется с одним внутренним получателем. При port overloading два разных внутренних tuple получают одну и ту же внешнюю пару. Пока они разговаривают с разными серверами, NAT добавляет удалённый адрес и порт к скрытому ключу.

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

RFC 5382 описывает эту коллизию в разделе 7.1 и формулирует REQ-7: NAT не должен применять port overloading для TCP. Требование защищает не только первый узел. Оно уменьшает объём неявного контекста, который должен пережить переключение, расследование и обновление программного обеспечения.

Состояние, проекция и результат — разные вещи

Запись NAT является локальным объектом. Публичный адрес и порт — её внешняя проекция. Пакеты демонстрируют работу механизма. Завершённая операция приложения является более поздним результатом. Успех одного слоя не передаёт полномочия следующему.

Наличие строки на резерве не доказывает, что она однозначна. Ответ на SYN не доказывает сохранение прикладного сеанса. Зелёный health check узлов не доказывает, что конкретная связь пережила смену владельца состояния.

Эта граница особенно важна при перегрузке. Система может честно реплицировать все поля своей внутренней схемы и всё равно нарушать ожидание TCP, если одна внешняя идентичность одновременно обещана двум внутренним источникам. Проблема не сводится к качеству копирования; исходный объект уже содержит конфликт прав.

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

Независимое отображение не разрешает совместное владение

RFC 5382 требует endpoint-independent mapping для TCP. Один внутренний tuple может использовать одинаковое внешнее отображение при общении с разными удалёнными сторонами. Владелец остаётся один, поэтому такая повторная эксплуатация поддерживает непрерывность.

Перегрузка добавляет другого внутреннего владельца. Теперь для различения нужен удалённый peer. Это принципиально иной контракт. Один владелец через несколько направлений и несколько владельцев под одним именем нельзя сводить к общей шкале «степень повторного использования».

Фильтрация также не исправляет конфликт. Она отвечает, каким внешним источникам позволено посылать обратный трафик. Если отображение имеет двух внутренних получателей, разрешение пакета не говорит, кому его доставить. Существующая статья BTW уже отделяет NAT64 mapping от filtering. Здесь рассматривается предшествующая гарантия: имя должно указывать на одного получателя до применения политики доступа.

Эти ответы следует хранить отдельно: кто получил отображение; какие peers допущены; какой TCP-сеанс установился; какой запрос приложения завершился. Идентичные счётчики не делают их взаимозаменяемыми.

Это не crossed SYN

RFC 5382 известна и требованиями для simultaneous open. Два peer одновременно отправляют SYN, сегменты пересекаются, и полная машина состояний TCP может установить одно соединение. Упрощённый NAT иногда принимал этот допустимый путь за нежелательный входящий трафик. Этой теме и шестисекундному окну посвящён отдельный материал BTW.

В port overloading два внутренних клиента обычно обращаются к третьей стороне. Их роли не меняются. Коллизия возникает потому, что переводчик дал двум источникам одну публичную проекцию. Продление ожидания входящего SYN не создаёт отсутствующее второе отображение.

Различаются и журналы. Для simultaneous open важны состояния SYN-SENT и SYN-RECEIVED, номера последовательности и порядок пакетов. Для REQ-7 важен акт выделения: внутренний tuple, внешний tuple, удалённый tuple, протокол, время, версия алгоритма и узел-владелец. Общий диагноз «NAT потерял соединение» не показывает, какая власть была применена неверно.

Редкий IPv4 не делает идентичность бесплатной

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

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

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

Планирование вправе менять размер пула, блоки портов, admission control и стратегию IPv6. Оно не вправе превращать уникальность в опциональную функцию ради красивой плотности. Иначе цена вернётся в виде трудно воспроизводимых сбоев, ложной атрибуции и более тяжёлого failover.

Hairpinning проверяет сохранение внешнего имени

REQ-8 требует TCP hairpinning и внешнего адреса с портом в качестве источника для завернутого внутрь пакета. Два внутренних приложения, знающие друг друга по публичным отображениям, должны увидеть ожидаемого peer даже на внутреннем пути.

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

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

Ошибка не получает право удалить сеанс

REQ-9 рекомендует переводить ICMP Destination Unreachable. REQ-10 запрещает прекращать отображение или TCP-соединение только из-за ICMP. Сообщение несёт свидетельство о пути, но не становится полномочием удалить состояние.

Таймер также не доказывает смерть endpoint. RFC задаёт минимальные периоды, если активность определить нельзя. Другой материал BTW разбирает неоднозначность тишины и keepalive. Для REQ-7 важна более узкая мысль: действующее отображение не становится свободным для одновременной выдачи лишь из-за отсутствия недавних пакетов.

ALG создаёт дополнительный долг состояния. Если NAT меняет TCP sequence numbers, он должен правильно обрабатывать SACK. Каждое скрытое преобразование обязано оставаться согласованным. При port overloading ещё до этого неизвестно, какому владельцу и пространству последовательности принадлежит пакет.

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

Испытание переключением и общей целью

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

Затем выполняется failover. Сохраняются внутренний, внешний и удалённый tuple, протокол, время создания, refresh и удаления, версия политики, идентификатор узла и эпоха состояния. Пакеты SYN, SYN-ACK и ACK связываются с этими записями. Отдельная операция приложения показывает, продолжилась ли полезная работа.

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

Для атрибуции публичная пара значима лишь вместе с точным временным окном. Если восстановление требует удалённого peer, ограничение следует явно указывать. REQ-7 сокращает риск: у одного живого TCP-отображения не должно быть двух одновременных внутренних владельцев.

Источники