SoftEther's virtuele adapter verschijnt maar verstuurt geen verkeer

Een virtuele SoftEther-adapter verschijnt in de netwerklijst van het besturingssysteem, meldt zich als niet aangesloten en voert geen verkeer. Die combinatie is normaal voor een apparaat zonder aangekoppelde sessie, en het is ook de toestand die u ziet wanneer het verkeerde profiel eraan is gekoppeld. De adapter is een apparaat dat het besturingssysteem bezit; de sessie is wat hem leven geeft. Doorloop deze vier controles in volgorde en stop bij de eerste die faalt.

Scheid het apparaat van de sessie

Het aanmaken van de adapter installeert een netwerkapparaat; het authenticeert bij geen enkele server. Controleer wat de verbindingslijst van de client zegt voordat u iets uit de interfacestatus afleidt. Een profiel dat niet is verbonden, verklaart de niet-aangesloten status zonder verder onderzoek.

De adapter en de fysieke interface hebben verschillende taken. De ene voert het ontsleutelde verkeer dat de toepassingen zien, en de andere voert de versleutelde buitenste verbinding naar de server. Beide verwisselen leidt ertoe dat firewallregels en routes op het verkeerde apparaat worden toegepast. Regels voor de fysieke interface passen niet bij het verkeer van de tunnel, en regels voor de tunnel hebben geen invloed op de buitenste verbinding.

Koppel één adapter aan één profiel

Elke adapter moet aan het beoogde verbindingsprofiel zijn gekoppeld, en die koppeling moet zichtbaar zijn in de client in plaats van onthouden. Als er meerdere adapters zijn, noteer dan welk profiel welk apparaat bezit voordat u er een aanraakt. Een adapter hergebruiken over profielen heen is hoe een verouderd adres een herverbinding overleeft.

Biedt de client een ondersteunde manier om de koppeling opnieuw te maken, gebruik die dan in plaats van de configuratie van het besturingssysteem rechtstreeks te bewerken. De client schrijft de instellingen van de adapter bij het verbinden, dus handmatige wijzigingen verdwijnen vaak of botsen in de volgende sessie.

Lees na het verbinden de werkelijke instellingen

Zodra een sessie actief is, lees dan het adres, de route en de resolver uit het systeem. Het statuspaneel van de client beschrijft wat hij heeft gevraagd, terwijl de kernel beschrijft wat er werkelijk is gebeurd.

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

De adressenlijst laat zien of de adapter überhaupt iets heeft ontvangen, en een adapter zonder adres na een geslaagde aanmelding wijst op de configuratie van het profiel en niet op het stuurprogramma. De routequery laat zien welke interface een privébestemming zou dragen, en daar wordt een ontbrekende route zichtbaar. De uitvoer van de resolver laat zien of DNS de sessie heeft gevolgd, omdat een werkende verbinding met lokale DNS nog steeds een half gebroken verbinding oplevert.

Een aangemaakte adapter zonder bruikbare instellingen kan samengaan met een geslaagde beheeraanmelding elders in de client. De twee panelen beantwoorden verschillende vragen, dus het ene is nooit bewijs over het andere. Als ze het oneens zijn, is de systeemweergave degene die de toepassingen ervaren.

Stop voordat u overbrugt of verwijdert

De virtuele adapter overbruggen naar een fysieke is een ontwerpwijziging, geen reparatie. Het voegt twee netwerkgrenzen samen, en het is geen manier om een ontbrekende route te verhelpen. Als de uitrol die opzet nodig heeft, heeft die een goedgekeurd ontwerp en een testplan nodig.

Een adapter verwijderen is net zo destructief wanneer een andere dienst hem gebruikt. Stel eerst de eigenaar vast, inclusief elke andere client of elk virtualisatieproduct op de machine dat een interface met een vergelijkbare naam heeft gemaakt. Een apparaat dat na verwijdering terugkeert, vertelt u dat iets het opnieuw aanmaakt.

Sluit af door de toepassing te testen, niet de adapter. Een bestandsshare of intranetpagina die via de tunnel laadt, is het bewijs dat het apparaat, de sessie en de route het eens zijn.