Диагностика проблем с WireGuard с помощью Tcpdump [Часть 2]

B3. На принимающем хосте — получение зашифрованного пакета

Третья строка, которую вы должны увидеть в tcpdump на Host β, выглядит так:

19:47:20.753831 eth0  In  IP 198.51.100.1.51821 > 203.0.113.2.51822: UDP, length 96

Эта запись означает, что Host β получил первый зашифрованный пакет данных WireGuard от публичного адреса Endpoint A 198.51.100.1 на свой WAN-адрес 203.0.113.2 и порт 51822. Пакет пришёл на интерфейс eth0.

Полезная нагрузка этого пакета — это исходный TCP-пакет из записи A1, зашифрованный и упакованный в UDP. Если на Endpoint A вы видите запись A4 (и длина пакета там не равна 148 байтам), то соответствующая запись здесь должна появляться обязательно.

Признаки проблемы

Неверная длина пакета

Длина этого пакета зависит от зашифрованных данных. Но если она ровно 148 байт, скорее всего, это не зашифрованный пакет данных, а очередная попытка handshake — то есть запись B1.

Если WireGuard на Endpoint A не получает успешный ответ на handshake, вы можете увидеть примерно 20 записей B1 с интервалом около 5 секунд — WireGuard будет снова и снова пытаться инициировать соединение с Host β.

Если эти записи перемежаются соответствующими B2 — вероятно, проблема в фаерволе или маршрутизации между Host β и Endpoint A (см. раздел A3).

Если записей B2 вообще нет — скорее всего, проблема либо в фаерволе на Host β, либо в конфигурации WireGuard на нём (см. раздел B1).

B4. На принимающем хосте — после расшифровки пакета

Четвёртая строка, которую вы должны увидеть в tcpdump на Host β, выглядит так:

19:47:20.753857 wg0   In  IP 10.0.0.1.45734 > 192.168.200.22.80: Flags [S], seq 1045811890, win 62167, options [mss 1380,sackOK,TS val 133588375 ecr 0,nop,wscale 6], length 0

Эта запись должна зеркалить исходную A1 на Endpoint A. Она показывает, что Host β получил первый пакет данных через WireGuard-туннель и успешно его расшифровал.

Вы должны увидеть TCP-пакет, пришедший через интерфейс wg0, от WireGuard-адреса Endpoint A 10.0.0.1 к LAN-адресу Endpoint B 192.168.200.22 на порт 80.

Признаки проблемы

Нет записи в tcpdump

Если запись B3 есть (то есть зашифрованный пакет пришёл), а этой строки нет, значит, проблема в конфигурации WireGuard.

Выполните wg на Host β и проверьте, что в настройке AllowedIPs для peer’а Endpoint A указан WireGuard-адрес Endpoint A 10.0.0.1.

B5. На принимающем хосте — пересылка пакета

Пятая строка, которую вы должны увидеть в tcpdump на Host β, выглядит так:

19:47:20.753880 eth1  Out IP 192.168.200.2.45734 > 192.168.200.22.80: Flags [S], seq 1045811890, win 62167, options [mss 1380,sackOK,TS val 133588375 ecr 0,nop,wscale 6], length 0

По сути, это тот же пакет, что и в B4, но теперь он уходит через LAN-интерфейс Host β — eth1.

Если вы используете NAT на Host β для маскарадинга трафика от Endpoint A (как в этом примере), то исходный IP-адрес должен измениться: вместо WireGuard-адреса Endpoint A 10.0.0.1 вы увидите LAN-адрес Host β 192.168.200.2.

Примечание

В конфигурации WireGuard Hub-and-Spoke, где Endpoint A использует Host β как центральный хаб для пересылки соединений к другим WireGuard-узлам, в этой записи пакет должен уходить через интерфейс wg0, а не eth1. И обычно в таком сценарии NAT не используется — исходный IP останется 10.0.0.1.

Примечание

В конфигурации WireGuard Point-to-Point, где Endpoint A подключается к сервису, запущенному непосредственно на Host β (а не через него к другим хостам), этой записи — как и B6 — не будет. Следующей записью на Host β станет B7.

