Спасибо! Я после работы продолжил свое исследование (включая MTU). Как оказалось, все UDP соединения на WireGuard сервер, порты которых выше 1000 (т.е. начиная с 1001) не проходят до моего удаленного сервера через Дом.ру. В ЛК я не нашел настроек Firewall, есть только включить\выключить NAT. Я попробовал переключение NAT, поведение не поменялось. Сейчас все стабильно работает с трехзначным номером порта.
Но в моем случае обе системы Ubuntu (Server и Desktop) и мобильное устройство на iOS. Desktop и iOS перестают работать только если подключение через Дом.ру проходит и оба клиента начинают работать если подключение к серверу я произвожу через мобильную сеть.
Возможно дело в чем-то другом и это просто совпадение…
У меня вчера вечером неожиданно перестали работать все клиенты которые используют VPN WireGuard, провайдер Дом.ру, проблема связана с Handshake .Сервер крутится на DigitalOcean. Попробовал подключиться через мобильного оператора к удаленному серверу - соединение проходит. Вот теперь интересно, не связанны ли эти блокировки с проблемой которая у меня возникла....
Нашел подобные проблемы в Google (на 4pda) и понял, проблема не у меня одного такая оказывается. Некоторые пишут там что CloudFlare WARP отвалился тоже (он работает на основе WireGuard)
Похоже понадобиться поднимать какой-нибудь udptunnel или udp2raw для второго слоя. Но если это возможно сможет решить вопрос "сервер → сервер" или "ПК → сервер" (и то тут вопросы есть для macOS и Windows), то не сможет решить проблему - "мобильное устройство → сервер". Придется какой-нибудь Raspberry Pi организовывать как WIFI точку доступа с этими двумя слоями для VPN, а мобильные устройства к нему цеплять….
У меня тоже была подобная ситуация в macOS при обновлении Wireguard, режим on-demand включен. Это действительно не совсем удобно в использовании. Например, если нужно на короткое время, да или насовсем отключить VPN, нужно заходить в приложение Wireguard, нажимать кнопку редактирования конфигурации, вводить пароль администратора (или отпечаток пальца), затем уже выключать режим on-demand. И потом все тоже самое для включения режима on-demand…
Но в процессе использования этого VPN, я обратил внимание, если в приложении Wireguard включен режим on-demand, то в стандартных настройках сетевых соединений ОС, в интерфейсе Wireguard появляется галочка «Connect on demand», она имеет приоритет над режимом on-demand в приложении Wireguard. Когда мне нужно быстро отключить VPN (или обновить Wireguard), я просто снимаю эту галочку и там-же нажимаю на кнопку «Disconnect», трафик соответсвенно начнёт идти в обход VPN. Когда нужно вернуть VPN, достаточно просто поставить галочку напротив «Connect on demand», соединение само поднимется.
У меня в Ubuntu 14.04 метод с файлом /etc/pam.d/common-auth не сработал, при попытке залогинится через любую учетную запись система отказывалась принимать пароли.
Решилось так, добавил строку auth required pam_google_authenticator.so в конец файла /etc/pam.d/sshd, в файле /etc/ssh/sshd_config в строчке ChallengeResponseAuthentication поменял no на yes. После перезапуска сервиса ssh все заработало.
Спасибо!
Я после работы продолжил свое исследование (включая MTU). Как оказалось, все UDP соединения на WireGuard сервер, порты которых выше 1000 (т.е. начиная с 1001) не проходят до моего удаленного сервера через Дом.ру. В ЛК я не нашел настроек Firewall, есть только включить\выключить NAT. Я попробовал переключение NAT, поведение не поменялось. Сейчас все стабильно работает с трехзначным номером порта.
Спасибо, буду иметь в виду.
Но в моем случае обе системы Ubuntu (Server и Desktop) и мобильное устройство на iOS. Desktop и iOS перестают работать только если подключение через Дом.ру проходит и оба клиента начинают работать если подключение к серверу я произвожу через мобильную сеть.
Возможно дело в чем-то другом и это просто совпадение…
У меня вчера вечером неожиданно перестали работать все клиенты которые используют VPN WireGuard, провайдер Дом.ру, проблема связана с Handshake .Сервер крутится на DigitalOcean. Попробовал подключиться через мобильного оператора к удаленному серверу - соединение проходит. Вот теперь интересно, не связанны ли эти блокировки с проблемой которая у меня возникла....
Нашел подобные проблемы в Google (на 4pda) и понял, проблема не у меня одного такая оказывается. Некоторые пишут там что CloudFlare WARP отвалился тоже (он работает на основе WireGuard)
Похоже понадобиться поднимать какой-нибудь udptunnel или udp2raw для второго слоя. Но если это возможно сможет решить вопрос "сервер → сервер" или "ПК → сервер" (и то тут вопросы есть для macOS и Windows), то не сможет решить проблему - "мобильное устройство → сервер". Придется какой-нибудь Raspberry Pi организовывать как WIFI точку доступа с этими двумя слоями для VPN, а мобильные устройства к нему цеплять….
Но в процессе использования этого VPN, я обратил внимание, если в приложении Wireguard включен режим on-demand, то в стандартных настройках сетевых соединений ОС, в интерфейсе Wireguard появляется галочка «Connect on demand», она имеет приоритет над режимом on-demand в приложении Wireguard. Когда мне нужно быстро отключить VPN (или обновить Wireguard), я просто снимаю эту галочку и там-же нажимаю на кнопку «Disconnect», трафик соответсвенно начнёт идти в обход VPN. Когда нужно вернуть VPN, достаточно просто поставить галочку напротив «Connect on demand», соединение само поднимется.
Решилось так, добавил строку auth required pam_google_authenticator.so в конец файла /etc/pam.d/sshd, в файле /etc/ssh/sshd_config в строчке ChallengeResponseAuthentication поменял no на yes. После перезапуска сервиса ssh все заработало.