Кратко

  • RFC 4084 различает веб-связность, клиентский доступ, доступ с межсетевым экраном и полную связность, не объявляя один продукт достойным, а другой плохим. Её предмет — раскрытие функций и ограничений.
  • Квитанция возможностей отдельно хранит рекламу, договор, конфигурацию провайдера и воспроизводимое наблюдение. Рабочий обходной туннель не превращается в обязанность провайдера.

Одинаковое название не означает одинаковую сеть

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

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

RFC 4084 была опубликована в 2005 году как BCP 104 именно для устранения такой неопределённости. Она называет веб-связность, клиентский доступ без публичного адреса, клиентский доступ с публичным адресом, связность с управляемым межсетевым экраном и полную интернет-связность. Термины намеренно не носят уничижительного характера. Ограниченный продукт может подходить ограниченной задаче. Документ регулирует язык и информацию, а не ассортимент, который обязан продавать провайдер.

Для покупателя вывод прост: название услуги не может быть актом приёмки. Принимать нужно операции, от которых зависит система.

Адрес, достижимость и разрешение не совпадают

Публичный адрес сам по себе не разрешает сервер. RFC 4084 описывает клиентский доступ с публичным адресом, где большинство VPN работает, но серверы запрещены договором или входным фильтром. Непубличный адрес и NAT обычно ограничивают серверы и многие функции P2P. Термин полной связности несовместим с навязанными провайдером NAT, прокси и ограничениями портов.

Поэтому реестр адресации включает IPv4/IPv6, совместное или отдельное использование, стабильность, внешнюю динамическую маркировку, обратный DNS, точку трансляции, входящую достижимость и владельца настройки. Заказанный клиентом управляемый экран нельзя выдавать за неизбежное свойство канала.

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

Ретранслятор, rendezvous-служба или туннель могут восстановить приложение. Это хорошая инженерная работа. Она не доказывает поддержку входящих сервисов, договорное право на сервер или сохранение поведения после изменения сети.

Четыре колонки вместо одного статуса

Колонка объявлено содержит название продукта, версию, публичное описание и дату. Колонка законтрактовано содержит права на серверы и P2P, стабильность адреса, VPN, почту, фильтры, выбранную клиентом защиту и поддержку.

Колонка настроено описывает подконтрольные провайдеру NAT, входные и выходные фильтры, прокси, перехват, DNS, ICMP, туннели, перенаправление почты и запрошенные клиентом правила. Записи нужна идентичность изменения.

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

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

Почта требует нескольких независимых проверок

RFC 4084 рассматривает обязательный сервер отправки провайдера, блокировку портов к внешним серверам, перенаправление трафика, ограничения POP3/IMAP4 и динамическую маркировку адреса. Рабочая веб-почта не подтверждает ни один из этих путей.

Квитанция отдельно отмечает аутентифицированную отправку, внешний SMTP, удалённое получение, домены отправителя, обратный DNS, репутацию и перенаправление. Для VPN указываются тип, направление, простой, смена адреса и резервный транспорт. Для DNS — возможность произвольного резолвера. Для ICMP — доступная диагностика. Для входящих сервисов — запрет, фильтр, изменение или отсутствие теста.

У ограничения есть заказчик и исполнитель

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

Узкое утверждение полезнее общего: «входящий TCP на этом порту не прошёл из двух независимых сетей; экран клиента такого правила не имеет; договор содержит или не содержит условие провайдера». Такой факт можно проверить и направить правильной команде.

Источники