Признаки проблемы

Нет записи в tcpdump

Если B4 есть, а этой строки нет, значит, на Host β либо проблема с фаерволом, либо с маршрутизацией.

Сначала выполните:

sysctl net.ipv4.conf.all.forwarding

Значение должно быть 1 — это означает, что IPv4 forwarding включён.

Если forwarding включён, проверьте фаервол Host β:

• iptables-save
• nft list ruleset

Убедитесь, что разрешён как минимум форвардинг новых соединений к TCP-порту 80 Endpoint B (192.168.200.22) через интерфейс eth1, от WireGuard-адреса Endpoint A 10.0.0.1, пришедших через интерфейс wg0.

Если дело не в фаерволе, выполните:

ip route get 192.168.200.22

и убедитесь, что:

• у Host β есть маршрут до Endpoint B,
• этот маршрут выходит через eth1.

Неверный исходный адрес

Если вы ожидаете использовать SNAT (маскарадинг), исходный адрес между B4 и B5 должен измениться. В нашем примере 10.0.0.1 должен преобразоваться в 192.168.200.2.

Если трансляция происходит неправильно или не происходит вовсе — проблема в правилах фаервола. Проверьте их через iptables-save или nft list ruleset.

Неверный адрес назначения

Если вы используете DNAT (port forwarding), адрес назначения должен измениться между B4 и B5. В этом примере DNAT не используется, поэтому изменений быть не должно.

Если трансляция выполняется некорректно — снова ищите проблему в правилах фаервола Host β.

B6. На принимающем хосте — пересылка ответного пакета

Шестая строка, которую вы должны увидеть в tcpdump на Host β, выглядит так:

19:47:20.754071 eth1  In  IP 192.168.200.22.80 > 192.168.200.2.45734: Flags [S.], seq 2143248836, ack 1045811891, win 62643, options [mss 1460,sackOK,TS val 659394353 ecr 133588375,nop,wscale 6], length 0

Здесь показан ответ от Endpoint B: новый пакет приходит на LAN-интерфейс Host β eth1 с IP-адреса 192.168.200.22.

Если вы используете NAT на Host β (как в этом примере), пакет будет адресован на LAN-адрес Host β 192.168.200.2. Между B5 и B6 источник и назначение должны быть ровно поменяны местами.

Примечание

В конфигурации Hub-and-Spoke, где Endpoint A использует Host β как центральный WireGuard-хаб для соединений с другими WireGuard-узлами, между B5 и этой записью вы должны увидеть как минимум ещё два пакета — зашифрованные WireGuard-пакеты между Host β и Endpoint B.

Например, если Endpoint B находится не в Site B LAN, а где-то в интернете (скажем, 192.0.2.3 с портом 51823), между B5 и B6 вы увидите что-то вроде:

19:47:20.753991 eth0  Out IP 203.0.113.2.51822 > 192.0.2.3.51823: UDP, length 176
19:47:20.754002 eth0  In  IP 192.0.2.3.51823 > 203.0.113.2.51822: UDP, length 96

Также возможны дополнительные пакеты handshake между Host β и Endpoint B, если с последнего обмена прошло 2 минуты и больше. Если дополнительных записей нет, возможно, само WireGuard-соединение между Host β и Endpoint B не работает — в этом случае стоит остановиться и сначала отдельно его отладить.

В hub-and-spoke-сценарии эта запись должна приходить через wg0, а не eth1. И NAT обычно не используется, поэтому адрес назначения будет 10.0.0.1.

Примечание

В конфигурации Point-to-Point, где Endpoint A подключается к сервису непосредственно на Host β, а не через него к другим хостам, записей B5 и B6 не будет. Следующей записью станет B7.

Признаки проблемы

Нет записи в tcpdump

Сначала перепроверьте B5. Если там всё выглядит корректно, проблема либо в фаерволе, либо в маршрутизации внутри Site B LAN (или в сети между Host β и Endpoint B, если это не одна LAN), либо на самом Endpoint B.

