Profili i lidhjes SoftEther: kontrolloni gjashtë fusha para importit
Gjashtë fusha vendosin nëse një profil SoftEther funksionon. Kontrolloni me radhë pikën fundore, portën, protokollin, qendrën, përdoruesin dhe rolin, pastaj provoni se me çfarë jeni lidhur në të vërtetë.
Importi i profilit ka sukses, por vërtetimi i identitetit dështon sepse skedari tregon një Virtual Hub të cilit llogaria nuk i është bashkuar kurrë. Asgjë në skedar nuk është e dëmtuar; ai përshkruan një konfigurim për të cilin kredencialet nuk janë lëshuar. Gjashtë fusha vendosin nëse importi mund të funksionojë: emri i hostit, porta, protokolli, Virtual Hub, identiteti i përdoruesit dhe nëse dikush ju ka dhënë gabimisht një kredencial administratori. Kontrollet një deri tre i mbulojnë ato fusha me radhë, dhe dy të fundit mbulojnë vetë skedarin dhe atë me të cilën jeni lidhur në të vërtetë.
Kontrolli 1: emri i hostit dhe porta
Lexoni emrin e hostit, portën dhe metodën e deklaruar të aksesit përpara se të importoni çdo gjë. Dëgjuesi vendas i SoftEther përgjigjet normalisht në TCP 443, ndërsa 992 dhe 5555 janë alternativa që operatorët i hapin për klientët pas rrjeteve kufizuese. Një profil i drejtuar nga një port që shërben një faqe web ose një shërbim tjetër dështon përpara vërtetimit dhe e raporton gabimin si problem kredencialesh. Krahasoni çiftin me atë që operatori publikon për këtë pikë fundore, jo me një listë katalogu që dikush mblodhi vitin e kaluar. Nëse emri i hostit zgjidhet në një adresë që operatori nuk e përmend kurrë, ndaloni aty, sepse hapi tjetër dërgon kredenciale në atë adresë.
Porta 443 është territor i përbashkët, prandaj porta vetëm nuk provon asgjë për shërbimin pas saj. Një klient SoftEther i ndan të dyja me shtrëngimin e duarve të protokollit, prandaj një profil mund të tregojë portën e duhur dhe gjithsesi të përfundojë në një server web. Ai gabim duket si fjalëkalim i gabuar në regjistrin e klientit, edhe pse asnjë fjalëkalim nuk u kontrollua kurrë.
Shkruani pikën fundore si emër hosti, portë dhe metodë, në atë rend. Ky treshe është pjesa që mund të verifikoni pa u lidhur, dhe pjesa që citoni kur pyesni operatorin nëse dëgjuesi është ende aktiv. Çdo gjë që nuk mund të plotësoni nga një burim i publikuar mbetet e paverifikuar dhe jo e supozuar.
Kontrolli 2: protokolli vendos klientin
Një server që ofron disa metoda aksesi nuk e kthen një skedar të eksportuar në një profil që çdo klient mund ta hapë. Each method has its own format, its own client and its own failure mode, dhe përzierja e tyre prodhon gabime që tingëllojnë si probleme kredencialesh. Vendosni se cilën metodë deklaron skedari përpara se të vendosni cili klient e hap atë.
Tabela më poshtë rendit portat konvencionale dhe çfarë kërkon në të vërtetë secila metodë. Portat janë zgjedhja e operatorit, prandaj trajtojini si vlera të paracaktuara dhe jo si fakte për një server të caktuar. Një profil vendas SoftEther importohet nga klienti SoftEther, një paketë ovpn i përket OpenVPN, dhe profilet SSTP ose L2TP përpunohen nga vetë sistemi operativ. Instalimi i një klienti të dytë për të hapur një skedar që i pari e refuzon zakonisht e kthen një gabim të qartë në një të ngatërruar.
| 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 |
Lexoni deklaratën brenda skedarit, jo shtesën. Një skedar i emërtuar sipas OpenVPN është sipas përkufizimit një profil OpenVPN, ndërsa një profil SoftEther është një konfigurim i vogël që klienti SoftEther e importon, dhe të dy nuk janë të këmbyeshëm. Nëse metoda e deklaruar është një që nuk mund ta shërbeni, kjo i përgjigjet pyetjes së importit.
Kontrolli 3: qendra, përdoruesi dhe roli i administratorit
Për akses vendas, profili emërton një Virtual Hub dhe një përdorues brenda tij. A hub is a logical VPN server instance with its own users and its own settings, dhe përdoruesi është anëtar i asaj qendre me vërtetimin e vet. Asnjëri prej tyre nuk është administrimi i serverit, i cili kontrollon dëgjuesit, qendrat dhe çdo përdorues të vendosjes. Një profil klienti nuk duhet të vijë kurrë me atë kontroll të bashkangjitur. Kur dikush ju dërgon një kredencial administratori që një klient të funksionojë, konfigurimi është i gabuar, pavarësisht nëse lidhet apo jo.
Mbani të tre të ndarë kur dokumentoni lidhjen, sepse revokohen ndryshe. Heqja e një përdoruesi qendre i jep fund aksesit të një personi dhe lë pjesën tjetër të vendosjes të paprekur, ndërsa rrotullimi i kredencialit të administratorit prek gjithçka. Ky ndryshim është edhe arsyeja për t'u kundërvënë një përdoruesi të përbashkët qendre për një ekip, sepse një kredencial i vetëm do të thotë një ngjarje e vetme revokimi për të gjithë.
Kontrolli 4: skedari është aq i ndjeshëm sa ajo që mban
Në varësi të formatit, një profil mund të mbajë një fjalëkalim të ruajtur, një certifikatë ose një çelës të parashpërndarë. Trajtojeni eksportimin si sekret për sa kohë që ekziston, sepse kopja që bashkëngjitni në një kërkesë është një kopje që dikush tjetër mund ta importojë. Hiqni kredencialin përpara se të ndani, ose ndani një profil të rigjeneruar me një sekret të re. Ndjeshmëria e skedarit vjen nga përmbajtja, jo nga shtesa ose madhësia.
Konfirmoni pikën fundore përmes një kanali që operatori publikon, dhe trajtoni një etiketë katalogu si të paverifikuar. Një flamur vendi dhe një emër hosti në një listë publike nyjesh zgjidhen nga ai që e dërgoi hyrjen, prandaj asnjëri nuk përcakton kush e drejton serverin. Nëse profili erdhi nga një katalog publik, kjo është arsye për më shumë kontrolle, jo më pak.
Shënoni nga erdhi skedari dhe kur e morët. Kur një lidhje më vonë sillet ndryshe, origjina është gjëja e parë që krahasoni me pikën fundore të verifikuar. Një profil pa origjinë është një profil që nuk mund ta auditoni.
Arkivoni kopjen që verifikuat, jo atë që gjetët më vonë. Dy skedarë me të njëjtin emër dhe pika fundore të ndryshme janë mënyra se si një import funksional bëhet një rast mbështetjeje. Mbani kopjen e verifikuar pranë shënimit për origjinën e saj.
Kontrolli 5: provoni aplikacionin, jo dritën e statusit
Pas importit, provoni aplikacionin që ju nevojitet vërtet në vend të treguesit të lidhjes. Një vërtetim i suksesshëm provon që kredencialet funksionojnë, jo që rrugët ose DNS-ja që prisnit erdhën me sesionin. Lidhuni, pastaj përdorni shërbimin që profili duhej të arrinte.
Shqyrtoni rrugët e caktuara dhe serverët DNS, dhe shënoni cilat destinacione e anashkalojnë tunelin nëse dizajni ka një ndarje. Pastaj përsëriteni me një destinacion që duhet të përjashtohet, sepse një tunel i ndarë që dërgon gjithçka përmes tunelit e kalon gjithsesi një test me një destinacion. Nëse një burim privat dështon, rruga është e dyshuara përpara kredencialit. Shënoni katër rezultatet: vërtetuar, shërbimi i arritshëm, rrugët siç pritej, destinacioni i përjashtuar i përjashtuar.
Krahasoni të katër rezultatet me atë që operatori premtoi për këtë qendër. Një sesion që vërtetohet ndërsa destinacioni i përjashtuar është gjithashtu i arritshëm do të thotë që ndarja nuk është në fuqi dhe që profili nuk është problemi. Rregulloni pritshmërinë ose politikën e qendrës, pastaj rikryeni katër kontrollet në të njëjtin rend.