SoftEthers virtuella adapter dyker upp men skickar ingen trafik

En virtuell SoftEther-adapter dyker upp i operativsystemets nätverkslista, rapporterar sig som frånkopplad och bär ingen trafik. Den kombinationen är normal för en enhet utan en ansluten session, och det är också det tillstånd du ser när fel profil är bunden till den. Adaptern är en enhet som operativsystemet äger; sessionen är det som ger den liv. Gå igenom dessa fyra kontroller i ordning och stanna vid den första som misslyckas.

Separera enheten från sessionen

Att skapa adaptern installerar en nätverksenhet; den autentiserar sig inte mot någon server. Bekräfta vad klientens anslutningslista säger innan du läser in något i gränssnittets tillstånd. En profil som inte är ansluten förklarar det frånkopplade tillståndet utan någon ytterligare undersökning.

Adaptern och det fysiska gränssnittet har olika uppgifter. Den ena bär den dekrypterade trafik som programmen ser, och den andra bär den krypterade yttre anslutningen till servern. Att förväxla de två leder till att brandväggsregler och rutter tillämpas på fel enhet. Regler skrivna för det fysiska gränssnittet matchar inte tunnelns trafik, och regler skrivna för tunneln påverkar inte den yttre anslutningen.

Koppla en adapter till en profil

Varje adapter bör vara bunden till den anslutningsprofil du avser, och bindningen bör vara synlig i klienten i stället för ihågkommen. När det finns flera adaptrar, notera vilken profil som äger vilken enhet innan du rör någon av dem. Återanvändning av en adapter mellan profiler är hur en inaktuell adress överlever en återanslutning.

Om klienten erbjuder ett stött sätt att återskapa bindningen, använd det i stället för att redigera operativsystemets konfiguration direkt. Klienten skriver adapterns inställningar vid anslutning, så manuella ändringar försvinner ofta eller krockar i nästa session.

Läs de faktiska inställningarna efter anslutning

När en session är uppe, läs adressen, rutten och resolvern från systemet. Klientens statuspanel beskriver vad den bad om, medan kärnan beskriver vad som faktiskt hände.

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

Adresslistan visar om adaptern fick något alls, och en adapter utan adress efter en lyckad inloggning pekar på profilens konfiguration och inte på drivrutinen. Ruttfrågan visar vilket gränssnitt som skulle bära en privat destination, och det är där en saknad rutt blir synlig. Resolverns utdata visar om DNS följde sessionen, eftersom en fungerande länk med lokal DNS fortfarande ger en halvt trasig anslutning.

En skapad adapter utan användbara inställningar kan samexistera med en lyckad administrationsinloggning någon annanstans i klienten. De två panelerna svarar på olika frågor, så den ena är aldrig bevis om den andra. När de inte stämmer överens är systemvyn den som programmen upplever.

Stanna före bryggning eller borttagning

Att brygga den virtuella adaptern till en fysisk är en designändring, inte en reparation. Den smälter samman två nätverksgränser, och det är inte ett sätt att åtgärda en saknad rutt. Om driftsättningen behöver den ordningen behöver den en godkänd design och en testplan.

Borttagning av en adapter är lika förödande när en annan tjänst använder den. Identifiera ägaren först, inklusive alla andra klienter eller virtualiseringsprodukter på maskinen som har skapat ett gränssnitt med liknande namn. En enhet som dyker upp igen efter borttagning säger dig att något återskapar den.

Avsluta med att testa programmet, inte adaptern. En filresurs eller intranätsida som laddas genom tunneln är beviset på att enheten, sessionen och rutten är överens.