Два стрибки VPN на одному Pi: який маршрут несе якого партнера

Дві адреси тунелю на одній маленькій платі виглядають як помилка, і рефлекс — видалити одну. Цей рефлекс ламає те, що мав упорядкувати. Хост із двома стрибками тримає по одній адресі на кожне підключення, і кожну адресу вибирає інший маршрут. Питання, яке варто поставити: який маршрут вибирає який носій для якого призначення, а не скільки адрес існує.

Три призначення, яким потрібні різні носії

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

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

Адреси мають ролі, а не число

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

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

ip -4 addr show
ip -4 route show table all
ip rule show

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

Порядок активації перемагає фіксоване очікування

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

Ядро видає імена на кшталт tun0 і tun1 у порядку створення, і цей порядок може змінюватися між перезавантаженнями чи перепідключеннями. Прив'яжіть конфігурацію до ідентичності, яку надає інструмент, або до імені, яке ви призначаєте свідомо. Ім'я, яке вибираєте ви, — договір; ім'я, яке вибирає ядро, — випадковість.

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

Що відбувається, коли зовнішній стрибок помирає

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

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

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

Приймайте кожен шар у тому порядку, у якому ви його будували

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

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