SoftEthers virtuelle adapter vises, men sender ingen trafikk

En virtuell SoftEther-adapter vises i operativsystemets nettverksliste, melder seg som frakoblet og bærer ingen trafikk. Den kombinasjonen er normal for en enhet uten en tilknyttet sesjon, og det er også tilstanden du ser når feil profil er bundet til den. Adapteren er en enhet som operativsystemet eier; sesjonen er det som gir den liv. Gå gjennom disse fire kontrollene i rekkefølge og stopp ved den første som feiler.

Skill enheten fra sesjonen

Opprettelsen av adapteren installerer en nettverksenhet; den autentiserer seg ikke mot noen server. Bekreft hva klientens tilkoblingsliste sier før du leser noe inn i grensesnittets tilstand. En profil som ikke er tilkoblet, forklarer den frakoblede statusen uten ytterligere undersøkelse.

Adapteren og det fysiske grensesnittet har ulike oppgaver. Den ene bærer den dekrypterte trafikken som programmene ser, og den andre bærer den krypterte ytre forbindelsen til serveren. Å forveksle de to fører til at brannmurregler og ruter brukes på feil enhet. Regler skrevet for det fysiske grensesnittet vil ikke samsvare med tunnelens trafikk, og regler skrevet for tunnelen vil ikke påvirke den ytre forbindelsen.

Koble én adapter til én profil

Hver adapter bør være bundet til tilkoblingsprofilen du har tenkt, og bindingen bør være synlig i klienten i stedet for husket. Når det finnes flere adaptere, noter hvilken profil som eier hvilken enhet før du berører noen av dem. Gjenbruk av en adapter på tvers av profiler er måten en utdatert adresse overlever en gjentilkobling.

Hvis klienten tilbyr en støttet måte å gjenopprette bindingen på, bruk den i stedet for å redigere operativsystemets konfigurasjon direkte. Klienten skriver adapterens innstillinger ved tilkobling, så manuelle endringer forsvinner ofte eller kolliderer i neste sesjon.

Les de faktiske innstillingene etter tilkobling

Når en sesjon er oppe, les adressen, ruten og oppløseren fra systemet. Klientens statuspanel beskriver hva den ba om, mens kjernen beskriver hva som faktisk skjedde.

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

Adresselisten viser om adapteren fikk noe i det hele tatt, og en adapter uten adresse etter vellykket innlogging peker på profilens konfigurasjon og ikke på driveren. Rutespørringen viser hvilket grensesnitt som ville bære en privat destinasjon, og det er der en manglende rute blir synlig. Oppløserens utdata viser om DNS fulgte sesjonen, siden en fungerende lenke med lokal DNS fortsatt gir en halvveis ødelagt forbindelse.

En opprettet adapter uten nyttige innstillinger kan eksistere samtidig med en vellykket administrasjonsinnlogging andre steder i klienten. De to panelene svarer på forskjellige spørsmål, så det ene er aldri bevis om det andre. Når de er uenige, er systemvisningen den programmene opplever.

Stopp før bro eller sletting

Å bro den virtuelle adapteren til en fysisk er en designendring, ikke en reparasjon. Den smelter sammen to nettverksgrenser, og den er ikke en måte å rette en manglende rute på. Hvis utrullingen trenger den ordningen, trenger den et autorisert design og en testplan.

Sletting av en adapter er like ødeleggende når en annen tjeneste bruker den. Identifiser eieren først, inkludert enhver annen klient eller virtualiseringsprodukt på maskinen som har opprettet et grensesnitt med lignende navn. En enhet som dukker opp igjen etter fjerning, forteller deg at noe gjenoppretter den.

Avslutt med å teste programmet, ikke adapteren. En filshare eller intranettside som lastes gjennom tunnelen, er beviset på at enheten, sesjonen og ruten er enige.