Чаму ўваход у openfortivpn не ўдаецца, калі ўставіць URL партала

Збой выглядае як праблема з уліковымі данымі: openfortivpn запытвае пароль, адпраўляе яго, а шлюз адказвае адмовай ці перанакіраваннем назад на старонку ўваходу. Тады карыстальнікі зноў уводзяць пароль, спрабуюць імя ўліковага запісу з даменам і ўрэшце ўстаўляюць URL партала з браўзера ў поле хоста. Менавіта гэты апошні крок ператварае дробную памылку канфігурацыі ў заблытаную.

Адрас партала Fortinet, напрыклад https://vpn.example.com/ext, нясе адразу некалькі частак інфармацыі, і толькі некаторыя з іх належаць кліенту VPN.

Канчатковы пункт і рэалм — асобныя ўваходныя значэнні

openfortivpn чакае канчатковы пункт у форме host або host:port, а таксама ўліковы запіс і, калі разгортванне яго выкарыстоўвае, значэнне рэалма. Рэалм паведамляе шлюзу, якую палітыку аўтэнтыфікацыі ўжываць перад праверкай уліковага запісу. Гэта асобнае поле, а не суфікс, які кліент вымантачвае з URL.

Для разгортвання, дзе аператар пацвярджае, што рэалм — ext, непатаемны выклік выглядае так: openfortivpn vpn.example.com:443 --username=alice --realm=ext. Тыя ж значэнні належаць у файл канфігурацыі як запісы host, port, username і realm. Пакіньце пароль па-за абодвума формамі і дайце кліенту запытаць яго, каб ён не трапіў у гісторыю абалонкі ці ў файл, чытальны для ўсіх. Другая спроба, пакуль першы кліент яшчэ трымае тунэль, скончыцца няўдачай з прычыны, якая не мае ніякага дачынення да рэалма.

Дапаможнік openfortivpn пералічвае абодва параметры, таму дакладнае напісанне лёгка праверыць перад званком у падтрымку. Але ён не можа сказаць, які рэалм наладжаны на вашым шлюзе.

Сегмент шляху не з’яўляецца рэалмам аўтаматычна

URL партала збіраюць разнастайныя рэчы пасля імя хоста: праграму ўваходу, выбар мовы, мэту перанакіравання, ідэнтыфікатар сеансу. Зрэзаць апошні сегмент шляху і называць яго рэалмам працуе дастаткова часта, каб стаць небяспечным. Спытайце ў аператара наладжанае значэнне або прачытайце яго з профілю, які распаўсюджвае ваша арганізацыя.

Рэалм таксама не тое самае, што суфікс дамена ў імені карыстальніка ці рэгіён, дзе знаходзіцца шлюз. Некаторыя разгортванні хочуць alice, іншыя — alice@corp, і менавіта рэалм вырашае, які з іх шлюз прыме. Змена фармату ўліковага запісу, каб кампенсаваць няправільны рэалм, звычайна дае другую, менш інфарматыўную адмову.

Не выпраўляйце памылку рэалма зменай хоста

Замена імя хоста на IP-адрас выглядае як зняцце аднаго пласта, але ламае больш, чым выпраўляе. Праверка імені TLS параўноўвае сертыфікат з імем, якое выкарыстаў кліент, а IP-адрас рэдка трапляе ў альтэрнатыўныя імёны суб’екта сертыфіката. Паказальнік імя сервера змяняецца разам з адрасам, таму шлюз, які размяшчае некалькі парталаў на адным адрасе, можа адказаць не тым. Захавайце імя хоста і канфігурацыю даверу нязменнымі, пакуль выпраўляеце параметр аўтэнтыфікацыі.

Калі сертыфікат не давяраецца ў вашым асяроддзі, выпраўце сховішча даверу або свядома замацуйце чаканы сертыфікат. Адключэнне праверкі, каб абысці памылку рэалма, мяняе праблему ўваходу на рызыку ціхага перахопу.

Аддзяліце адхілены ўваход ад збою тунэля

Збоі аўтэнтыфікацыі і збоі тунэля прыходзяць у розныя моманты, і паведамленні розныя. Памылка развязання імені ўзнікае перад любым рукапацісканнем TLS. Адмова TLS узнікае перад адпраўкай уліковых даных. Адмова рэалма ці ўліковага запісу вяртаецца як адказ узроўню HTTP ад партала. Толькі пасля гэтых этапаў пачынаюцца перамовы PPP, і толькі тады з’яўляюцца праблемы маршрутызацыі і DNS.

Правільны рэалм не стварае адсутны маршрут і не робіць працуючым непадтрыманы спосаб уваходу. Калі партал настойвае на браўзерным сцэнары, выкарыстоўвайце падтрыманы кліентам шлях для гэтага сцэнару, а не паўтарайце абмен паролем у спадзеве, што сеанс супадзе.

Трымайце значэнні там, дзе іх знойдзе наступны запуск

Пасля паспяховага злучэння запішыце шлюз, порт, уліковы запіс і рэалм у кіраваны профіль, а не ў alias абалонкі. Профілі, якія захоўваюцца ў рэпазітары ці сістэме кіравання канфігурацыяй, не даюць наступнаму запуску ціха падхапіць рэалм іншага профілю.

Паўторыце адно злучэнне ад пачатку да канца і пацвердзіце як ужытую палітыку, так і доступ да рэсурсу, які вам сапраўды патрэбны. Паспяховая аўтэнтыфікацыя — гэта пачатак такой праверкі, а не яе канец.