Wirtualny adapter SoftEther pojawia się, ale nie przesyła ruchu

Wirtualny adapter SoftEther pojawia się na liście sieci systemu operacyjnego, zgłasza się jako odłączony i nie przenosi żadnego ruchu. Ta kombinacja jest normalna dla urządzenia bez podłączonej sesji, a jest to także stan, który widzisz, gdy jest do niego przypisany niewłaściwy profil. Adapter to urządzenie, które posiada system operacyjny; sesja to to, co daje mu życie. Przejdź te cztery kontrole po kolei i zatrzymaj się na pierwszej, która zawiedzie.

Oddziel urządzenie od sesji

Utworzenie adaptera instaluje urządzenie sieciowe; nie uwierzytelnia się ono na żadnym serwerze. Zanim wyciągniesz jakiekolwiek wnioski ze stanu interfejsu, sprawdź, co mówi lista połączeń klienta. Profil, który nie jest połączony, wyjaśnia stan odłączenia bez dalszego dochodzenia.

Adapter i interfejs fizyczny mają różne zadania. Jeden przenosi odszyfrowany ruch, który widzą aplikacje, a drugi przenosi zaszyfrowane połączenie zewnętrzne do serwera. Pomieszanie obu powoduje stosowanie reguł zapory i tras do niewłaściwego urządzenia. Reguły napisane dla interfejsu fizycznego nie będą pasować do ruchu tunelu, a reguły napisane dla tunelu nie wpłyną na połączenie zewnętrzne.

Przypisz jeden adapter do jednego profilu

Każdy adapter powinien być przypisany do zamierzonego profilu połączenia, a przypisanie powinno być widoczne w kliencie, a nie zapamiętane. Gdy istnieje kilka adapterów, przed dotknięciem któregokolwiek zanotuj, który profil posiada które urządzenie. Ponowne używanie adaptera w różnych profilach to sposób, w jaki nieaktualny adres przetrwa ponowne połączenie.

Jeśli klient oferuje obsługiwany sposób odtworzenia przypisania, użyj go zamiast bezpośredniej edycji konfiguracji systemu operacyjnego. Klient zapisuje ustawienia adaptera przy połączeniu, więc ręczne zmiany często znikają lub kolidują w następnej sesji.

Po połączeniu odczytaj faktyczne ustawienia

Gdy sesja jest aktywna, odczytaj adres, trasę i resolver z systemu. Panel stanu klienta opisuje, o co poprosił, a jądro opisuje, co faktycznie się stało.

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

Lista adresów pokazuje, czy adapter w ogóle coś otrzymał, a adapter bez adresu po udanym logowaniu wskazuje na konfigurację profilu, a nie na sterownik. Zapytanie o trasę pokazuje, który interfejs przeniósłby cel prywatny, i tam właśnie brakująca trasa staje się widoczna. Wynik resolvera pokazuje, czy DNS podążył za sesją, ponieważ działające łącze z lokalnym DNS nadal daje na wpół zepsute połączenie.

Utworzony adapter bez użytecznych ustawień może współistnieć z udanym logowaniem zarządzania w innym miejscu klienta. Dwa panele odpowiadają na różne pytania, więc jeden nigdy nie jest dowodem na drugi. Gdy się nie zgadzają, widok systemu jest tym, czego doświadczają aplikacje.

Zatrzymaj się przed mostkowaniem lub usunięciem

Mostkowanie adaptera wirtualnego z fizycznym to zmiana projektu, a nie naprawa. Łączy dwie granice sieci i nie jest sposobem na naprawienie brakującej trasy. Jeśli wdrożenie potrzebuje takiego układu, potrzebuje zatwierdzonego projektu i planu testów.

Usunięcie adaptera jest równie destrukcyjne, gdy korzysta z niego inna usługa. Najpierw ustal właściciela, w tym każdego innego klienta lub produkt wirtualizacyjny na maszynie, który utworzył interfejs o podobnej nazwie. Urządzenie, które po usunięciu pojawia się ponownie, mówi ci, że coś je odtwarza.

Zakończ, testując aplikację, a nie adapter. Udział plików lub strona intranetowa, która ładuje się przez tunel, jest dowodem, że urządzenie, sesja i trasa są zgodne.