SoftEther-tilkoplingsprofil: sjekk seks felt før import
Seks felt avgjer om ein SoftEther-profil fungerer. Sjekk endepunkt, port, protokoll, hub, brukar og rolle i rekkjefølgje, og test deretter kva du faktisk kopla til.
Importen av profilen lukkast, men autentiseringa feilar fordi fila peikar på ein Virtual Hub som kontoen aldri har vorte med i. Ingenting i fila er feilforma; ho skildrar ei ordning som påloggingsinformasjonen ikkje vart utferda for. Seks felt avgjer om importen kan fungere: vertsnamn, port, protokoll, Virtual Hub, brukaridentitet, og om nokon ved ein feil gav deg ein administratorlegitimasjon. Sjekk éin til tre dekkjer desse felta i rekkjefølgje, og dei to siste dekkjer sjølve fila og det du faktisk vart med i.
Sjekk 1: vertsnamnet og porten
Les vertsnamnet, porten og den oppgjevne tilgangsmetoden før du importerer noko. Den innebygde SoftEther-lyttaren svarar normalt på TCP 443, med 992 og 5555 som alternativ som operatørar opnar for klientar bak restriktive nettverk. Ein profil retta mot ein port som tener eit nettstad eller ei anna teneste, feilar før autentiseringa og rapporterer feilen som ein påloggingsfeil. Samanlikn paret med det operatøren publiserer for dette endepunktet, ikkje med ei katalogliste som nokon samla inn i fjor. Viss vertsnamnet blir løyst opp til ei adresse operatøren aldri nemner, stopp der, fordi neste steg sender påloggingsinformasjon til den adressa.
Port 443 er felles territorium, så porten åleine beviser ingenting om tenesta bak. Ein SoftEther-klient skil dei to gjennom protokollhandtrykket, og difor kan ein profil peike på rett port og likevel enda mot ein webserver. Den feilen ser ut som eit feil passord i klientloggen, sjølv om ingen passord nokon gong vart kontrollert.
Skriv ned endepunktet som vertsnamn, port og metode, i den rekkjefølgja. Den trioen er den delen du kan kontrollere utan å kople til, og det er den delen du siterer når du spør operatøren om lyttaren framleis er oppe. Alt du ikkje kan fylle ut frå ein publisert kjelde, blir uverifisert i staden for antatt.
Sjekk 2: protokollen avgjer klienten
Ein server som tilbyr fleire tilgangsmetodar gjer ikkje éi eksportert fil til ein profil som kvar klient kan opne. Each method has its own format, its own client and its own failure mode, og å blande dei gir feil som høyrest ut som påloggingsproblem. Avgjer kva metode fila oppgir, før du avgjer kva klient som opnar henne.
Tabellen nedanfor viser dei vanlege portane og kva kvar metode faktisk krev. Portar er operatørens val, så handsam dei som standardverdiar og ikkje som fakta om ein bestemt server. Ein innebygd SoftEther-profil blir importert av SoftEther-klienten, eit ovpn-pakke høyrer til OpenVPN, og SSTP- eller L2TP-profilar blir handsama av operativsystemet sjølv. Å installere ein ekstra klient for å opne ei fil som den første avviser, gjer vanlegvis ein klar feil til ein forvirrande.
| Access method | Typical port | What the client needs |
|---|---|---|
| SoftEther native | TCP 443, 992 or 5555 | The SoftEther client and a hub name |
| OpenVPN | UDP or TCP 1194 | An ovpn profile and an OpenVPN client |
| SSTP | TCP 443 | Operating system support |
| L2TP over IPsec | UDP 500 and 4500 | Operating system support and the shared key |
Les erklæringa inne i fila i staden for filtypen. Ei fil som er kalla opp etter OpenVPN er per definisjon ein OpenVPN-profil, medan ein SoftEther-profil er ein liten konfigurasjon som SoftEther-klienten importerer, og dei to kan ikkje bytast om. Viss den oppgjevne metoden er ein du ikkje kan tene, svarar det på importspørsmålet.
Sjekk 3: huben, brukaren og administratorrolla
For innebygd tilgang namngir profilen ein Virtual Hub og ein brukar i han. A hub is a logical VPN server instance with its own users and its own settings, og brukaren er medlem av den huben med si eiga autentisering. Ingen av dei er serveradministrasjon, som styrer lyttarar, hubar og kvar brukar i utrullinga. Ein klientprofil bør aldri kome med den kontrollen fest til seg. Når nokon sender deg ein administratorlegitimasjon for å få ein klient til å verke, er ordninga feil, anten ho koplar til eller ikkje.
Hald dei tre frå kvarandre når du dokumenterer tilkoplinga, fordi dei blir trekte tilbake ulikt. Å fjerne ein hub-brukar avsluttar tilgangen til éin person og lèt resten av utrullinga vere urørt, medan rotasjon av administratorlegitimasjonen rører alt. Skilnaden er også grunnen til å motsetje seg éin delt hub-brukar for eit team, sidan éin legitimasjon betyr éi tilbaketrekkinghending for alle.
Sjekk 4: fila er like følsam som det ho ber
Avhengig av formatet kan ein profil bere eit lagra passord, eit sertifikat eller ein førehandsdelt nøkkel. Handsame eksporten som ein hemmelegheit så lenge han finst, fordi kopien du legg ved ei sak er ein kopi nokon andre kan importere. Fjern legitimasjonen før du deler, eller del ein nygenerert profil med ein ny hemmelegheit. Følsemda til fila kjem frå innhaldet, ikkje frå filtypen eller storleiken.
Stadfest endepunktet gjennom ein kanal operatøren publiserer, og handsame ei katalogetikett som uverifisert. Eit landflagg og eit vertsnamn i ei offentleg nodeliste blir valde av den som sende inn oppføringa, så ingen av dei fastslår kven som driv serveren. Viss profilen kom frå ein offentleg katalog, er det ein grunn til fleire sjekkar, ikkje færre.
Noter kvar fila kom frå og når du tok imot ho. Når ei tilkopling seinare oppfører seg annleis, er opphavet det første du samanliknar med det verifiserte endepunktet. Ein profil utan opphav er ein profil du ikkje kan revidere.
Arkiver kopien du verifiserte, ikkje den du fann seinare. To filer med same namn og ulike endepunkt er måten ein fungerande import blir ei støttesak. Oppbevar den verifiserte kopien ved sida av notatet om kvar han kom frå.
Sjekk 5: test applikasjonen, ikkje statuslampa
Etter importen skal du teste applikasjonen du faktisk treng, i staden for tilkoplingsindikatoren. Ei vellukka autentisering viser at påloggingsinformasjonen verkar, ikkje at rutene eller DNS-en du forventa følgde med økta. Kople til, og bruk deretter tenesta profilen skulle nå.
Inspiser dei tildelte rutene og DNS-serverane, og noter kva destinasjonar som omgår tunnelen viss designet har ein splitt. Gjenta deretter med éin destinasjon som burde vere utelukka, fordi ein delt tunnel som sender alt gjennom tunnelen, likevel greier ein test med éin destinasjon. Viss ein privat ressurs feilar, er ruta den mistenkte før legitimasjonen. Skriv ned dei fire resultata: autentisert, teneste nåbar, ruter som forventa, utelukka destinasjon utelukka.
Samanlikn alle fire resultata med det operatøren lova for denne huben. Ei økt som autentiserer medan den utelukka destinasjonen også er nåbar, betyr at splitten ikkje er i kraft og at profilen ikkje er problemet. Rett forventninga eller hub-policyen, og køyr deretter dei fire sjekkane igjen i same rekkjefølgje.