Два прыжка VPN на одном Pi: какой маршрут несёт какого партнёра

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

Три назначения, которым нужны разные носители

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

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

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

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

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

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

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

Порядок активации побеждает фиксированное ожидание

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

Ядро выдаёт имена вроде tun0 и tun1 в порядке создания, и этот порядок может меняться между перезагрузками или переподключениями. Привяжите конфигурацию к идентичности, которую предоставляет инструмент, или к имени, которое вы назначаете сознательно. Имя, которое выбираете вы, — договор; имя, которое выбирает ядро, — случайность.

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

Что происходит, когда внешний прыжок умирает

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

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

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

Принимайте каждый слой в том порядке, в котором вы его строили

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

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