Log masuk OpenConnect mendarat di halaman salah? Semak laluan dahulu

Anda menampal alamat daripada e-mel orientasi, klien sampai ke get laluan, dan borang log masuk yang muncul ialah portal umum, bukan portal rakan yang diterangkan oleh pengendali. Tiada apa yang menunjukkan ralat, dan itulah yang mengelirukan: terowong mungkin juga naik, cuma di belakang titik masuk yang salah. Laluan dalam URL itu sedang berfungsi, dan apa sahaja yang menggantikannya menggugurkan kerja itu.

Asingkan dua perkara yang tiba sebagai satu rentetan dalam tiket: alamat yang sampai ke perkhidmatan, dan input yang menentukan dari mana pengesahan bermula. Membaiki yang pertama sambil mengabaikan yang kedua ialah cara nama hos yang betul masih menghasilkan log masuk yang salah.

Apa yang klien hantar sebelum anda melihat borang

Dengan alamat seperti https://vpn.example.net/partners, tindakan pertama klien ialah permintaan HTTPS ke laluan itu, bukan ke hos kosong. Yang kembali biasanya ubah hala ke titik akhir log masuk, atau borang itu sendiri. Klien yang hanya diberi vpn.example.net bermula dari halaman pendaratan lalai yang ada, dan itu mungkin portal lain, senarai kumpulan lain, atau halaman yang menjangka protokol yang sama sekali berbeza. Perbezaannya kelihatan dalam pengepala respons jauh sebelum sebarang kelayakan ditaip.

Sebab itulah tab pelayar yang berfungsi dan profil klien yang gagal boleh menamakan get laluan yang sama namun masih tidak bersetuju. Pelayar mengikut laluan; profil tidak pernah memilikinya.

Dua input yang kelihatan boleh ditukar ganti dan sebenarnya tidak

OpenConnect mendedahkan laluan HTTPS awal sebagai --usergroup, dan halaman manual menganggap URL penuh yang membawa laluan itu sebagai permintaan yang sama yang ditulis dengan cara lain. --authgroup ialah pilihan berasingan: ia memilih entri daripada senarai yang dipaparkan get laluan di dalam borang log masuk. Sesetengah protokol menamakan entri itu kumpulan, yang lain domain atau get laluan, dan di situlah kedua-dua bendera dikelirukan.

Sesuatu perkhidmatan boleh memerlukan kedua-duanya secara sah. Laluan mungkin membawa anda ke portal yang betul sementara borang masih meminta anda memilih antara kumpulan di dalamnya. Memberi nama portal sebagai nama kumpulan, atau sebaliknya, menghasilkan log masuk yang kelihatan diterima dan kemudian gagal membenarkan, kerana nilainya sah dari segi sintaksis dan salah dari segi makna.

Minta setiap nilai daripada pengendali pada barisnya sendiri: laluan masuk, pemilihan borang, dan sama ada kedua-duanya diperlukan. Jangan terbitkan satu daripada yang lain kerana labelnya berbunyi serupa.

Mengapa memangkas laluan mengubah hasilnya

Klien yang hanya menerima hos dan port selalunya masih bersambung, jadi simptomnya jarang menjadi kegagalan keras. Sebaliknya anda mendapat halaman log masuk yang salah, senarai kumpulan kosong, nama sijil yang tidak lagi sepadan dengan yang diterbitkan pengendali, atau terowong yang naik tanpa laluan ke perkhidmatan yang anda mahukan. Setiap satu daripadanya berada pada lapisan berbeza, dan tiada satu pun dibaiki dengan menampal rentetan lebih panjang ke dalam medan yang didokumenkan sebagai nama hos. Dua daripadanya juga tidak dapat dibezakan dari luar, kerana kedua-duanya tiba sebagai borang log masuk yang sekadar tidak berterusan.

Menggantikan nama hos dengan alamat IP ialah kesilapan berasingan yang sering ikut bersama. Pemilihan perkhidmatan berdasarkan nama dan pengesahan sijil kedua-duanya bergantung pada nama, jadi alamat berangka boleh menukar masalah format laluan menjadi ralat TLS.

Alamat pelayar juga membawa lebih daripada laluan. Pengecam sesi, sasaran ubah hala, awalan bahasa dan parameter log masuk sementara semuanya muncul dalam bar alamat, dan tiada satu pun daripada itu tergolong dalam profil klien yang disimpan.

Sahkan titik masuk sebelum menyunting apa-apa lagi

Baca pengepala bagi laluan yang diberikan kepada anda. Permintaan seperti curl -sS -o /dev/null -D - https://vpn.example.net/partners mencetak baris status dan mana-mana pengepala Location tanpa mengikut ubah hala. 302 yang menunjuk ke titik akhir log masuk bernama mengesahkan laluan itu wujud dan menunjukkan ke mana ia pergi; 404 bermaksud alamat pengendali sudah lapuk.

Kemudian hasilkan semula titik masuk yang sama dalam klien yang diluluskan, contohnya openconnect --usergroup=partners vpn.example.net, dan perhatikan borang mana yang muncul. Jika borang itu betul dan terowong masih gagal, laluan itu tidak pernah menjadi masalah dan perhentian seterusnya ialah dasar atau penghalaan.

Catat nama hos, port, protokol, laluan masuk dan pemilihan borang sebagai lima medan berasingan dalam tiket. Senarai itulah yang membolehkan jurutera seterusnya membezakan pelayan yang tidak dapat dicapai daripada penolakan TLS, pemilihan yang ditolak, dan terowong yang naik tanpa laluan yang diperlukan.