Налаштування punchy у Nebula: яке з них виправляє ваш NAT

Два вузли знаходять один одного через маяк і потім не можуть побудувати прямий шлях, а перший інстинкт це ввімкнути кожен параметр punchy. Цей інстинкт дає конфігурацію з трьома змінами і без розуміння, яка з них мала значення. Налаштування відповідають на різні питання: одне підтримує зіставлення, що вже існує, а інше намагається виконати рукостискання у зворотному напрямку. Вирішіть, яке питання у вас, перш ніж торкатися будь-якого з них.

Спершу кінцева точка, потім час

Вузол, який ніколи не з'являється за очікуваною адресою, не буде врятований налаштуванням punch. Перевірте, що маяк знає про вузол і що оголошує його власна конфігурація, бо застаріла адреса bootstrap або приватна адреса, опублікована помилково зводять нанівець будь-який прийом проходження. Підтвердьте також, що сертифікат є довіреним, оскільки недовірена ідентичність зупиняє розмову задовго до того, як NAT стане важливим. Потім перевірте, чи UDP взагалі доходить до маяка. Значення часу це останнє, на що варто дивитися, а не перше.

Запишіть пару кінцевих точок, з якою ви тестуєте, щоб подальші порівняння використовували ті самі вузли, а не дві інші машини.

punch зберігає зіставлення, respond відкриває напрямок

Параметр punch періодично надсилає порожні пакети на адресу нижнього рівня вузла, який уже має тунель. Його мета не блискуча: він не дає NAT зі станом або міжмережевому екрану закрити зіставлення, від якого залежить прямий шлях. Параметр respond змінює те, що відбувається при повідомленні маяка, змушуючи хост спробувати рукостискання назад до вузла, який намагається його досягти. Це різні механізми з різними режимами відмови.

Виберіть punch, коли прямий шлях працює, а потім слабшає. Виберіть respond, коли шлях ніколи не формується в одному напрямку. Увімкнути обидва й сподіватися це спосіб перетворити п'ятихвилинне виправлення на тиждень налаштування.

Затримки вирішують коли, а не чи

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

Залиште їх у спокої, доки механізм не стане правильним. Потім налаштуйте одне і запишіть старе значення.

Коли ретранслятор і є чесна відповідь

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

Вузол-ретранслятор із досяжною адресою дає цим вузлам шлях, який не залежить від успіху проходження. Він витрачає пропускну здатність через цей вузол, тому це рішення про ємність, а не обхідний шлях. Налаштуйте ретранслятор свідомо і перевірте, що вузли можуть до нього дістатися, бо ретранслятор, який сам стоїть за складним NAT, нічого не змінює. Потім припиніть налаштовувати punch для цієї пари, оскільки прямий шлях ніколи не мав з'явитися.

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

Відтворіть умову, що зламалася: залиште пару в простої на той самий інтервал або повторіть послідовність рукостискань, яка раніше не вдавалася. Потім перевірте застосунок між цими двома вузлами, а не запит до маяка. Відповідь маяка доводить шлях керування і нічого не каже про шлях даних.

Запишіть, яке налаштування змінилося, час і чи з'явився прямий шлях або трафік залишився на ретрансляторі. Якщо залишився, відповідь це ретранслятор і замітка про ємність, і це цілком добрий результат. Якщо з'явився, наступне питання чи витримає він годину простою, бо зіставлення, що слабшає, і є та сама проблема, для якої існує punch.