Виртуалният адаптер на SoftEther се появява, но не изпраща трафик

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

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

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

Адаптерът и физическият интерфейс имат различни задачи. Единият пренася дешифрирания трафик, който приложенията виждат, а другият пренася криптираната външна връзка към сървъра. Объркването на двете води до правила на защитната стена и маршрути, приложени към грешното устройство. Правилата, написани за физическия интерфейс, няма да съвпаднат с трафика на тунела, а правилата, написани за тунела, няма да засегнат външната връзка.

Свържете един адаптер с един профил

Всеки адаптер трябва да бъде обвързан с профила на връзката, който възнамерявате, и обвързването трябва да се вижда в клиента, а не да се помни. Когато има няколко адаптера, отбележете кой профил притежава кое устройство, преди да пипате който и да е от тях. Повторното използване на адаптер за различни профили е начинът, по който остарял адрес оцелява при повторно свързване.

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

Прочетете ефективните настройки след свързване

След като сесията е установена, прочетете адреса, маршрута и резолвера от системата. Панелът за състояние на клиента описва какво е поискал, докато ядрото описва какво всъщност се е случило.

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

Списъкът с адреси показва дали адаптерът е получил изобщо нещо, а адаптер без адрес след успешен вход сочи към конфигурацията на профила, а не към драйвера. Заявката за маршрут показва кой интерфейс би пренесъл частна дестинация и именно там липсващият маршрут става видим. Изходът на резолвера показва дали DNS е последвал сесията, тъй като работеща връзка с локален DNS все още дава наполовина счупена връзка.

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

Спрете преди мостове или изтриване

Мостът между виртуалния адаптер и физически такъв е промяна в дизайна, а не ремонт. Той слива две мрежови граници и не е начин да се поправи липсващ маршрут. Ако внедряването се нуждае от такава подредба, то се нуждае от разрешен дизайн и план за тестване.

Изтриването на адаптер е еднакво разрушително, когато друга услуга го използва. Първо установете собственика, включително всеки друг клиент или продукт за виртуализация на машината, който е създал интерфейс с подобно име. Устройство, което се появява отново след премахване, ви казва, че нещо го пресъздава.

Завършете, като тествате приложението, а не адаптера. Споделена папка или интранет страница, която се зарежда през тунела, е доказателството, че устройството, сесията и маршрутът са в съгласие.