Как проверить VPN из сети клиента: синхронный захват на роутере и VPS

Пакет ушёл с компьютера в офисе. На роутере он виден, в туннель вошёл, а на VPS его нет. Или наоборот: на VPS он пришёл, ответ ушёл, а на стороне клиента ответа никто не видел. Такая картина выглядит как загадка, но на деле это очень полезный факт: у пакета есть последняя точка, где его видели, и первая, где его уже не было. Между ними и находится место потери. Задача диагностики — не «понять всё про VPN», а честно найти эту пару точек.

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

Один запрос вместо «посмотрим, что там ходит»

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

Поэтому начинаем с выбора пробы. Хорошая проба обладает четырьмя свойствами:

• Короткая. Один запрос и один ответ, а не загрузка файла. Например, одиночный ICMP echo или один TCP-запрос к известному порту.
• Узнаваемая. У неё есть адрес источника, адрес назначения и порт или тип, которых нет у фонового шума.
• Воспроизводимая. Вы можете повторить её по команде и увидеть тот же сценарий.
• Безобидная. Она не несёт пользовательских данных: в содержимом нет ничего, кроме служебного.

Один ping здесь подходит как пример, но не как приговор. ICMP по дороге могут по-разному обрабатывать фильтры, лимиты и правила хоста, поэтому отсутствие ответа на ping само по себе не доказывает, что сеть «блокирует VPN». Лучше иметь пару проб: ICMP и TCP на порт, где на VPS гарантированно слушает простая служба. Если ICMP не проходит, а TCP проходит, вы уже знаете больше, чем знали бы из одного ping.

Пример условный: клиентская машина 192.168.10.25 обращается к VPS по адресу туннеля 10.8.0.1 на TCP-порт 8080. Это нужно только чтобы зафиксировать язык разговора: у пробы есть источник, цель и порт, и все наблюдательные посты будут искать именно их.

Четыре поста и общая шкала времени

Теперь выберем, где смотреть. Для типичной схемы «офисная сеть — роутер с клиентом VPN — VPS на другом конце» естественны три или четыре точки:

1. LAN-интерфейс роутера. Здесь видно, что запрос вообще дошёл от компьютера до роутера и с каким исходным адресом.
2. Интерфейс туннеля на роутере. Здесь запрос уже выходит в туннель, обычно с тем же внутренним адресом источника или после трансляции, если вы её настроили.
3. Публичный интерфейс VPS. Здесь видны внешние пакеты туннеля: они зашифрованы, но адреса, порты и время прохождения заметны.
4. Интерфейс туннеля на VPS. Здесь расшифрованный запрос уже внутри, и можно увидеть, дошла ли проба до нужного адреса и ответила ли служба.

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

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

Практичный приём: запускайте захваты на всех постах заранее, затем выполняйте одну пробу, затем останавливайте всё. Окно захвата получается в десятки секунд, а не в минуты.

Фильтр: смотрим только свой обмен

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

Принципы построения фильтров для каждого поста такие:

• На LAN роутера и на туннельных интерфейсах фильтруйте по адресам пробы: источник и цель, и при необходимости порт. Фильтр по двум адресам отсекает весь прочий офисный трафик.
• На публичном интерфейсе VPS внешний трафик туннеля устроен иначе: это пакеты между публичным адресом роутера и публичным адресом VPS на порту службы VPN. Содержимое внутри зашифровано, поэтому по адресам проб там искать бесполезно. Фильтруйте по адресу клиентской стороны и порту туннеля.
• Ограничьте захват по времени или по числу пакетов. Остановиться по лимиту лучше, чем забыть выключить.
• Если захват идёт долго, используйте кольцевые файлы небольшого размера: старые данные перезаписываются, диск не переполняется.

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

Внешняя передача и трафик внутри туннеля

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

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

Здесь полезно помнить, как WireGuard принимает пакеты. Параметр AllowedIPs, как описано в справке wg(8), задаёт и допустимые адреса входящего трафика от peer, и направления исходящего; IPv4 и IPv6 перечисляются отдельно. Из этого следует практический вывод: внешний пакет может прийти на публичный интерфейс VPS и быть корректно расшифрован, но внутренний адрес источника не попадёт в разрешённый список peer — тогда на туннельном интерфейсе пакета не будет. Для этого случая в таблице ниже есть отдельная строка. Если вы используете другую технологию туннеля, смысл тот же, просто механизм проверки называется иначе.

Ещё одна особенность из той же справки: endpoint peer обновляется по корректно аутентифицированным пакетам. Если за роутером сменился внешний адрес или порт, на VPS после первого же аутентифицированного пакета ответы пойдут на новый адрес. На практике это значит: в захвате внешний адрес клиента может отличаться от того, что вы ожидали, и это не ошибка пробы, а повод сверить адрес роутера на момент теста.

До и после трансляции адресов

Если на роутере включена трансляция адресов (NAT), один и тот же пакет выглядит по-разному в разных точках. На LAN-интерфейсе источник — 192.168.10.25. На интерфейсе туннеля после трансляции источник может оказаться адресом самого туннельного интерфейса роутера. На VPS придёт уже он. Если искать на VPS исходный офисный адрес, вы его не найдёте и можете ошибочно решить, что пакет потерялся.

