Login OpenConnect mendarat di halaman yang salah? Periksa dulu jalurnya

Anda menempelkan alamat dari email orientasi, klien mencapai gateway, dan formulir login yang muncul adalah portal umum, bukan portal mitra yang dijelaskan operator. Tidak ada yang menampilkan galat, dan justru itu yang membingungkan: terowongan bahkan bisa naik, hanya di balik titik masuk yang salah. Jalur di URL itu sedang bekerja, dan apa pun yang menggantikannya menjatuhkan pekerjaan itu.

Pisahkan dua hal yang datang sebagai satu untai dalam tiket: alamat yang mencapai layanan, dan masukan yang menentukan dari mana autentikasi dimulai. Memperbaiki yang pertama sambil mengabaikan yang kedua adalah cara nama host yang benar tetap menghasilkan login yang salah.

Apa yang dikirim klien sebelum Anda melihat formulir

Dengan alamat seperti https://vpn.example.net/partners, tindakan pertama klien adalah permintaan HTTPS ke jalur itu, bukan ke host kosong. Yang kembali biasanya pengalihan ke titik akhir login, atau formulirnya sendiri. Klien yang hanya diberi vpn.example.net mulai dari halaman pendaratan bawaan apa pun, yang bisa berupa portal lain, daftar grup lain, atau halaman yang mengharapkan protokol yang sama sekali berbeda. Perbedaannya terlihat di header respons jauh sebelum kredensial apa pun diketik.

Itulah sebabnya tab peramban yang berfungsi dan profil klien yang gagal bisa menyebut gateway yang sama namun tetap tidak sepakat. Peramban mengikuti jalur; profil tidak pernah memilikinya.

Dua masukan yang tampak bisa dipertukarkan dan ternyata tidak

OpenConnect memaparkan jalur HTTPS awal sebagai --usergroup, dan halaman manual memperlakukan URL lengkap yang membawa jalur itu sebagai permintaan yang sama yang ditulis dengan cara lain. --authgroup adalah opsi terpisah: ia memilih entri dari daftar yang ditampilkan gateway di dalam formulir login. Sebagian protokol menyebut entri itu grup, sebagian domain atau gateway, dan di situlah kedua tanda itu tertukar.

Sebuah layanan bisa sah-sah saja membutuhkan keduanya. Jalur bisa membawa Anda ke portal yang benar sementara formulir masih meminta Anda memilih di antara grup di dalamnya. Memberikan nama portal sebagai nama grup, atau sebaliknya, menghasilkan login yang tampak diterima lalu gagal mengotorisasi, karena nilainya valid secara sintaksis dan salah secara semantik.

Mintalah setiap nilai dari operator pada barisnya sendiri: jalur masuk, pilihan formulir, dan apakah keduanya diperlukan. Jangan menurunkan yang satu dari yang lain karena labelnya terdengar mirip.

Mengapa memangkas jalur mengubah hasilnya

Klien yang hanya menerima host dan port sering tetap terhubung, jadi gejalanya jarang berupa kegagalan keras. Sebagai gantinya Anda mendapat halaman login yang salah, daftar grup kosong, nama sertifikat yang tidak lagi cocok dengan yang diterbitkan operator, atau terowongan yang naik tanpa rute ke layanan yang Anda inginkan. Masing-masing berada di lapisan berbeda, dan tidak satu pun diperbaiki dengan menempelkan untai yang lebih panjang ke kolom yang didokumentasikan sebagai nama host. Dua di antaranya juga tidak bisa dibedakan dari luar, karena keduanya datang sebagai formulir login yang sekadar tidak berlanjut.

Mengganti nama host dengan alamat IP adalah kesalahan terpisah yang sering ikut serta. Pemilihan layanan berbasis nama dan validasi sertifikat keduanya bergantung pada nama, sehingga alamat numerik bisa mengubah masalah format jalur menjadi galat TLS.

Alamat peramban juga membawa lebih dari sekadar jalur. Pengenal sesi, target pengalihan, awalan bahasa, dan parameter login sementara semuanya muncul di bilah alamat, dan tidak satu pun pantas berada di profil klien yang tersimpan.

Pastikan titik masuk sebelum menyunting hal lain

Baca header untuk jalur yang diberikan kepada Anda. Permintaan seperti curl -sS -o /dev/null -D - https://vpn.example.net/partners mencetak baris status dan setiap header Location tanpa mengikuti pengalihan. 302 yang menunjuk ke titik akhir login bernama memastikan jalur itu ada dan menunjukkan ke mana ia menuju; 404 berarti alamat operator sudah usang.

Lalu reproduksi titik masuk yang sama di klien yang disetujui, misalnya openconnect --usergroup=partners vpn.example.net, dan amati formulir mana yang muncul. Jika formulirnya benar dan terowongan tetap gagal, jalur tidak pernah menjadi masalahnya dan perhentian berikutnya adalah kebijakan atau perutean.

Catat nama host, port, protokol, jalur masuk, dan pilihan formulir sebagai lima kolom terpisah di tiket. Daftar itulah yang memungkinkan insinyur berikutnya membedakan server yang tak terjangkau dari penolakan TLS, pilihan yang ditolak, dan terowongan yang naik tanpa rute yang dibutuhkannya.