Виртуальный адаптер SoftEther появляется, но не передаёт трафик

Виртуальный адаптер SoftEther появляется в сетевом списке операционной системы, сообщает о себе как об отключённом и не передаёт никакого трафика. Такое сочетание нормально для устройства без присоединённого сеанса, и это же состояние вы видите, когда к нему привязан неправильный профиль. Адаптер — это устройство, которым владеет операционная система; сеанс — это то, что даёт ему жизнь. Пройдите эти четыре проверки по порядку и остановитесь на первой, которая не пройдёт.

Отделите устройство от сеанса

Создание адаптера устанавливает сетевое устройство; оно не проходит проверку подлинности ни на одном сервере. Прежде чем делать выводы из состояния интерфейса, проверьте, что говорит список подключений клиента. Профиль, который не подключён, объясняет отключённое состояние без дополнительного расследования.

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

Сопоставьте один адаптер одному профилю

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

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

После подключения прочитайте действующие настройки

Когда сеанс установлен, прочитайте адрес, маршрут и распознаватель из системы. Панель состояния клиента описывает то, что он запросил, а ядро описывает то, что произошло на самом деле.

ip -brief address show
ip route get 10.20.30.41
resolvectl status | head -20

Список адресов показывает, получил ли адаптер хоть что-нибудь, а адаптер без адреса после успешного входа указывает на конфигурацию профиля, а не на драйвер. Запрос маршрута показывает, какой интерфейс понёс бы частный адрес назначения, и именно там становится виден отсутствующий маршрут. Вывод распознавателя показывает, последовал ли DNS за сеансом, так как рабочее соединение с локальным DNS всё равно даёт наполовину сломанное подключение.

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

Остановитесь до моста или удаления

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

Удаление адаптера столь же разрушительно, когда его использует другой сервис. Сначала определите владельца, включая любой другой клиент или продукт виртуализации на машине, создавший интерфейс с похожим именем. Устройство, которое появляется снова после удаления, говорит вам, что что-то создаёт его заново.

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