SoftEther-verbindingsprofiel: kontroleer ses velde voor invoer
Ses velde bepaal of 'n SoftEther-profiel werk. Gaan die eindpunt, poort, protokol, hub, gebruiker en rol in volgorde na en toets dan waaraan jy werklik gekoppel het.
Die invoer van die profiel slaag, maar verifikasie misluk omdat die lêer na 'n Virtual Hub wys waarby die rekening nooit aangesluit het nie. Niks in die lêer is wanvormig nie; dit beskryf 'n reëling waarvoor die geloofsbriewe nie uitgereik is nie. Ses velde bepaal of die invoer kan werk: hostnaam, poort, protokol, Virtual Hub, gebruikersidentiteit en of iemand per ongeluk vir jou 'n administrateur-geloofsbrief gegee het. Kontroles een tot drie dek daardie velde in volgorde, en die laaste twee dek die lêer self en waaraan jy werklik aangesluit het.
Kontrole 1: die hostnaam en die poort
Lees die hostnaam, die poort en die verklaarde toegangsmetode voordat jy enigiets invoer. Die inheemse SoftEther-luisteraar antwoord gewoonlik op TCP 443, met 992 en 5555 as alternatiewe wat operateurs oopmaak vir kliënte agter beperkende netwerke. 'n Profiel wat op 'n poort gemik is wat 'n webwerf of 'n ander diens bedien, misluk voor verifikasie en rapporteer die fout as 'n geloofsbriefprobleem. Vergelyk die paar met wat die operateur vir hierdie eindpunt publiseer, nie met 'n gidslys wat iemand verlede jaar versamel het nie. As die hostnaam na 'n adres oplos wat die operateur nooit noem nie, stop daar, want die volgende stap stuur geloofsbriewe na daardie adres.
Poort 443 is gemeenskaplike gebied, so die poort alleen bewys niks oor die diens daarby. 'n SoftEther-kliënt skei die twee met die protokol-handdruk, daarom kan 'n profiel na die regte poort wys en tog by 'n webbediener eindig. Daardie fout lyk soos 'n verkeerde wagwoord in die kliëntlog, al is geen wagwoord ooit nagegaan nie.
Skryf die eindpunt neer as hostnaam, poort en metode, in daardie volgorde. Hierdie drietal is die deel wat jy sonder verbinding kan verifieer, en dit is die deel wat jy aanhaal wanneer jy die operateur vra of die luisteraar nog werk. Enigiets wat jy nie uit 'n gepubliseerde bron kan invul nie, bly ongeverifieer eerder as aangeneem.
Kontrole 2: die protokol bepaal die kliënt
'n Bediener wat verskeie toegangsmetodes bied, verander nie een uitgevoerde lêer in 'n profiel wat elke kliënt kan oopmaak nie. Each method has its own format, its own client and its own failure mode, en om hulle te meng lewer foute op wat soos geloofsbriefprobleme klink. Besluit watter metode die lêer verklaar voordat jy besluit watter kliënt dit oopmaak.
Die tabel hieronder lys die konvensionele poorte en wat elke metode werklik vereis. Poorte is die operateur se keuse, so hanteer hulle as verstekwaardes en nie as feite oor 'n spesifieke bediener nie. 'n Inheemse SoftEther-profiel word deur die SoftEther-kliënt ingevoer, 'n ovpn-bundel hoort by OpenVPN, en SSTP- of L2TP-profiele word deur die bedryfstelsel self verwerk. Om 'n tweede kliënt te installeer om 'n lêer oop te maak wat die eerste verwerp, verander gewoonlik 'n duidelike fout in 'n verwarrende een.
| 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 |
Lees die verklaring binne die lêer, nie die uitbreiding nie. 'n Lêer wat na OpenVPN vernoem is, is per definisie 'n OpenVPN-profiel, terwyl 'n SoftEther-profiel 'n klein konfigurasie is wat die SoftEther-kliënt invoer, en die twee is nie uitruilbaar nie. As die verklaarde metode een is wat jy nie kan bedien nie, beantwoord dit die invoervraag.
Kontrole 3: die hub, die gebruiker en die administrateurrol
Vir inheemse toegang noem die profiel 'n Virtual Hub en 'n gebruiker daarbinne. A hub is a logical VPN server instance with its own users and its own settings, en die gebruiker is 'n lid van daardie hub met sy eie verifikasie. Nie een van die twee is bedieneradministrasie nie, wat luisteraars, hubs en elke gebruiker in die ontplooiing beheer. 'n Kliëntprofiel behoort nooit met daardie beheer daaraan geheg te kom nie. Wanneer iemand vir jou 'n administrateur-geloofsbrief stuur om 'n kliënt te laat werk, is die reëling verkeerd, of dit koppel of nie.
Hou die drie apart wanneer jy die verbinding dokumenteer, want hulle word verskillend herroep. Om 'n hub-gebruiker te verwyder beëindig een persoon se toegang en laat die res van die ontplooiing onaangeraak, terwyl die rotasie van die administrateur-geloofsbrief alles raak. Daardie verskil is ook die rede om een gedeelde hub-gebruiker vir 'n span teë te staan, want een geloofsbrief beteken een herroepingsgebeurtenis vir almal.
Kontrole 4: die lêer is so sensitief soos wat dit dra
Afhangend van die formaat kan 'n profiel 'n gestoorde wagwoord, 'n sertifikaat of 'n vooraf gedeelde sleutel dra. Behandel die uitvoer as 'n geheim solank dit bestaan, want die kopie wat jy aan 'n kaartjie heg, is 'n kopie wat iemand anders kan invoer. Verwyder die geloofsbrief voordat jy deel, of deel 'n hergenereerde profiel met 'n nuwe geheim. Die lêer se sensitiwiteit kom uit sy inhoud, nie uit sy uitbreiding of grootte nie.
Bevestig die eindpunt deur 'n kanaal wat die operateur publiseer, en behandel 'n gidsetiket as ongeverifieer. 'n Landvlag en 'n hostnaam in 'n openbare nodelys word gekies deur wie die inskrywing ingestuur het, so nie een van die twee stel vas wie die bediener bestuur nie. As die profiel uit 'n openbare gids kom, is dit 'n rede vir meer kontroles, nie minder nie.
Teken aan waar die lêer vandaan kom en wanneer jy dit ontvang het. Wanneer 'n verbinding later anders optree, is die oorsprong die eerste ding wat jy met die geverifieerde eindpunt vergelyk. 'n Profiel sonder herkoms is 'n profiel wat jy nie kan ouditeer nie.
Argiveer die kopie wat jy geverifieer het, nie die een wat jy later gevind het nie. Twee lêers met dieselfde naam en verskillende eindpunte is hoe 'n werkende invoer 'n ondersteuningsgeval word. Hou die geverifieerde kopie langs die nota oor waar dit vandaan kom.
Kontrole 5: toets die toepassing, nie die statusliggie nie
Toets na die invoer die toepassing wat jy werklik nodig het eerder as die verbindingsaanwyser. 'n Suksesvolle verifikasie bewys dat die geloofsbriewe werk, nie dat die roetes of DNS wat jy verwag het saam met die sessie gekom het nie. Koppel, en gebruik dan die diens wat die profiel moes bereik.
Ondersoek die toegewysde roetes en die DNS-bediener, en let op watter bestemmings die tonnel omseil as die ontwerp 'n splitsing het. Herhaal dan met een bestemming wat uitgesluit behoort te word, want 'n gesplete tonnel wat alles deur die tonnel stuur, slaag steeds 'n toets met een bestemming. As 'n private hulpbron misluk, is die roete die verdagte voor die geloofsbrief. Skryf die vier resultate neer: geverifieer, diens bereikbaar, roetes soos verwag, uitgeslote bestemming uitgesluit.
Vergelyk al vier die resultate met wat die operateur vir hierdie hub belowe het. 'n Sessie wat verifieer terwyl die uitgeslote bestemming ook bereikbaar is, beteken die splitsing is nie van krag nie en die profiel is nie die probleem nie. Reg die verwagting of die hubbeleid, en voer dan die vier kontroles in dieselfde volgorde weer uit.