Varför en OpenVPN-profil inte kan importeras i SoftEther

Två filer som båda ser ut som en VPN-konfiguration hamnar i samma mapp, och bara en av dem fungerar. OpenVPN-profilen beskriver en TLS-tunnel med direktiv som den klienten förstår, medan en SoftEther-anslutning beskriver en session mot en virtuell hubb med ett annat autentiseringsavtal. Att göra om den ena till den andra är ingen formateringsövning, eftersom de två klienterna inte implementerar samma protokoll. Att fastställa vilken tjänst operatören faktiskt publicerade avgör allt som följer.

Två filer, två avtal

En OpenVPN-profil är en klientkonfiguration: en fjärransluten ändpunkt, ett transportskikt, TLS-material och direktiv för routning och omförhandling. En SoftEther-anslutning är en inbyggd klientsession mot en virtuell hubb, med en virtuell adapter kopplad till sig.

De kan beskriva åtkomst till samma nätverk utan att vara utbytbara. OpenVPN-lyssnaren är en kompatibilitetsfunktion som servern kan publicera på en separat port, och den talar OpenVPN i stället för det inbyggda protokollet. Den inbyggda klienten talar det inbyggda protokollet och förväntar sig sin egen profil. En server, två dörrar, och varje dörr har sin egen nyckel.

Filändelsen berättar nästan ingenting, därför är operatörens svar viktigare än filnamnet.

Läs servern innan du rör ett certifikatblock

Fråga operatören om tre saker: vilken port och transport, vilken autentiseringsmetod och vilken klient de förväntar sig att du använder. De svaren tar bort det mesta av gissningarna.

Bekräfta sedan vad som faktiskt lyssnar, i stället för vad en guide påstår. En avstängd kompatibilitetslyssnare visar ingenting på sin port, och en aktiverad visar en socket även när ingen någonsin har anslutit. Skillnaden mellan en stängd port och en nekad inloggning är den första användbara diagnosen. Allt därefter beror på vilken dörr det knackades på.

ss -lunp | grep -E ':1194|:443'
sudo ss -ltnp | grep -E ':992|:5555'
grep -nE '^(remote|proto|auth-user-pass|ca |cert |key )' profile.ovpn

En UDP-port som saknas i lyssnarlistan är en avstängd funktion och inte ett brandväggsproblem.

Vad den inbyggda klienten behöver och en profil inte kan ge den

Den inbyggda klienten installerar en virtuell nätverksadapter och binder en anslutning till den. Utan den adaptern finns inget gränssnitt att routa genom, vilket är varför en inbyggd anslutning kan autentisera och ändå inte föra någon trafik.

Inbyggd autentisering sker mot en virtuell hubb, med ett användarobjekt som hubbadministratören skapade. Certifikatblock som kopierats från en OpenVPN-profil blir inte hubb-användare, och en hubb-användare blir inte ett klientcertifikat. De två systemen lagrar olika saker, och en profil har ingenstans att lägga hubbens användarpost. Det är en strukturell skillnad och inte ett syntaxproblem.

Håll den privata nyckeln borta från varje konverteringstjänst, eftersom en nyckel som lämnar maskinen måste betraktas som röjd.

Vad den OpenVPN-kompatibla lyssnaren accepterar

Kompatibilitetslyssnaren är en riktig OpenVPN-server ur klientens perspektiv: den förväntar sig en OpenVPN-klient och de direktiv som den klienten stöder. Inbäddade certifikatblock är en OpenVPN-funktion, och de hör till den sidan av staketet.

Vad den inte gör är att acceptera en inbyggd SoftEther-profil, eftersom den profilen inte är en OpenVPN-konfiguration. Lyssnaren gör heller inte den inbyggda klienten till en OpenVPN-klient. Om operatören bara erbjuder den inbyggda tjänsten är svaret den inbyggda klienten; om de erbjuder kompatibilitetslyssnaren är svaret OpenVPN och dess eget material.

Be om operatörens stödda export i stället för att sätta ihop en av fragment, eftersom exporten bär detaljer som en handbyggd fil vanligtvis missar.

Bevisa vägen innan du redigerar direktiv

När klienten är vald, testa tunneln innan du rör rutter. En lyckad inloggning och ett gränssnitt som för trafik är två olika resultat.

sudo openvpn --config profile.ovpn --verb 3
ip -br addr
ip route get 10.70.4.20
resolvectl status | grep -A2 'DNS Servers'

Jämför den tilldelade adressen med den pool som operatören beskrev, och titta sedan på rutter och upplösare var för sig. En inbyggd hubbanslutning kan autentisera rent och inte installera några rutter alls, vilket från klientsidan ser ut som en trasig tunnel. Först när dessa tre stämmer är det värt att redigera ett direktiv. Tidigare redigering döljer vilket lager som var fel.