SoftEthers virtuelle adapter dukkar opp, men sender ingen trafikk

Ein virtuell SoftEther-adapter dukkar opp i nettverkslista til operativsystemet, melder seg som fråkopla og fører ingen trafikk. Den kombinasjonen er normal for ei eining utan ein tilknytt sesjon, og det er også tilstanden du ser når feil profil er bunden til henne. Adapteren er ei eining som operativsystemet eig; sesjonen er det som gir henne liv. Gå gjennom desse fire kontrollane i rekkefølgje og stopp ved den første som feilar.

Skil eininga frå sesjonen

Opprettinga av adapteren installerer ei nettverkseining; ho autentiserer seg ikkje mot nokon tenar. Stadfest kva tilkoplingslista til klienten seier før du les noko inn i tilstanden til grensesnittet. Ein profil som ikkje er tilkopla, forklarar den fråkopla statusen utan vidare undersøking.

Adapteren og det fysiske grensesnittet har ulike oppgåver. Den eine fører den dekrypterte trafikken som programma ser, og den andre fører det krypterte ytre sambandet til tenaren. Å blande dei to fører til at brannmurreglar og ruter vert brukte på feil eining. Reglar skrivne for det fysiske grensesnittet vil ikkje passe til trafikken i tunnelen, og reglar skrivne for tunnelen vil ikkje påverke den ytre sambandet.

Kople éin adapter til éin profil

Kvar adapter bør vere bunden til tilkoplingsprofilen du har tenkt, og bindinga bør vere synleg i klienten i staden for hugsa. Når det finst fleire adapterar, noter kva profil som eig kva eining før du rører nokon av dei. Gjenbruk av ein adapter på tvers av profilar er måten ei utdatert adresse overlever ei ny tilkopling.

Viss klienten tilbyr ein støtta måte å gjenopprette bindinga på, bruk han i staden for å redigere konfigurasjonen til operativsystemet direkte. Klienten skriv innstillingane til adapteren ved tilkopling, så manuelle endringar forsvinn ofte eller kolliderer i neste sesjon.

Les dei faktiske innstillingane etter tilkopling

Når ein sesjon er oppe, les adressa, ruta og oppløysaren frå systemet. Statuspanelet til klienten skildrar kva han bad om, medan kjernen skildrar kva som faktisk hende.

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

Adresselista viser om adapteren fekk noko i det heile, og ein adapter utan adresse etter vellukka innlogging peikar på konfigurasjonen til profilen og ikkje på drivaren. Rutespørjinga viser kva grensesnitt som ville føre ein privat destinasjon, og det er der ei manglande rute vert synleg. Utdata frå oppløysaren viser om DNS følgde sesjonen, sidan ei fungerande lenkje med lokal DNS framleis gir eit halvt øydelagt samband.

Ein oppretta adapter utan nyttige innstillingar kan eksistere saman med ei vellukka administrasjonsinnlogging andre stader i klienten. Dei to panela svarar på ulike spørsmål, så det eine er aldri prov om det andre. Når dei er usamde, er systemvisinga den programma opplever.

Stopp før bru eller sletting

Å bru den virtuelle adapteren til ein fysisk er ei designendring, ikkje ein reparasjon. Ho smeltar saman to nettverksgrenser, og ho er ikkje ein måte å rette ei manglande rute på. Viss utrullinga treng den ordninga, treng ho eit autorisert design og ein testplan.

Sletting av ein adapter er like øydeleggjande når ein annan teneste brukar han. Identifiser eigaren først, inkludert kvar annan klient eller virtualiseringsprodukt på maskinen som har oppretta eit grensesnitt med liknande namn. Ei eining som dukkar opp att etter fjerning, fortel deg at noko gjenopprettar henne.

Avslutt med å teste programmet, ikkje adapteren. Ei filutdeling eller ei intranettside som lastar gjennom tunnelen, er provet på at eininga, sesjonen og ruta er samde.