Если используется NAT (как в этом примере), для Site B LAN трафик от Endpoint A должен выглядеть так, будто он приходит с 192.168.200.2.

В этом случае проверьте:

• что фаерволы между Host β и Endpoint B разрешают новые соединения от 192.168.200.2 к TCP-порту 80 на 192.168.200.22;
• что локальный фаервол Endpoint B разрешает входящие соединения на LAN-интерфейсе от 192.168.200.2 к TCP-порту 80.

Если NAT не используется, для Site B LAN трафик будет выглядеть как исходящий от 10.0.0.1.

Тогда нужно проверить:

• что в Site B LAN настроена маршрутизация 10.0.0.1 обратно к 192.168.200.2 (Host β);
• что фаерволы между Host β и Endpoint B разрешают новые соединения от 10.0.0.1 к TCP-порту 80 на 192.168.200.22;
• что локальный фаервол Endpoint B разрешает входящие соединения от 10.0.0.1 к TCP-порту 80.

B7. На принимающем хосте — перед шифрованием ответного пакета

Седьмая строка, которую вы должны увидеть в tcpdump на Host β, выглядит так:

19:47:20.754079 wg0   Out IP 192.168.200.22.80 > 10.0.0.1.45734: Flags [S.], seq 2143248836, ack 1045811891, win 62643, options [mss 1460,sackOK,TS val 659394353 ecr 133588375,nop,wscale 6], length 0

По сути, это тот же пакет, что и в B6, но теперь он уходит через WireGuard-интерфейс wg0.

Если используется NAT на Host β (как в этом примере), адрес назначения будет снова изменён на WireGuard-адрес Endpoint A 10.0.0.1. Если NAT не используется, этот адрес уже был бы 10.0.0.1 на этапе B6.

Примечание

В конфигурации Point-to-Point, где Endpoint A подключается к сервису, запущенному непосредственно на Host β, эта запись должна идти сразу после B4. Если её нет, значит, проблема в фаерволе на Host β.

Проверьте правила фаервола с помощью:

• iptables-save
• nft list ruleset

Они должны как минимум разрешать входящие соединения от WireGuard-адреса Endpoint A 10.0.0.1 через интерфейс wg0 к TCP-порту 80 (или к тому сервису, к которому вы подключаетесь).

Признаки проблемы

Нет записи в tcpdump

Если запись B6 есть, а этой строки нет — проблема в фаерволе на Host β.

Проверьте правила фаервола (iptables-save, nft list ruleset). Они должны разрешать как минимум форвардинг установленных соединений к WireGuard-адресу Endpoint A 10.0.0.1 через интерфейс wg0, от LAN-адреса Endpoint B 192.168.200.22, пришедших через eth1.

Неверный интерфейс

Если в этой записи указан интерфейс, отличный от wg0, значит, проблема с маршрутизацией: Host β не отправляет трафик к WireGuard-адресу Endpoint A 10.0.0.1 через WireGuard.

Проверьте маршруты и policy routing с помощью ip route и ip rule.

B8. На принимающем хосте — отправка зашифрованного ответного пакета

Восьмая строка, которую вы должны увидеть в tcpdump на Host β, выглядит так:

19:47:20.754110 eth0  Out IP 203.0.113.2.51822 > 198.51.100.1.51821: UDP, length 96

Эта запись показывает, что Host β отправляет зашифрованный пакет данных WireGuard через WAN-интерфейс eth0 со своего публичного IP 203.0.113.2 обратно на публичный IP Endpoint A 198.51.100.1.

Полезная нагрузка этого пакета — TCP-пакет из записи B7, зашифрованный и упакованный в UDP.

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

A5. На инициирующем хосте — получение зашифрованного ответного пакета

Пятая строка, которую вы должны увидеть в tcpdump на Endpoint A, выглядит так:

19:47:20.754497 wlan0 In  IP 203.0.113.2.51822 > 192.168.1.11.51821: UDP, length 96

Эта запись показывает, что Endpoint A получил зашифрованный пакет данных WireGuard на UDP-порт 51821 интерфейса wlan0 от публичного IP Host β 203.0.113.2.

