Importen af profilen lykkes, men godkendelsen fejler, fordi filen peger på en Virtual Hub, som kontoen aldrig er blevet medlem af. Intet i filen er forkert udformet; den beskriver en opsætning, som legitimationsoplysningerne ikke er udstedt til. Seks felter afgør, om importen kan virke: værtsnavn, port, protokol, Virtual Hub, brugeridentitet, og om nogen ved en fejl har givet dig en administratorlegitimation. Tjek et til tre dækker disse felter i rækkefølge, og de sidste to dækker selve filen og det, du faktisk er blevet medlem af.

Tjek 1: værtsnavnet og porten

Læs værtsnavnet, porten og den angivne adgangsmetode, før du importerer noget. Den native SoftEther-listener svarer normalt på TCP 443, med 992 og 5555 som alternativer, som operatører åbner for klienter bag restriktive netværk. En profil rettet mod en port, der betjener et websted eller en anden tjeneste, fejler før godkendelsen og rapporterer fejlen som en legitimationsfejl. Sammenlign parret med det, operatøren offentliggør for dette endpoint, ikke med en katalogoversigt, som nogen indsamlede sidste år. Hvis værtsnavnet opløses til en adresse, som operatøren aldrig nævner, så stop der, fordi næste skridt sender legitimationsoplysninger til den adresse.

Port 443 er fælles territorium, så porten alene beviser intet om tjenesten bag den. En SoftEther-klient adskiller de to via protokolhåndtrykket, og derfor kan en profil pege på den rigtige port og alligevel ende mod en webserver. Den fejl ser ud som en forkert adgangskode i klientloggen, selv om ingen adgangskode nogensinde blev kontrolleret.

Skriv endpointet ned som værtsnavn, port og metode, i den rækkefølge. Den tripel er den del, du kan kontrollere uden at forbinde, og det er den del, du citerer, når du spørger operatøren, om listeneren stadig kører. Alt, hvad du ikke kan udfylde fra en offentliggjort kilde, forbliver uverificeret i stedet for antaget.

Tjek 2: protokollen bestemmer klienten

En server, der tilbyder flere adgangsmetoder, gør ikke én eksporteret fil til en profil, som enhver klient kan åbne. Each method has its own format, its own client and its own failure mode, og at blande dem giver fejl, der lyder som legitimationsproblemer. Afgør, hvilken metode filen angiver, før du afgør, hvilken klient der åbner den.

Tabellen nedenfor viser de sædvanlige porte og hvad hver metode faktisk kræver. Porte er operatørens valg, så behandl dem som standardværdier og ikke som fakta om en bestemt server. En native SoftEther-profil importeres af SoftEther-klienten, et ovpn-bundt hører til OpenVPN, og SSTP- eller L2TP-profiler håndteres af selve operativsystemet. At installere en ekstra klient for at åbne en fil, som den første afviser, gør normalt en klar fejl til en forvirrende.

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 erklæringen inde i filen i stedet for filtypen. En fil, der er opkaldt efter OpenVPN, er per definition en OpenVPN-profil, mens en SoftEther-profil er en lille konfiguration, som SoftEther-klienten importerer, og de to kan ikke udskiftes. Hvis den angivne metode er en, du ikke kan betjene, besvarer det importspørgsmålet.

Tjek 3: hubben, brugeren og administratorrollen

Til native adgang angiver profilen en Virtual Hub og en bruger i den. A hub is a logical VPN server instance with its own users and its own settings, og brugeren er medlem af den hub med sin egen godkendelse. Ingen af dem er serveradministration, som styrer listenere, hubs og hver bruger på udrulningen. En klientprofil bør aldrig ankomme med den kontrol hæftet på. Når nogen sender dig en administratorlegitimation for at få en klient til at virke, er opsætningen forkert, uanset om den forbinder eller ej.

Hold de tre adskilt, når du dokumenterer forbindelsen, fordi de tilbagekaldes forskelligt. At fjerne en hub-bruger afslutter én persons adgang og lader resten af udrulningen være urørt, mens rotation af administratorlegitimationen berører alt. Forskellen er også grunden til at afvise én delt hub-bruger til et team, da én legitimationsoplysning betyder én tilbagekaldelseshændelse for alle.

Tjek 4: filen er lige så følsom som det, den bærer

Afhængigt af formatet kan en profil bære en gemt adgangskode, et certifikat eller en forudelt nøgle. Behandl eksporten som en hemmelighed, så længe den findes, fordi den kopi, du vedhæfter en sag, er en kopi, som en anden kan importere. Fjern legitimationsoplysningen, før du deler, eller del en nygenereret profil med en ny hemmelighed. Filens følsomhed kommer fra indholdet, ikke fra dens filtype eller størrelse.

Bekræft endpointet gennem en kanal, som operatøren offentliggør, og behandl et katalogmærke som uverificeret. Et landeflag og et værtsnavn på en offentlig nodeliste vælges af den, der indsendte posten, så ingen af dem fastslår, hvem der driver serveren. Hvis profilen kom fra en offentlig katalog, er det en grund til flere tjek, ikke færre.

Notér, hvor filen kom fra, og hvornår du modtog den. Når en forbindelse senere opfører sig anderledes, er oprindelsen det første, du sammenligner med det verificerede endpoint. En profil uden oprindelse er en profil, du ikke kan revidere.

Arkivér den kopi, du verificerede, i stedet for den, du fandt senere. To filer med samme navn og forskellige endpoints er måden, hvorpå en fungerende import bliver en supportsag. Opbevar den verificerede kopi ved siden af noten om, hvor den kom fra.

Tjek 5: test applikationen, ikke statuslampen

Efter importen skal du teste den applikation, du faktisk har brug for, i stedet for forbindelsesindikatoren. En vellykket godkendelse viser, at legitimationsoplysningerne virker, ikke at de ruter eller den DNS, du forventede, fulgte med sessionen. Forbind, og brug derefter den tjeneste, som profilen skulle nå.

Undersøg de tildelte ruter og DNS-serverne, og notér, hvilke destinationer der omgår tunnelen, hvis designet har en split. Gentag derefter med én destination, der burde være udelukket, fordi en split-tunnel, der sender alt gennem tunnelen, alligevel består en test med én destination. Hvis en privat ressource fejler, er ruten den mistænkte før legitimationsoplysningen. Skriv de fire resultater ned: godkendt, tjeneste tilgængelig, ruter som forventet, udelukket destination udelukket.

Sammenlign alle fire resultater med det, operatøren lovede for denne hub. En session, der godkendes, mens den udelukkede destination også er tilgængelig, betyder, at splittet ikke er i kraft, og at profilen ikke er problemet. Ret forventningen eller hub-politikken, og kør derefter de fire tjek igen i samme rækkefølge.

Relaterede artikler