Meraki VPN за NAT разрушает Bitbucket Git на WSL2 (Ubuntu 20) на Windows 10.

Содержание

Вопрос или проблема
Ответ или решение
Теория
Пример
Применение
Заключение

Вопрос или проблема

Я подключаюсь к двум VPN Meraki из Windows 10 Pro 10.0.19042 Build 19042:

Один, который не находится за NAT — когда я включаю его, я могу спокойно выполнять git clone [...] или git fetch [...].
Второй, который находится за NAT — когда я подключаюсь и выполняю git fetch, появляется сообщение об ошибке: “fatal: unable to access ‘https://bitbucket.org/[project]/[project-name].git/’: gnutls_handshake() failed: Error in the pull function.“

Чтобы заставить второй VPN работать, я выполнил следующие команды:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent" /v AssumeUDPEncapsulationContextOnSendRule /t REG_DWORD /d 2 /f
reg add "HKLM\System\CurrentControlSet\Services\Rasman\Parameters" /v AllowL2TPWeakCrypto /t REG_DWORD /d 1 /f
reg add "HKLM\System\CurrentControlSet\Services\Rasman\Parameters" /v ProhibitIpSec /t REG_DWORD /d 0 /f
Кроме того, необходимо было отключить IPv6.

Это заставило VPN работать на Windows, но не на Linux внутри сессии WSL2.

Есть какие-нибудь предложения? Большое спасибо!

Проблема заключалась в несоответствии между MTU VPN и MTU Linux под WSL2.

Это можно выявить с помощью двух команд:

Windows PowerShell (запущен от имени администратора)

netsh interface ipv4 show subinterfaces

Обратите внимание на первую строку — она показывает, какой размер MTU разрешен в вашем VPN.

Консоль Linux (внутри WSL2)

ip addr

Обратите внимание на строку, начинающуюся с ‘eth0’ — ее MTU должно соответствовать или быть ниже, чем у предыдущей.

В моем случае MTU в Linux было выше.

Решение

Следующая команда мгновенно решает проблему:

sudo ip link set dev eth0 mtu 1400 (обновите значение MTU, чтобы соответствовать вашему VPN)

Я добавил это в мой ~/.bashrc и добавил /usr/sbin/ip в sudoers NOPASSWD для моего аккаунта.

Лучшее решение

Пока что мне не удалось использовать ни один из стандартных инструментов Linux для изменения MTU при запуске Linux внутри WSL2 (и таким образом избежать добавления его в .bashrc).

rc-local не работает под WSL2
/etc/dhcp/dhcpclient.conf не передает изменения в default interface-mtu или supersede interface-mtu
netsh interface ipv4 set subinterface "vEthernet (WSL)" mtu=1400 store=persistent не влияет на Linux
/etc/netplan не работает внутри WSL2

Если вы найдете способ, я был бы очень рад видеть его здесь!

Мое решение было следующим:

sudo ip link set dev eth0 mtu 1350

НЕ:

sudo ip link set dev eth0 mtu 1400

Проверьте, понизив значение MTU, чтобы адаптироваться под настройки вашей сети.

Это не ответ, скорее, дополнение к ответу @RAIMUNDOS54. Хотел бы иметь 50 репутации здесь, чтобы комментировать.

Похоже, это какой-то баг TLS (специально GNU TLS?), у которого есть несколько обходных путей. Когда его видели с exim4 при подключении к Postfix https://serverfault.com/a/1175182/1243895, удалось исправить баг… видимо, на лету, внутри одного TCP-соединения. Я не знаю достаточно, чтобы дать больше деталей о том, как это сработало.

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

Ответ или решение

Теория

При работе с VPN-соединениями, особенно в случаях, когда VPN находится за NAT (Network Address Translation), часто возникают проблемы, связанные с конфигурацией сети. Одной из таких проблем может быть несовпадение значений MTU (Maximum Transmission Unit) — максимального размера пакета, который может передаваться по сети без фрагментации. В случае VPN-за-NAT это может привести к проблемам с передачей данных из-за невозможности VPN туннеля адекватно маршрутизировать пакеты.

В процессе работы с системами, такими как Windows Subsystem for Linux 2 (WSL2), данная проблема может быть еще более заметной из-за различий в сетевых настройках между хостом Windows и внутренней системой Linux. Ваша текущая задача — правильно конфигурировать сеть обеих систем, чтобы избежать ошибок, связанных с TLS (Transport Layer Security), например, ошибок при использовании команд git fetch или git clone.

Пример

Вы отметили, что при использовании Meraki VPN, который находится за NAT, при выполнении команды git fetch возникала ошибка: "gnutls_handshake() failed: Error in the pull function." Это указывает на сложность при установлении защищенного соединения через TLS. При этом на другой VPN, который не находится за NAT, всё работает исправно.

Вы обнаружили, что проблема связана с несовпадением величин MTU. Изменение MTU в WSL2 на меньшее значение, чем в Windows, решило проблему. Установив MTU интерфейса eth0 в WSL2 на значение 1350, вы смогли восстановить нормальную работу команды git fetch.

Применение

Проверка значений MTU:
- На Windows используйте команду netsh interface ipv4 show subinterfaces для проверки текущего значения MTU на VPN.
- В командной строке WSL2 используйте ip addr для проверки установленного значения MTU на сетевом интерфейсе eth0.
Изменение MTU на WSL2:
Если вам требуется установить меньший MTU, выполните команду sudo ip link set dev eth0 mtu 1350. Это решит проблему несовпадения MTU между системой WSL2 и вашим VPN.
Автоматизация изменения MTU:
- Чтобы изменения MTU не требовалось вводить вручную при каждом старте системы, добавьте команду для изменения MTU в файл ~/.bashrc.
- Чтобы автоматизировать выполнение команды ip, можно добавить ее в файл sudoers с параметром NOPASSWD.
Другие возможные настройки:
- На текущий момент стандартные инструменты для изменения MTU на старте Linux в WSL2, такие как rc-local, netplan, или конфигурации DHCP не работают из коробки по различным причинам. Возможно, в будущем будут разработаны более интегрированные решения для настройки сети в WSL2.

Заключение

Работа с VPN, особенно в окружениях Windows с использованием WSL2, может требовать различных настроек, обеспечивающих стабильную работу приложений через сети, защищенные VPN. Основным вопросом в данном случае была настройка MTU, что является важной частью конфигурации сети. Изменение MTU решает непосредственные проблемы и предоставляет временное устранение последствий. Следует следить за обновлениями программного обеспечения и возможными изменениями в сетевой инфраструктуре, чтобы оптимизировать и автоматизировать данную процедуру в будущем.