Adaptorul virtual SoftEther apare, dar nu trimite trafic

Un adaptor virtual SoftEther apare în lista de rețele a sistemului de operare, se raportează ca deconectat și nu transportă niciun trafic. Această combinație este normală pentru un dispozitiv fără o sesiune atașată, și este și starea pe care o vedeți când la el este legat un profil greșit. Adaptorul este un dispozitiv deținut de sistemul de operare; sesiunea este ceea ce îi dă viață. Parcurgeți aceste patru verificări în ordine și opriți-vă la prima care eșuează.

Separați dispozitivul de sesiune

Crearea adaptorului instalează un dispozitiv de rețea; nu se autentifică la niciun server. Confirmați ce spune lista de conexiuni a clientului înainte de a trage concluzii din starea interfeței. Un profil care nu este conectat explică starea deconectată fără nicio investigație suplimentară.

Adaptorul și interfața fizică au sarcini diferite. Unul transportă traficul decriptat pe care îl văd aplicațiile, iar celălalt transportă conexiunea exterioară criptată către server. Confundarea celor două duce la aplicarea regulilor de firewall și a rutelor pe dispozitivul greșit. Regulile scrise pentru interfața fizică nu se vor potrivi cu traficul tunelului, iar regulile scrise pentru tunel nu vor afecta conexiunea exterioară.

Asociați un adaptor cu un profil

Fiecare adaptor ar trebui să fie legat de profilul de conexiune dorit, iar legătura ar trebui să fie vizibilă în client, nu memorată. Când există mai multe adaptoare, notați ce profil deține ce dispozitiv înainte de a atinge vreunul dintre ele. Reutilizarea unui adaptor între profiluri este modul în care o adresă veche supraviețuiește unei reconectări.

Dacă clientul oferă o modalitate acceptată de a recreea legătura, folosiți-o în loc să editați direct configurația sistemului de operare. Clientul scrie setările adaptorului la conectare, așa că modificările manuale tind să dispară sau să intre în conflict în sesiunea următoare.

Citiți setările efective după conectare

După ce sesiunea este activă, citiți adresa, ruta și resolverul din sistem. Panoul de stare al clientului descrie ce a cerut, în timp ce nucleul descrie ce s-a întâmplat de fapt.

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

Lista de adrese arată dacă adaptorul a primit ceva, iar un adaptor fără adresă după o autentificare reușită indică configurația profilului, nu driverul. Interogarea rutei arată ce interfață ar transporta o destinație privată, și acolo o rută lipsă devine vizibilă. Ieșirea resolverului arată dacă DNS a urmat sesiunea, deoarece o legătură funcțională cu DNS local produce în continuare o conexiune pe jumătate stricată.

Un adaptor creat fără setări utile poate coexista cu o autentificare de administrare reușită în altă parte a clientului. Cele două panouri răspund la întrebări diferite, așa că unul nu este niciodată dovadă despre celălalt. Când nu sunt de acord, viziunea sistemului este cea pe care o experimentează aplicațiile.

Opriți-vă înainte de punte sau ștergere

Puntea dintre adaptorul virtual și unul fizic este o schimbare de proiectare, nu o reparație. Unește două granițe de rețea și nu este o modalitate de a corecta o rută lipsă. Dacă implementarea are nevoie de această configurație, are nevoie de un proiect autorizat și de un plan de testare.

Ștergerea unui adaptor este la fel de distructivă când un alt serviciu îl folosește. Identificați mai întâi proprietarul, inclusiv orice alt client sau produs de virtualizare de pe mașină care a creat o interfață cu un nume similar. Un dispozitiv care reapare după îndepărtare vă spune că ceva îl recreează.

Încheiați testând aplicația, nu adaptorul. O partajare de fișiere sau o pagină de intranet care se încarcă prin tunel este dovada că dispozitivul, sesiunea și ruta sunt de acord.