SoftEthers virtuelle adapter dukker op, men sender ingen trafik

En virtuel SoftEther-adapter vises på styresystemets netværksliste, melder sig som ikke tilsluttet og bærer ingen trafik. Den kombination er normal for en enhed uden en tilknyttet session, og det er også den tilstand, du ser, når den forkerte profil er bundet til den. Adapteren er en enhed, som styresystemet ejer; sessionen er det, der giver den liv. Gå gennem disse fire kontroller i rækkefølge, og stop ved den første, der fejler.

Adskil enheden fra sessionen

Oprettelsen af adapteren installerer en netværksenhed; den godkender sig ikke over for nogen server. Bekræft, hvad klientens forbindelsesliste siger, før du læser noget ind i grænsefladens tilstand. En profil, der ikke er forbundet, forklarer den afbrudte status uden yderligere undersøgelse.

Adapteren og den fysiske grænseflade har forskellige opgaver. Den ene bærer den dekrypterede trafik, som programmerne ser, og den anden bærer den krypterede ydre forbindelse til serveren. At forveksle de to fører til firewallregler og ruter, der anvendes på den forkerte enhed. Regler skrevet til den fysiske grænseflade matcher ikke tunnelens trafik, og regler skrevet til tunnelen påvirker ikke den ydre forbindelse.

Kobl én adapter til én profil

Hver adapter skal være bundet til den forbindelsesprofil, du har til hensigt, og bindingen skal være synlig i klienten frem for husket. Når der findes flere adaptere, notér hvilken profil der ejer hvilken enhed, før du rører ved nogen af dem. Genbrug af en adapter på tværs af profiler er måden, hvorpå en forældet adresse overlever en genopkobling.

Hvis klienten tilbyder en understøttet måde at genskabe bindingen på, så brug den i stedet for at redigere styresystemets konfiguration direkte. Klienten skriver adapterens indstillinger ved forbindelse, så manuelle ændringer forsvinder ofte eller støder sammen i næste session.

Læs de effektive indstillinger efter forbindelse

Når en session er oppe, skal du læse adressen, ruten og resolveren fra systemet. Klientens statuspanel beskriver, hvad den bad om, mens kernen beskriver, hvad der faktisk skete.

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

Adresselisten viser, om adapteren overhovedet modtog noget, og en adapter uden adresse efter et vellykket login peger på profilens konfiguration frem for på driveren. Ruteopslaget viser, hvilken grænseflade der ville bære en privat destination, og det er her, en manglende rute bliver synlig. Resolverens output viser, om DNS fulgte sessionen, fordi et fungerende link med lokal DNS stadig giver en halvt brudt forbindelse.

En oprettet adapter uden brugbare indstillinger kan eksistere samtidig med et vellykket administrationslogin andetsteds i klienten. De to paneler besvarer forskellige spørgsmål, så det ene er aldrig bevis om det andet. Når de er uenige, er systemvisningen den, som programmerne oplever.

Stop før bro eller sletning

At bro en virtuel adapter til en fysisk er en designændring frem for en reparation. Den smelter to netværksgrænser sammen, og den er ikke en måde at reparere en manglende rute på. Hvis udrulningen har brug for den ordning, har den brug for et autoriseret design og en testplan.

Sletning af en adapter er lige så destruktiv, når en anden tjeneste bruger den. Identificér ejeren først, herunder enhver anden klient eller virtualiseringsprodukt på maskinen, som har oprettet en grænseflade med et lignende navn. En enhed, der dukker op igen efter fjernelse, fortæller dig, at noget genskaber den.

Afslut med at teste programmet, ikke adapteren. En filshare eller intranetsside, der indlæses gennem tunnelen, er beviset på, at enheden, sessionen og ruten er enige.