Полезная нагрузка этого пакета — TCP-пакет из записи B7, зашифрованный и упакованный в UDP.

Признаки проблемы

Неверная длина пакета

Длина этого пакета зависит от данных внутри. Но если она ровно 92 байта, скорее всего, это не зашифрованный пакет данных, а очередной ответ на handshake — то есть запись A3.

Если вы видите несколько записей A2 (инициация handshake), перемежающихся с несколькими A3 (ответы на handshake), значит, проблема в фаерволе на Endpoint A.

Проверьте правила с помощью:

• iptables-save
• nft list ruleset

Убедитесь, что фаервол Endpoint A разрешает входящие пакеты для установленных соединений на интерфейсе wlan0, как минимум для UDP-порта 51821, от публичного IP Host β 203.0.113.2.

A6. На инициирующем хосте — после расшифровки пакета

Шестая строка, которую вы должны увидеть в tcpdump на Endpoint A, выглядит так:

19:47:20.754516 wg0   In  IP 192.168.200.22.80 > 10.0.0.1.45734: Flags [S.], seq 2143248836, ack 1045811891, win 62643, options [mss 1460,sackOK,TS val 659394353 ecr 133588375,nop,wscale 6], length 0

Эта запись должна зеркалить B7 с Host β. Она показывает, что Endpoint A получил первый ответный пакет данных через WireGuard-туннель и успешно его расшифровал.

Здесь должен быть TCP-пакет, пришедший через интерфейс wg0: от порта 80 LAN-адреса Endpoint B 192.168.200.22 к WireGuard-адресу Endpoint A 10.0.0.1.

Признаки проблемы

Повторяющиеся записи

Если вы видите одни и те же записи A5 и A6, повторяющиеся несколько раз (и больше ничего, кроме keepalive-пакетов), значит, проблема в фаерволе на Endpoint A.

Проверьте правила фаервола на Endpoint A с помощью iptables-save и nft list ruleset. Они должны как минимум разрешать установленные соединения, входящие на WireGuard-интерфейс wg0, от LAN-адреса Endpoint B 192.168.200.22.

Приложение ничего не получает

Если эта строка в tcpdump выглядит правильно, но приложение (например, curl) при этом пишет, что ничего не получило, это снова указывает на проблему с фаерволом на Endpoint A.

Проверьте правила через iptables-save и nft list ruleset. Они должны разрешать как минимум установленные соединения, приходящие на wg0 от 192.168.200.22.

Keepalive-пакеты

Остальные строки в примере вывода tcpdump либо показывают дополнительные UDP-пакеты WireGuard, которыми обмениваются Endpoint A и Host β, либо исходные TCP-пакеты, которые передаются внутри туннеля. Когда соединение WireGuard установлено и работает, такого трафика будет много.

Единственное исключение — последние строки в выводе для Endpoint A и Host β. Это небольшие keepalive-пакеты, которые можно увидеть, когда соединение WireGuard в остальном неактивно.

В выводе tcpdump на Endpoint A последняя строка такая:

19:47:30.984489 wlan0 Out IP 192.168.1.11.51821 > 203.0.113.2.51822: UDP, length 32

А в выводе на Host β — такая:

19:47:30.984753 eth0  In  IP 198.51.100.1.51821 > 203.0.113.2.51822: UDP, length 32

Эти пакеты легко узнать: это UDP-пакеты длиной 32 байта, отправляемые между портами WireGuard 51821 и 51822.

Такие пакеты появляются только если handshake ранее уже был успешно завершён. WireGuard автоматически отправляет keepalive через несколько секунд после любой вспышки трафика с одной из сторон — чтобы удержать соединение открытым через stateful-фаерволы на случай, если у второй стороны ещё остались данные для отправки.

Кроме того, если для peer’а настроен параметр PersistentKeepalive, WireGuard будет периодически отправлять keepalive-пакет с этой стороны соединения каждые X секунд после последнего отправленного пакета (данных или keepalive), где X — значение PersistentKeepalive. Таким образом соединение поддерживается открытым постоянно.