SoftEther se virtuele adapter wys op maar stuur geen verkeer

’n SoftEther virtuele adapter verskyn in die bedryfstelsel se netwerklys, rapporteer homself as ontkoppel en dra geen verkeer nie. Daardie kombinasie is normaal vir ’n toestel sonder ’n sessie wat daaraan gekoppel is, en dit is ook die toestand wat jy sien wanneer die verkeerde profiel daaraan gebind is. Die adapter is ’n toestel wat die bedryfstelsel besit; die sessie is wat dit lewe gee. Werk deur hierdie vier kontroles in volgorde en stop by die eerste een wat misluk.

Skei die toestel van die sessie

Om die adapter te skep, installeer ’n netwerktoestel; dit verifieer nie by enige bediener nie. Bevestig wat die kliënt se verbindingslys sê voordat jy enigiets in die koppelvlaktoestand inlees. ’n Profiel wat nie gekoppel is nie, verduidelik die ontkoppelde status sonder enige verdere ondersoek.

Die adapter en die fisiese koppelvlak het verskillende take. Een dra die ontsleutelde verkeer wat die programme sien, en die ander een dra die geïnkripteerde buitenste verbinding na die bediener. Om die twee te verwar lei tot firewall-reëls en roetes wat op die verkeerde toestel toegepas word. Reëls wat vir die fisiese koppelvlak geskryf is, sal nie by die tonnel se verkeer pas nie, en reëls wat vir die tonnel geskryf is, sal nie die buitenste verbinding beïnvloed nie.

Pas een adapter by een profiel

Elke adapter moet aan die verbindingsprofiel gebind word wat jy bedoel, en die binding moet in die kliënt sigbaar wees eerder as onthou word. Wanneer daar verskeie adapters is, let op watter profiel watter toestel besit voordat jy enigeen aanraak. Om ’n adapter oor profiele te hergebruik, is hoe ’n verouderde adres ’n herverbinding oorleef.

As die kliënt ’n ondersteunde manier bied om die binding te herskep, gebruik dit eerder as om die bedryfstelsel se konfigurasie direk te wysig. Die kliënt skryf die adapter se instellings wanneer dit koppel, so handmatige wysigings verdwyn dikwels of bots by die volgende sessie.

Lees die effektiewe instellings nadat jy gekoppel het

Sodra ’n sessie aan die gang is, lees die adres, die roete en die oplosser uit die stelsel. Die kliënt se statuspaneel beskryf waarvoor dit gevra het, terwyl die kernel beskryf wat werklik gebeur het.

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

Die adreslys wys of die adapter hoegenaamd iets ontvang het, en ’n adapter sonder ’n adres ná ’n suksesvolle aanmelding dui op die profiel se konfigurasie eerder as op die drywer. Die roetevraag wys watter koppelvlak ’n private bestemming sou dra, en dit is waar ’n ontbrekende roete sigbaar word. Die oplosser-uitvoer wys of DNS die sessie gevolg het, aangesien ’n werkende skakel met plaaslike DNS steeds ’n halfgebroke verbinding lewer.

’n Geskepte adapter sonder nuttige instellings kan saambestaan met ’n suksesvolle bestuursaanmelding elders in die kliënt. Die twee panele beantwoord verskillende vrae, so een is nooit bewyse oor die ander nie. Wanneer hulle verskil, is die stelsel-aansig die een wat die programme ervaar.

Stop voordat jy skakel of uitvee

Om die virtuele adapter aan ’n fisiese een te brug, is ’n ontwerpverandering eerder as ’n herstelling. Dit smelt twee netwerkgrense saam, en dit is nie ’n manier om ’n ontbrekende roete reg te maak nie. As die ontplooiing daardie reëling nodig het, het dit ’n gemagtigde ontwerp en ’n toetsplan nodig.

Om ’n adapter te verwyder is ewe vernietigend wanneer ’n ander diens dit gebruik. Identifiseer eers die eienaar, insluitend enige ander kliënt of virtualiseringsproduk op die masjien wat ’n koppelvlak met ’n soortgelyke naam geskep het. ’n Toestel wat ná verwydering weer verskyn, sê vir jou dat iets dit herskep.

Eindig deur die toepassing te toets, nie die adapter nie. ’n Lêerdeling of intranetblad wat deur die tonnel laai, is die bewys dat die toestel, die sessie en die roete almal saamstem.