Importen av profilen lyckas, men autentiseringen misslyckas eftersom filen pekar på en Virtual Hub som kontot aldrig har anslutit till. Inget i filen är felformat; den beskriver en uppsättning som inloggningsuppgifterna inte utfärdats för. Sex fält avgör om importen kan fungera: värdnamn, port, protokoll, Virtual Hub, användaridentitet och om någon av misstag gav dig en administratörsuppgift. Kontroll ett till tre täcker dessa fält i ordning, och de två sista täcker själva filen och det du faktiskt anslöt till.

Kontroll 1: värdnamnet och porten

Läs värdnamnet, porten och den angivna åtkomstmetoden innan du importerar något. Den inbyggda SoftEther-lyssnaren svarar normalt på TCP 443, med 992 och 5555 som alternativ som operatörer öppnar för klienter bakom restriktiva nätverk. En profil som riktas mot en port som betjänar en webbplats eller en annan tjänst misslyckas före autentiseringen och rapporterar felet som ett inloggningsfel. Jämför paret med det operatören publicerar för denna endpoint, inte med en kataloglista som någon samlade in i fjol. Om värdnamnet löses upp till en adress som operatören aldrig nämner, stanna där, eftersom nästa steg skickar inloggningsuppgifter till den adressen.

Port 443 är delad mark, så porten ensam bevisar inget om tjänsten bakom. En SoftEther-klient skiljer de två genom protokollhandskakningen, vilket är varför en profil kan peka på rätt port och ändå avslutas mot en webbserver. Det felet ser ut som ett felaktigt lösenord i klientloggen trots att inget lösenord någonsin kontrollerades.

Skriv ned endpointen som värdnamn, port och metod, i den ordningen. Den trion är den del du kan kontrollera utan att ansluta, och det är den del du citerar när du frågar operatören om lyssnaren fortfarande är uppe. Allt du inte kan fylla i från en publicerad källa förblir overifierat i stället för antaget.

Kontroll 2: protokollet avgör klienten

En server som erbjuder flera åtkomstmetoder gör inte en exporterad fil till en profil som varje klient kan öppna. Each method has its own format, its own client and its own failure mode, och att blanda dem ger fel som låter som inloggningsproblem. Bestäm vilken metod filen anger innan du bestämmer vilken klient som öppnar den.

Tabellen nedan listar de vanliga portarna och vad varje metod faktiskt kräver. Portar är operatörens val, så behandla dem som standardvärden och inte som fakta om en specifik server. En inbyggd SoftEther-profil importeras av SoftEther-klienten, ett ovpn-paket hör till OpenVPN, och SSTP- eller L2TP-profiler hanteras av operativsystemet självt. Att installera en andra klient för att öppna en fil som den första avvisar gör vanligen ett tydligt fel till ett förvirrande.

Access methodTypical portWhat the client needs
SoftEther nativeTCP 443, 992 or 5555The SoftEther client and a hub name
OpenVPNUDP or TCP 1194An ovpn profile and an OpenVPN client
SSTPTCP 443Operating system support
L2TP over IPsecUDP 500 and 4500Operating system support and the shared key

Läs deklarationen inuti filen i stället för filändelsen. En fil som är namngiven efter OpenVPN är per definition en OpenVPN-profil, medan en SoftEther-profil är en liten konfiguration som SoftEther-klienten importerar, och de två är inte utbytbara. Om den angivna metoden är en du inte kan betjäna besvarar det importfrågan.

Kontroll 3: hubben, användaren och administratörsrollen

För inbyggd åtkomst anger profilen en Virtual Hub och en användare i den. A hub is a logical VPN server instance with its own users and its own settings, och användaren är medlem i den hubben med egen autentisering. Ingen av dem är serveradministration, som styr lyssnare, hubbar och varje användare i installationen. En klientprofil bör aldrig komma med den kontrollen fäst vid sig. När någon skickar dig en administratörsuppgift för att få en klient att fungera är uppsättningen fel, oavsett om den ansluter eller inte.

Håll de tre åtskilda när du dokumenterar anslutningen, eftersom de återkallas olika. Att ta bort en hubb-användare avslutar en persons åtkomst och lämnar resten av installationen orörd, medan rotation av administratörsuppgiften rör allt. Skillnaden är också skälet att stå emot en delad hubb-användare för ett team, eftersom en enda uppgift innebär en enda återkallelsehändelse för alla.

Kontroll 4: filen är lika känslig som det den bär

Beroende på formatet kan en profil bära ett sparat lösenord, ett certifikat eller en fördelad nyckel. Behandla exporten som en hemlighet så länge den finns, eftersom kopian du bifogar ett ärende är en kopia som någon annan kan importera. Ta bort uppgiften innan du delar, eller dela en nygenererad profil med en ny hemlighet. Filens känslighet kommer från innehållet, inte från filändelsen eller storleken.

Bekräfta endpointen via en kanal som operatören publicerar, och behandla en katalogetikett som overifierad. En landsflagga och ett värdnamn i en offentlig nodlista väljs av den som skickade in posten, så ingen av dem fastställer vem som driver servern. Om profilen kom från en offentlig katalog är det ett skäl till fler kontroller, inte färre.

Anteckna var filen kom ifrån och när du tog emot den. När en anslutning senare beter sig annorlunda är ursprunget det första att jämföra med den verifierade endpointen. En profil utan ursprung är en profil du inte kan granska.

Arkivera kopian du verifierade, inte den du hittade senare. Två filer med samma namn och olika endpoints är hur en fungerande import blir ett supportärende. Förvara den verifierade kopian bredvid anteckningen om var den kom ifrån.

Kontroll 5: testa applikationen, inte statuslampan

Efter importen ska du testa den applikation du faktiskt behöver i stället för anslutningsindikatorn. En lyckad autentisering visar att inloggningsuppgifterna fungerar, inte att de rutter eller den DNS du förväntade dig följde med sessionen. Anslut och använd sedan den tjänst som profilen skulle nå.

Granska de tilldelade rutterna och DNS-servrarna, och notera vilka destinationer som kringgår tunneln om designen har en split. Upprepa sedan med en destination som borde vara utesluten, eftersom en delad tunnel som skickar allt genom tunneln ändå klarar ett test med en enda destination. Om en privat resurs misslyckas är rutten den misstänkta före inloggningsuppgiften. Skriv ned de fyra resultaten: autentiserad, tjänst nåbar, rutter som förväntat, utesluten destination utesluten.

Jämför alla fyra resultaten med vad operatören lovade för denna hubb. En session som autentiseras medan den uteslutna destinationen också är nåbar betyder att delningen inte är i kraft och att profilen inte är problemet. Rätta förväntningen eller hubbpolicyn och kör sedan de fyra kontrollerna igen i samma ordning.

Relaterade artiklar