Запишите путь пакета до настройки VPN

Большинство сборок VPN начинается с клиента и профиля, и к моменту, когда туннель поднят, никто уже не может сказать, какой пакет должен был через него пройти. Первая страница работы дешевле третьего часа отладки: опишите одно предполагаемое соединение от начала до конца, на бумаге, до того как появится файл конфигурации. Упражнение обычно закрывает вопрос, который вы ещё не задали, например: требование — это выход в интернет, удалённый доступ к подсети или канал между двумя площадками.

Одного соединения достаточно для начала. Три страницы топологии обычно скрывают один и тот же недостающий ответ.

Опишите один запрос, а не схему

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

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

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

Следите за ответом раньше запроса

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

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

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

У каждого решения должен быть владелец

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

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

Где значение определяет провайдер, а не вы, скажите это в той же строке. У префикса, делегированного хостинговой компанией, другой процесс изменения, чем у выбранного вами самими. Эта заметка экономит следующему инженеру обращение в поддержку во время инцидента. Она также объясняет, почему одобренное вами изменение не дало эффекта.

Опишите, что ломается и как вы восстанавливаетесь

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

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

Назовите безобидную проверку для каждого этапа

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

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