Bakit nabibigo ang pag-login sa openfortivpn kapag ini-paste mo ang URL ng portal
Ang landas ng portal tulad ng /ext ay hindi realm. Ibigay ang gateway bilang host at port, itakda ang realm nang hiwalay, at panatilihin ang hostname upang pumasa pa rin ang mga pagsusuri ng TLS.
Ang kabiguan ay mukhang problema sa mga kredensyal: hinihingi ng openfortivpn ang password, ipinapadala ito, at sumasagot ang gateway ng pagtanggi o pag-redirect pabalik sa pahina ng pag-login. Pagkatapos ay i-type muli ng mga user ang password, subukan ang account name na may domain, at sa huli ay i-paste ang URL ng portal mula sa browser sa field ng host. Ang huling galaw na iyon ang gumagawa ng maliit na pagkakamali sa configuration na maging nakalilito.
Ang address ng portal ng Fortinet tulad ng https://vpn.example.com/ext ay nagdadala ng ilang piraso ng impormasyon nang sabay, at ilan lamang sa mga ito ang pag-aari ng VPN client.
Ang endpoint at realm ay magkahiwalay na input
Inaasahan ng openfortivpn ang isang endpoint sa anyong host o host:port, kasama ang isang account at, kung gumagamit ang deployment ng isa, isang halaga ng realm. Sinasabi ng realm sa gateway kung anong patakaran ng authentication ang ilalapat bago suriin ang account. Ito ay hiwalay na field, hindi suffix na kinukuha ng client mula sa URL.
Para sa deployment na kinukumpirma ng operator na ang realm ay ext, ganito ang hitsura ng isang hindi lihim na tawag: openfortivpn vpn.example.com:443 --username=alice --realm=ext. Ang parehong mga halaga ay napupunta sa configuration file bilang mga entry na host, port, username at realm. Iwanan ang password sa labas ng dalawang anyo at hayaang hilingin ito ng client, upang hindi ito mapunta sa kasaysayan ng shell o sa file na mababasa ng lahat. Ang pangalawang pagtatangka habang hawak pa ng unang client ang tunnel ay mabibigo dahil sa dahilang walang kinalaman sa realm.
manwal ng openfortivpn ay naglilista ng parehong opsyon, kaya madaling kumpirmahin ang eksaktong baybay bago tumawag sa suporta. Gayunpaman, hindi nito masasabi kung aling realm ang naka-configure sa iyong gateway.
Ang segment ng landas ay hindi awtomatikong realm
Ang mga URL ng portal ay nangongolekta ng iba't ibang bagay pagkatapos ng hostname: isang application ng pag-login, isang tagapili ng wika, isang target ng redirect, isang identifier ng session. Ang pagputol ng huling segment ng landas at pagtawag dito na realm ay gumagana nang sapat na madalas upang maging mapanganib. Itanong sa operator ang naka-configure na halaga, o basahin ito mula sa profile na ipinamimigay ng iyong organisasyon.
Ang realm ay hindi rin kapareho ng suffix ng domain sa username o ng rehiyon kung saan naroroon ang gateway. Gusto ng ilang deployment ang alice, gusto ng iba ang alice@corp, at ang realm ang nagpasya kung alin sa mga ito ang tatanggapin ng gateway. Ang pagbabago ng format ng account upang mabayaran ang maling realm ay karaniwang gumagawa ng pangalawa, hindi gaanong informative na pagtanggi.
Huwag ayusin ang error sa realm sa pamamagitan ng pagbabago ng host
Ang pagpapalit ng hostname ng isang IP address ay parang pagtanggal ng isang layer, at mas marami itong nasisira kaysa naaayos. Ang validation ng pangalan sa TLS ay naghahambing ng certificate sa pangalang ginamit ng client, at ang IP address ay bihirang lumitaw sa mga alternatibong subject name ng certificate. Nagbabago ang server name indication kasama ng address, kaya ang gateway na nagho-host ng ilang portal sa isang address ay maaaring sumagot ng mali. Panatilihing buo ang hostname at ang configuration ng tiwala habang itinatama mo ang parameter ng authentication.
Kung ang certificate ay hindi pinagkakatiwalaan sa iyong kapaligiran, ayusin ang trust store o sadyang i-pin ang inaasahang certificate. Ang pagpapahinto ng verification upang lampasan ang error sa realm ay nagpapalit ng problema sa pag-login ng panganib ng tahimik na interception.
Ihiwalay ang tinanggihang login mula sa nabigong tunnel
Ang mga kabiguan sa authentication at kabiguan sa tunnel ay dumarating sa magkaibang sandali, at magkaiba ang mga mensahe. Ang error sa paglutas ng pangalan ay nangyayari bago ang anumang TLS handshake. Ang pagtanggi ng TLS ay nangyayari bago ipadala ang mga kredensyal. Ang pagtanggi ng realm o account ay bumabalik bilang sagot sa antas ng HTTP mula sa portal. Pagkatapos lamang ng mga yugtong iyon magsisimula ang negosasyon ng PPP, at doon lamang lumilitaw ang mga problema sa routing at DNS.
Ang tamang realm ay hindi gumagawa ng nawawalang ruta at hindi pinapagana ang isang hindi suportadong paraan ng pag-sign in. Kung iginigiit ng portal ang daloy na nakabatay sa browser, gamitin ang suportadong landas ng client para sa daloy na iyon sa halip na ulitin ang palitan ng password at umasang magtutugma ang session.
Itago ang mga halaga kung saan makikita ng susunod na paglulunsad
Kapag nagtagumpay ang koneksyon, isulat ang gateway, port, account at realm sa pinamamahalaang profile sa halip na sa isang alias ng shell. Ang mga profile na itinatago sa isang repository o sistema ng pamamahala ng configuration ay pumipigil sa susunod na paglulunsad na tahimik na kunin ang realm ng ibang profile.
Subukan muli ang isang koneksyon mula simula hanggang dulo at kumpirmahin ang parehong patakarang inilapat at ang pag-access sa isang resource na talagang kailangan mo. Ang tagumpay ng authentication ay simula ng pagsusuring iyon, hindi ang wakas.