Чтобы не путаться, заранее выпишите, как должен выглядеть адрес источника в каждой точке. Достаточно маленькой памятки на листе:

• LAN роутера: источник — адрес рабочей станции;
• туннель на роутере: источник — либо адрес станции, либо адрес туннельного интерфейса, в зависимости от настроек;
• туннель на VPS: тот же адрес, что вышел из туннеля роутера;
• публичный интерфейс VPS: адреса роутера и VPS на порту туннеля, без внутренних адресов.

Когда в одной точке адрес совпал с ожиданием, а в следующей нет, смотрите на правила трансляции между этими точками. Если вы выбираете, на чём поднимать клиент — на роутере или на отдельном устройстве, — от этого зависит, где именно возникает трансляция; об этом подробнее в статье VPN на роутере или на устройстве.

Четыре сочетания: таблица вместо инструкции

Возьмём две ключевые точки: туннельный интерфейс на стороне клиента (проба вышла в туннель) и туннельный интерфейс на VPS (проба вошла с другой стороны). Для каждого направления есть четыре сочетания. Добавим сюда публичный интерфейс VPS как промежуточный свидетель.

Строка с тремя «Есть» может показаться скучной, но она сдвигает фокус: запрос дошёл, значит, проблема в ответе. Тогда те же четыре точки читаются в обратном направлении, и нужно проверить, ответила ли служба и ушёл ли ответ из туннеля VPS.

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

Как читать частые подвохи

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

Внешний пакет есть, но только в одну сторону. Роутер отправляет, VPS не отвечает. Тогда либо VPS не принимает (порт, правила хоста), либо принимает, но не аутентифицирует пакет. В первом случае на публичном интерфейсе вы увидите входящий пакет без ответа. Во втором — также входящий и тишину. Различить поможет не захват, а состояние peer на VPS: когда было последнее рукопожатие. Осторожнее с командами вывода конфигурации: по справке wg(8), вывод showconf и машинный dump могут включать секреты, поэтому не вставляйте их в тикеты и чаты. Для диагностики хватает сводного статуса без ключей.

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

Что делать, когда таблица указывает на участок

Таблица даёт участок, а не причину. Следующий шаг — уточнить гипотезу одним изменением и повторить пробу. Не меняйте несколько вещей сразу: тогда вы не узнаете, что помогло. Изменения на живом интерфейсе и в конфигурационном файле — это разные действия: по справке wg(8), правка работающего интерфейса не меняет файл, а применение различий из файла (syncconf) обновляет интерфейс без пересоздания всех peer. Для диагностики это удобно: можно поправить список разрешённых адресов одного peer, не обрывая остальных, и тут же повторить пробу. Но после успешной проверки не забудьте перенести правку в файл, иначе при перезапуске всё вернётся к старому состоянию.

Если нужно временно исключить подозреваемого peer, его можно удалить командой вида wg set ... peer ... remove, где peer указывается открытым ключом. Это разрушающее действие для живой связи, поэтому делайте его только с согласованием и держите под рукой данные для восстановления.

Ресурсы VPS для такой работы

Сам по себе короткий захват с фильтром почти ничего не весит. Тарифу Ba с 1 vCPU, 2 ГБ памяти и 40 ГБ NVMe для разбора пары захватов размером в несколько мегабайт обычно достаточно как для отправной точки, но это ресурс для теста, а не обещание ёмкости: если вы одновременно держите на VPS туннель, пишете файлы и запускаете анализ, проверьте нагрузку на своём сценарии. Root-доступ нужен, чтобы запускать захват на интерфейсах: без него утилиты просто не получат нужных прав. Если вы подбираете VPS под VPN-шлюз с запасом для диагностики, смотрите предложение MAATRIX: там указаны локации UK, US, RU и FR, оплата картой РФ и СБП, а VPS создаётся автоматически за пару минут после оплаты. Для разбора проблем с потерями полезно иметь точку в той локации, которая ближе к клиентской сети, но это вопрос задержки, а не диагностики как таковой.

Когда остановиться

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

Практический порядок завершения:

1. Остановить все захваты по очереди и убедиться, что процессы не висят.
2. Сохранить только выдержки: несколько строк с пробой и ответом с каждого поста, с временем.
3. Удалить файлы полных захватов, если они не нужны для дальнейшей работы, либо убрать их в ограниченное по доступу место.
4. Записать условия эксперимента: адреса пробы, порт, расхождение часов, какие правила трансляции были активны.

Если ответа нет — например, на всех постах пусто, — не продлевайте захват «на всякий случай». Лучше проверить, что проба вообще генерировалась и что фильтр написан верно: частая причина пустых файлов — опечатка в адресе или не тот интерфейс.

Формулировка для тикета

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

TCP-запрос с 192.168.10.25 на 10.8.0.1:8080 виден на LAN и на туннельном интерфейсе роутера, виден как внешний пакет на публичном интерфейсе VPS, но не появляется на туннельном интерфейсе VPS. Часы сверены, расхождение указано, захват ограничен адресами пробы и портом туннеля, содержимое не сохранялось.

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