SSH зависает, пока VPN

Question 1

Я подключил обе мыши разработчика конструктора Microsoft и logitech K480, оба работают одновременно.

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

Question 2

Чтобы дать осмысленный ответ, нам понадобится дополнительная информация. Я предполагаю, что VPN - это Cisco Openconnect VPN. Это правильно? Без дополнительной информации я предполагаю, что ваша проблема заключается в настройке VPN.

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

Если вы предпочитаете решения с открытым исходным кодом, есть программа под названием openconnect. Инструкции по его использованию здесь.

Попробуйте 1 из этих вариантов. Если вас не интересует открытый исходный код, честно говоря, клиент Cisco будет работать наиболее легко. Если вам все равно, попробуйте openconnect.

Удачи!

Question 3

Question 4

Это звучит как проблема с DNS и, более конкретно, DNS при использовании dnsmasq с VPN. Известная проблема при использовании dnsmasq и NetworkManager с VPN, которая нарушит разрешение DNS внутри dnsmasq. Upstream признал, но также ничего не сделал для его фиксации. Это было проблемой с 16 апреля, и, похоже, в скором времени они не появятся на их радаре. Я предполагаю, что они понятия не имеют, где это происходит. (LP Bug # 1588018, среди многих других ошибок по одной и той же проблеме)

Решение состоит в признании вообще использовать dnsmasq и вместо этого использовать другую систему DNS или установить DNS-серверов по умолчанию, обычно путем принудительного переопределения настроек службы resolvconf.

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

ВНИМАНИЕ: Это моё решение этой проблемы и является нестандартным, нетривиальным решением проблемы DNS. Используйте только на свой страх и риск.

Реальный обходной путь был болезненным, нетривиальным. Я установил и настроил bind9 как переадресацию DNS-резольвера, чтобы он пересылал все DNS-запросы в Google DNS (8.8.8.8 и 8.8.4.4), а затем после этого я пошел и редактировал файл /etc/resolvconf/resolv.conf.d/head для запроса локального DNS. Обратите внимание, что мне пришлось добавить локальную привязку DNS для 127.0.2.1, и для этого мне нужно катить пользовательские диапазоны IP в моем адаптере lo, добавив эти строки в мой файл /etc/network/interfaces (я включил по умолчанию lo auto / loopback для контекста):

auto lo
iface lo inet loopback
    up ip -4 addr add 127.0.2.1/8 dev lo
    down ip -4 addr del 127.0.2.1/8 dev lo

... и установив bind9 в папку /etc/bind/named.conf.options, чтобы теперь это было в блоке конфигурации опций:

listen-on { 127.0.2.1; };

После того, как я перезапустил систему после внесения этих изменений, система начала по умолчанию использовать мой локальный bind9 resolver.

Однако это предотвращает VPN, которые имеют внутрисетевые и внутренние DNS-разрешения и внутренние домены от правильного разрешения; это привело к появлению других проблем, но я ничего не мог обойти (как мощный пользователь и системный администратор).

Question 5

Чтобы дать осмысленный ответ, нам понадобится дополнительная информация. Я предполагаю, что VPN - это Cisco Openconnect VPN. Это правильно? Без дополнительной информации я предполагаю, что ваша проблема заключается в настройке VPN.

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

Если вы предпочитаете решения с открытым исходным кодом, есть программа под названием openconnect. Инструкции по его использованию здесь.

Попробуйте 1 из этих вариантов. Если вас не интересует открытый исходный код, честно говоря, клиент Cisco будет работать наиболее легко. Если вам все равно, попробуйте openconnect.

Удачи!

Question 6

Это звучит как проблема с DNS и, более конкретно, DNS при использовании dnsmasq с VPN. Известная проблема при использовании dnsmasq и NetworkManager с VPN, которая нарушит разрешение DNS внутри dnsmasq. Upstream признал, но также ничего не сделал для его фиксации. Это было проблемой с 16 апреля, и, похоже, в скором времени они не появятся на их радаре. Я предполагаю, что они понятия не имеют, где это происходит. (LP Bug # 1588018, среди многих других ошибок по одной и той же проблеме)

Решение состоит в признании вообще использовать dnsmasq и вместо этого использовать другую систему DNS или установить DNS-серверов по умолчанию, обычно путем принудительного переопределения настроек службы resolvconf.

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

ВНИМАНИЕ: Это моё решение этой проблемы и является нестандартным, нетривиальным решением проблемы DNS. Используйте только на свой страх и риск.

Реальный обходной путь был болезненным, нетривиальным. Я установил и настроил bind9 как переадресацию DNS-резольвера, чтобы он пересылал все DNS-запросы в Google DNS (8.8.8.8 и 8.8.4.4), а затем после этого я пошел и редактировал файл /etc/resolvconf/resolv.conf.d/head для запроса локального DNS. Обратите внимание, что мне пришлось добавить локальную привязку DNS для 127.0.2.1, и для этого мне нужно катить пользовательские диапазоны IP в моем адаптере lo, добавив эти строки в мой файл /etc/network/interfaces (я включил по умолчанию lo auto / loopback для контекста):

auto lo
iface lo inet loopback
    up ip -4 addr add 127.0.2.1/8 dev lo
    down ip -4 addr del 127.0.2.1/8 dev lo

... и установив bind9 в папку /etc/bind/named.conf.options, чтобы теперь это было в блоке конфигурации опций:

listen-on { 127.0.2.1; };

После того, как я перезапустил систему после внесения этих изменений, система начала по умолчанию использовать мой локальный bind9 resolver.

Однако это предотвращает VPN, которые имеют внутрисетевые и внутренние DNS-разрешения и внутренние домены от правильного разрешения; это привело к появлению других проблем, но я ничего не мог обойти (как мощный пользователь и системный администратор).

Noah · Answer 1 · 17 July 2018 в 21:41

Чтобы дать осмысленный ответ, нам понадобится дополнительная информация. Я предполагаю, что VPN - это Cisco Openconnect VPN. Это правильно? Без дополнительной информации я предполагаю, что ваша проблема заключается в настройке VPN.

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

Если вы предпочитаете решения с открытым исходным кодом, есть программа под названием openconnect. Инструкции по его использованию здесь.

Попробуйте 1 из этих вариантов. Если вас не интересует открытый исходный код, честно говоря, клиент Cisco будет работать наиболее легко. Если вам все равно, попробуйте openconnect.

Удачи!

Thomas Ward · Answer 2 · 17 July 2018 в 21:41

Это звучит как проблема с DNS и, более конкретно, DNS при использовании dnsmasq с VPN. Известная проблема при использовании dnsmasq и NetworkManager с VPN, которая нарушит разрешение DNS внутри dnsmasq. Upstream признал, но также ничего не сделал для его фиксации. Это было проблемой с 16 апреля, и, похоже, в скором времени они не появятся на их радаре. Я предполагаю, что они понятия не имеют, где это происходит. (LP Bug # 1588018, среди многих других ошибок по одной и той же проблеме)

Решение состоит в признании вообще использовать dnsmasq и вместо этого использовать другую систему DNS или установить DNS-серверов по умолчанию, обычно путем принудительного переопределения настроек службы resolvconf.

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

ВНИМАНИЕ: Это моё решение этой проблемы и является нестандартным, нетривиальным решением проблемы DNS. Используйте только на свой страх и риск.

Реальный обходной путь был болезненным, нетривиальным. Я установил и настроил bind9 как переадресацию DNS-резольвера, чтобы он пересылал все DNS-запросы в Google DNS (8.8.8.8 и 8.8.4.4), а затем после этого я пошел и редактировал файл /etc/resolvconf/resolv.conf.d/head для запроса локального DNS. Обратите внимание, что мне пришлось добавить локальную привязку DNS для 127.0.2.1, и для этого мне нужно катить пользовательские диапазоны IP в моем адаптере lo, добавив эти строки в мой файл /etc/network/interfaces (я включил по умолчанию lo auto / loopback для контекста):

auto lo
iface lo inet loopback
    up ip -4 addr add 127.0.2.1/8 dev lo
    down ip -4 addr del 127.0.2.1/8 dev lo

... и установив bind9 в папку /etc/bind/named.conf.options, чтобы теперь это было в блоке конфигурации опций:

listen-on { 127.0.2.1; };

После того, как я перезапустил систему после внесения этих изменений, система начала по умолчанию использовать мой локальный bind9 resolver.

Однако это предотвращает VPN, которые имеют внутрисетевые и внутренние DNS-разрешения и внутренние домены от правильного разрешения; это привело к появлению других проблем, но я ничего не мог обойти (как мощный пользователь и системный администратор).

Noah · Answer 3 · 23 July 2018 в 22:18

Чтобы дать осмысленный ответ, нам понадобится дополнительная информация. Я предполагаю, что VPN - это Cisco Openconnect VPN. Это правильно? Без дополнительной информации я предполагаю, что ваша проблема заключается в настройке VPN.

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

Если вы предпочитаете решения с открытым исходным кодом, есть программа под названием openconnect. Инструкции по его использованию здесь.

Попробуйте 1 из этих вариантов. Если вас не интересует открытый исходный код, честно говоря, клиент Cisco будет работать наиболее легко. Если вам все равно, попробуйте openconnect.

Удачи!

-2

ответ дан Noah 23 July 2018 в 22:18

1

Нет никаких оснований полагать, что это проблемы с VPN. – Thomas Ward♦ 8 February 2018 в 19:11
2

Я бы сказал, что есть. Я использовал эти VPN с моим университетом, и маршрутизация часто острая. Кроме того, тот факт, что плакат конкретно упоминает о существовании проблемы маршрутизации, требующей изменения в NetworkManager, подразумевает, что в VPN существует что-то подозрительное. – Noah 8 February 2018 в 19:15
3

на самом деле это не проблема VPN, это проблема NetworkManager / dnsmasq и с ошибками об этом с 2016 года на радаре (см. мой ответ, который ссылается на ошибку). Готов поспорить, если OP идет и использует ping 8.8.8.8 или использует ssh ip.add.re.ss вместо того, чтобы пытаться использовать сам домен, он будет работать правильно. В конечном счете все еще не является проблемой, связанной с VPN, это компоненты Network Manager и dnsmasq, которые являются ошибками и не связаны с восходящим потоком. И это не просто специфический OpenConnect - это также влияет на обычные IPv4-сети OpenVPN и vpnc. В основном, все VPN, а не клиент или протокол. – Thomas Ward♦ 8 February 2018 в 19:21

Thomas Ward · Answer 4 · 23 July 2018 в 22:18

Это звучит как проблема с DNS и, более конкретно, DNS при использовании dnsmasq с VPN. Известная проблема при использовании dnsmasq и NetworkManager с VPN, которая нарушит разрешение DNS внутри dnsmasq. Upstream признал, но также ничего не сделал для его фиксации. Это было проблемой с 16 апреля, и, похоже, в скором времени они не появятся на их радаре. Я предполагаю, что они понятия не имеют, где это происходит. (LP Bug # 1588018, среди многих других ошибок по одной и той же проблеме)

Решение состоит в признании вообще использовать dnsmasq и вместо этого использовать другую систему DNS или установить DNS-серверов по умолчанию, обычно путем принудительного переопределения настроек службы resolvconf.

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

ВНИМАНИЕ: Это моё решение этой проблемы и является нестандартным, нетривиальным решением проблемы DNS. Используйте только на свой страх и риск.

Реальный обходной путь был болезненным, нетривиальным. Я установил и настроил bind9 как переадресацию DNS-резольвера, чтобы он пересылал все DNS-запросы в Google DNS (8.8.8.8 и 8.8.4.4), а затем после этого я пошел и редактировал файл /etc/resolvconf/resolv.conf.d/head для запроса локального DNS. Обратите внимание, что мне пришлось добавить локальную привязку DNS для 127.0.2.1, и для этого мне нужно катить пользовательские диапазоны IP в моем адаптере lo, добавив эти строки в мой файл /etc/network/interfaces (я включил по умолчанию lo auto / loopback для контекста):

auto lo
iface lo inet loopback
    up ip -4 addr add 127.0.2.1/8 dev lo
    down ip -4 addr del 127.0.2.1/8 dev lo

... и установив bind9 в папку /etc/bind/named.conf.options, чтобы теперь это было в блоке конфигурации опций:

listen-on { 127.0.2.1; };

После того, как я перезапустил систему после внесения этих изменений, система начала по умолчанию использовать мой локальный bind9 resolver.

Однако это предотвращает VPN, которые имеют внутрисетевые и внутренние DNS-разрешения и внутренние домены от правильного разрешения; это привело к появлению других проблем, но я ничего не мог обойти (как мощный пользователь и системный администратор).

SSH зависает, пока VPN

4 ответа

Другие вопросы по тегам:

Похожие вопросы: