Kial openfortivpn-ensaluto malsukcesas, kiam vi algluas la URL-on de la portalo

La malsukceso aspektas kiel problemo pri akreditiloj: openfortivpn petas la pasvorton, sendas ĝin, kaj la enirejo respondas per rifuzo aŭ per alidirektado reen al la ensaluta paĝo. Tiam uzantoj denove tajpas la pasvorton, provas la domajne kvalifikitan kontan nomon kaj fine algluas la portalan URL-on de la retumilo en la gastigantan kampon. Ĝuste tiu lasta movo igas malgrandan agordan eraron konfuza.

Fortinet-portala adreso kiel https://vpn.example.com/ext portas plurajn informpecojn samtempe, kaj nur kelkaj el ili apartenas al la VPN-kliento.

La finpunkto kaj la realm estas apartaj enigoj

openfortivpn atendas finpunkton en la formo host aŭ host:port, kune kun konto kaj, kie la deplojo uzas unu, realm-valoro. La realm diras al la enirejo, kiun aŭtentikigan politikon apliki antaŭ ol ĝi pritaksos la konton. Ĝi estas aparta kampo, ne sufikso, kiun la kliento eltiras el URL.

Por deplojo, kies administranto konfirmas, ke la realm estas ext, nesekreta alvoko aspektas tiel: openfortivpn vpn.example.com:443 --username=alice --realm=ext. La samaj valoroj apartenas al la agorda dosiero kiel rikordoj host, port, username kaj realm. Lasu la pasvorton ekster ambaŭ formoj kaj lasu la klienton demandi ĝin, por ke ĝi ne eniru la ŝelan historion aŭ dosieron legeblan de ĉiuj. Dua provo, dum la unua kliento ankoraŭ tenas la tunelon, malsukcesos pro kialo tute ne rilata al la realm.

La manlibro de openfortivpn listigas ambaŭ opciojn, do la ĝusta literumo facile konfirmeblas antaŭ subtena alvoko. Ĝi tamen ne povas diri al vi, kiun realm via enirejo havas agorditan.

Vojsegmento ne estas aŭtomate realm

Portalaj URL-oj kolektas ĉiaspecajn aferojn post la gastiganta nomo: ensalutan aplikaĵon, lingvoselektilon, alidirektan celon, sean-identigilon. Tranĉi la lastan vojsegmenton kaj nomi ĝin realm funkcias sufiĉe ofte, por ke ĝi estu danĝera. Demandu la administranton pri la agordita valoro aŭ legu ĝin el la profilo, kiun via organizo disdonas.

Realm ankaŭ ne samas kiel domajna sufikso ĉe la uzantnomo aŭ la regiono, en kiu troviĝas la enirejo. Iuj deplojoj volas alice, aliaj volas alice@corp, kaj la realm decidas, kiun el tiuj la enirejo akceptos. Ŝanĝi la kontan formaton por kompensi malĝustan realm kutime produktas duan, malpli informan rifuzon.

Ne ripari realm-eraron ŝanĝante la gastiganton

Anstataŭigi la gastigantan nomon per IP-adreso sentiĝas kiel forigi tavolon, kaj ĝi rompas pli ol ĝi riparas. TLS-nomkontrolo komparas la atestilon kun la nomo, kiun la kliento uzis, kaj IP-adreso malofte aperas en la alternativaj subjektaj nomoj de atestilo. La indiko de servila nomo ŝanĝiĝas kun la adreso, do enirejo, kiu gastigas plurajn portalojn sur unu adreso, povas respondi per la malĝusta. Konservu la gastigantan nomon kaj la fidoagordon sendifekte, dum vi korektas la aŭtentikigan parametron.

Se la atestilo ne estas fidinda en via medio, riparu la fidservon aŭ intence fiksu la atendatan atestilon. Malŝalti kontroladon por preterpasi realm-eraron interŝanĝas ensalutan problemon kontraŭ riskon de silenta interkapto.

Apartigu rifuzitan ensaluton de fiaskinta tunelo

Aŭtentikigaj fiaskoj kaj tunelaj fiaskoj alvenas en malsamaj momentoj, kaj la mesaĝoj malsamas. Noma solva eraro okazas antaŭ ajna TLS-manpremo. TLS-rifuzo okazas antaŭ ol sendiĝas akreditiloj. Rifuzo de realm aŭ konto revenas kiel respondo je HTTP-nivelo de la portalo. Nur post tiuj etapoj komenciĝas PPP-intertraktado, kaj nur tiam aperas problemoj pri enkursigado kaj DNS.

Ĝusta realm ne kreas mankantan vojon kaj ne igas funkcii neaprobatan ensalutan metodon. Se la portalo insistas pri retumila fluo, uzu la klientan subtenatan vojon por tiu fluo anstataŭ ripeti pasvortinterŝanĝon kaj esperi, ke la seanco kongruos.

Konservu la valorojn tie, kie la sekva lanĉo trovos ilin

Post sukcesa konekto, skribu la enirejon, pordon, konton kaj realm en la administritan profilon anstataŭ ŝelan kaŝnomon. Profiloj tenataj en deponejo aŭ agorda administra sistemo malhelpas, ke la sekva lanĉo silente prenu la realm de alia profilo.

Retestu unu konekton de komenco ĝis fino kaj konfirmu kaj la aplikitan politikon kaj aliron al rimedo, kiun vi vere bezonas. Sukceso de aŭtentikigo estas la komenco de tiu kontrolo, ne ĝia fino.