Настройки punchy в Nebula: какая из них исправляет ваш NAT

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

Сначала конечная точка, потом время

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

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

punch сохраняет сопоставление, respond открывает направление

Параметр punch периодически отправляет пустые пакеты на адрес нижнего уровня узла, у которого уже есть туннель. Его цель не блестящая: он не даёт NAT с состоянием или межсетевому экрану закрыть сопоставление, от которого зависит прямой путь. Параметр respond меняет то, что происходит при уведомлении маяка, заставляя хост пытаться выполнить рукопожатие обратно к узлу, который пытается его достичь. Это разные механизмы с разными режимами отказа.

Выбирайте punch, когда прямой путь работает, а затем ослабевает. Выбирайте respond, когда путь никогда не формируется в одном направлении. Включить оба и надеяться это способ превратить пятиминутное исправление в неделю настройки.

Задержки решают когда, а не получится ли

Значения задержки сдвигают время: одно относится к пакету, отправленному после уведомления, другое к попытке обратного рукопожатия. Ни одно не делает заблокированное направление рабочим. Изменение обоих сразу уничтожает сравнение, которое вы собирались провести.

Оставьте их в покое, пока механизм не станет правильным. Затем настройте один и запишите старое значение.

Когда ретранслятор и есть честный ответ

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

Узел-ретранслятор с достижимым адресом даёт этим узлам путь, который не зависит от успеха прохождения. Он расходует пропускную способность через этот узел, поэтому это решение о ёмкости, а не обходной путь. Настройте ретранслятор осознанно и проверьте, что узлы могут до него добраться, потому что ретранслятор, который сам находится за трудным NAT, ничего не меняет. Затем прекратите настраивать punch для этой пары, поскольку прямой путь никогда бы не появился.

Проверьте неудачную пару после простоя

Воспроизведите условие, которое сломалось: оставьте пару в простое на тот же интервал или повторите последовательность рукопожатий, которая раньше не удавалась. Затем проверьте приложение между этими двумя узлами, а не запрос к маяку. Ответ маяка доказывает путь управления и ничего не говорит о пути данных.

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