Importen av profilen lykkes, men autentiseringen mislykkes fordi filen peker på en Virtual Hub som kontoen aldri har blitt med i. Ingenting i filen er feilformet; den beskriver en ordning som påloggingsinformasjonen ikke ble utstedt for. Seks felt avgjør om importen kan fungere: vertsnavn, port, protokoll, Virtual Hub, brukeridentitet, og om noen ved en feil ga deg en administratorlegitimasjon. Sjekk én til tre dekker disse feltene i rekkefølge, og de to siste dekker selve filen og det du faktisk ble med i.

Sjekk 1: vertsnavnet og porten

Les vertsnavnet, porten og den oppgitte tilgangsmetoden før du importerer noe. Den innebygde SoftEther-lytteren svarer normalt på TCP 443, med 992 og 5555 som alternativer som operatører åpner for klienter bak restriktive nettverk. En profil rettet mot en port som betjener et nettsted eller en annen tjeneste, mislykkes før autentiseringen og rapporterer feilen som en påloggingsfeil. Sammenlign paret med det operatøren publiserer for dette endepunktet, ikke med en katalogliste som noen samlet inn i fjor. Hvis vertsnavnet løses opp til en adresse operatøren aldri nevner, stopp der, fordi neste steg sender påloggingsinformasjon til den adressen.

Port 443 er felles territorium, så porten alene beviser ingenting om tjenesten bak. En SoftEther-klient skiller de to gjennom protokollhåndtrykket, og derfor kan en profil peke på riktig port og likevel ende mot en webserver. Den feilen ser ut som et feil passord i klientloggen, selv om ingen passord noen gang ble kontrollert.

Skriv ned endepunktet som vertsnavn, port og metode, i den rekkefølgen. Den trioen er den delen du kan kontrollere uten å koble til, og det er den delen du siterer når du spør operatøren om lytteren fortsatt er oppe. Alt du ikke kan fylle ut fra en publisert kilde, forblir uverifisert i stedet for antatt.

Sjekk 2: protokollen avgjør klienten

En server som tilbyr flere tilgangsmetoder gjør ikke én eksportert fil til en profil som hver klient kan åpne. Each method has its own format, its own client and its own failure mode, og å blande dem gir feil som høres ut som påloggingsproblemer. Avgjør hvilken metode filen oppgir, før du avgjør hvilken klient som åpner den.

Tabellen nedenfor viser de vanlige portene og hva hver metode faktisk krever. Porter er operatørens valg, så behandle dem som standardverdier og ikke som fakta om en bestemt server. En innebygd SoftEther-profil importeres av SoftEther-klienten, et ovpn-pakke hører til OpenVPN, og SSTP- eller L2TP-profiler håndteres av operativsystemet selv. Å installere en ekstra klient for å åpne en fil som den første avviser, gjør vanligvis en klar feil 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

Les erklæringen inne i filen i stedet for filtypen. En fil som er oppkalt etter OpenVPN er per definisjon en OpenVPN-profil, mens en SoftEther-profil er en liten konfigurasjon som SoftEther-klienten importerer, og de to kan ikke byttes om. Hvis den oppgitte metoden er en du ikke kan betjene, besvarer det importspørsmålet.

Sjekk 3: huben, brukeren og administratorrollen

For innebygd tilgang navngir profilen en Virtual Hub og en bruker i den. A hub is a logical VPN server instance with its own users and its own settings, og brukeren er medlem av den huben med sin egen autentisering. Ingen av dem er serveradministrasjon, som styrer lyttere, huber og hver bruker i utrullingen. En klientprofil bør aldri komme med den kontrollen festet til seg. Når noen sender deg en administratorlegitimasjon for å få en klient til å virke, er ordningen feil, enten den kobler til eller ikke.

Hold de tre fra hverandre når du dokumenterer tilkoblingen, fordi de tilbakekalles ulikt. Å fjerne en hub-bruker avslutter én persons tilgang og lar resten av utrullingen være urørt, mens rotasjon av administratorlegitimasjonen berører alt. Forskjellen er også grunnen til å motsette seg én delt hub-bruker for et team, siden én legitimasjon betyr én tilbakekallingshendelse for alle.

Sjekk 4: filen er like følsom som det den bærer

Avhengig av formatet kan en profil bære et lagret passord, et sertifikat eller en forhåndsdelt nøkkel. Behandle eksporten som en hemmelighet så lenge den finnes, fordi kopien du legger ved en sak er en kopi noen andre kan importere. Fjern legitimasjonen før du deler, eller del en nygenerert profil med en ny hemmelighet. Filens følsomhet kommer fra innholdet, ikke fra filtypen eller størrelsen.

Bekreft endepunktet gjennom en kanal operatøren publiserer, og behandle en katalogetikett som uverifisert. Et landflagg og et vertsnavn i en offentlig nodeliste velges av den som sendte inn oppføringen, så ingen av dem fastslår hvem som driver serveren. Hvis profilen kom fra en offentlig katalog, er det en grunn til flere sjekker, ikke færre.

Noter hvor filen kom fra og når du mottok den. Når en tilkobling senere oppfører seg annerledes, er opprinnelsen det første du sammenligner med det verifiserte endepunktet. En profil uten opprinnelse er en profil du ikke kan revidere.

Arkiver kopien du verifiserte, ikke den du fant senere. To filer med samme navn og ulike endepunkter er måten en fungerende import blir en støttesak. Oppbevar den verifiserte kopien ved siden av notatet om hvor den kom fra.

Sjekk 5: test applikasjonen, ikke statuslampen

Etter importen skal du teste applikasjonen du faktisk trenger, i stedet for tilkoblingsindikatoren. En vellykket autentisering viser at påloggingsinformasjonen virker, ikke at rutene eller DNS-en du forventet fulgte med økten. Koble til, og bruk deretter tjenesten profilen skulle nå.

Inspiser de tildelte rutene og DNS-serverne, og noter hvilke destinasjoner som omgår tunnelen hvis designet har en splitt. Gjenta deretter med én destinasjon som burde være utelukket, fordi en delt tunnel som sender alt gjennom tunnelen, likevel består en test med én destinasjon. Hvis en privat ressurs feiler, er ruten den mistenkte før legitimasjonen. Skriv ned de fire resultatene: autentisert, tjeneste nåbar, ruter som forventet, utelukket destinasjon utelukket.

Sammenlign alle fire resultatene med det operatøren lovet for denne huben. En økt som autentiseres mens den utelukkede destinasjonen også er nåbar, betyr at splitten ikke er i kraft og at profilen ikke er problemet. Rett forventningen eller hub-policyen, og kjør deretter de fire sjekkene igjen i samme rekkefølge.

Relaterte artikler