Mencapai laman HTTPS yang hanya tersedia melalui VPN dengan penghantaran SSH

Satu mesin sudah mempunyai akses VPN yang diluluskan, mesin kedua memerlukan tepat satu perkhidmatan HTTPS peribadi, dan penghantaran SSH setempat boleh merapatkan jurang itu tanpa memberikan mesin kedua terowong. Penghantaran membawa satu destinasi TCP dan bukan seluruh rangkaian, dan had itulah yang menjadi intinya. Lakukan lima langkah di bawah mengikut urutan, kerana setiap satu gagal atas sebab yang berbeza dan langkah kemudian tidak dapat menyelamatkan jurang sebelumnya. Jika mana-mana prasyarat tiada, reka bentuk ini tidak menyelesaikannya dan tiada penalaan arahan akan membantu.

Langkah satu: sahkan tiga prasyarat

Tiga perkara mesti sudah benar sebelum mana-mana arahan bermakna. Anda memerlukan kebenaran menggunakan mesin pertama sebagai hos penghantaran, akses SSH yang berfungsi kepadanya, dan dasar pelayan yang membenarkan destinasi yang dimaksudkan. Akaun SSH yang dibuat untuk pemindahan fail mungkin mempunyai penghantaran dilumpuhkan, dan pelayan yang membenarkan penghantaran masih boleh mengehadkan destinasi mana yang boleh dicapai melaluinya. Tanya sebelum menguji, kerana menggunakan stesen kerja rakan sekerja sebagai titik lompat tanpa persetujuan ialah masalah dasar, walaupun arahan berjalan dengan sempurna.

Dua arahan menyelesaikan separuh teknikal senarai itu. Yang pertama membuktikan akaun dan kunci berfungsi tanpa gesaan interaktif, dan yang kedua mencetak dasar pelayan sebenar dan bukannya contoh yang dikomentari dalam fail konfigurasi.

ssh -o BatchMode=yes [email protected] 'echo ok'
sudo sshd -T | grep -E 'allowtcpforwarding|permitopen'

Langkah dua: ikat port loopback dan kekalkan sesi hidup

Pada mesin yang menjalankan aplikasi klien, buka penghantaran setempat ke perkhidmatan peribadi. Ikatnya secara eksplisit pada loopback supaya ia tidak diterbitkan pada rangkaian setempat, dan pilih port tinggi yang belum dipegang oleh mana-mana perkhidmatan setempat. Kekalkan sesi berjalan semasa anda bekerja, kerana menutupnya menutup pendengar. ExitOnForwardFailure menukar pengikatan yang ditolak atau port yang diduduki menjadi keluar segera dan bukannya sesi yang kekal tanpa penghantaran, dan itulah mod kegagalan yang paling banyak membuang masa.

Sambungan peribadi dibuat dari hos lompat, jadi DNS, laluan, dasar VPN dan akses perkhidmatan hos itu semuanya mesti berfungsi. Sesi SSH tidak mencipta ketercapaian yang hos lompat tidak ada, dan ia tidak boleh membaiki laluan yang VPN tidak pernah tolak. Sahkan pendengar di tempat ia benar-benar berada dan bukannya mempercayai kesenyapan arahan.

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:9443:portal.lab.example:443 [email protected]
ss -ltn '( sport = :9443 )'

Langkah tiga: kekalkan nama HTTPS apabila soket adalah setempat

Melayari https://127.0.0.1:9443/ menukar nama pelayan TLS dan kuasa aplikasi. Sijil yang dikeluarkan untuk portal.lab.example tidak akan disahkan terhadap alamat loopback, dan ralat yang terhasil kelihatan seperti sijil rosak dan bukannya jalan pintas penghantaran. Untuk ujian baris arahan, kekalkan URL sebenar dan ubah destinasi soket sahaja. Itulah yang dilakukan --connect-to, dan manual curl mendokumentasikan bentuk empat medan yang digunakan di bawah.

curl --noproxy portal.lab.example --connect-to portal.lab.example:443:127.0.0.1:9443 https://portal.lab.example/

Nama kekal dalam URL, dalam jabat tangan TLS dan dalam pengepala Host, manakala sambungan TCP pergi ke pendengar setempat. Pilihan tanpa proksi mengekalkan ujian pada penghantaran ini dan bukannya membiarkan proksi HTTP yang dikonfigurasikan memintasnya, dan membiarkan pengesahan sijil dihidupkan itulah yang menjadikan hasilnya bermakna.

Langkah empat: ketahui apa yang tidak dapat diliputi oleh satu penghantaran

Satu penghantaran TCP meliputi satu port destinasi. Halaman yang mengubah hala ke nama hos kedua, memuatkan aset daripada hos dalam rangkaian peribadi atau menghantar ke port lain memerlukan penghantarannya sendiri, dan setiap satu daripadanya memerlukan pemeriksaan dasar yang sama seperti yang pertama. Aliran kerja pelayar menambah keperluan tersendiri, kerana pelayar mesti diberitahu untuk menghantar nama sebenar ke port setempat melalui konfigurasi proksi atau pemetaan setempat. Oleh itu ujian baris arahan yang berjaya tidak membuktikan pelayar akan berjaya, walaupun ia membuktikan laluan itu.

UDP, penemuan SMB dan log masuk domain tidak melalui penghantaran TCP sama sekali. Jika keperluan sebenar ialah akses rangkaian umum, reka bentuk ini ialah alat yang salah dan gerbang akses jauh yang disokong ialah yang betul.

Langkah lima: bersihkan dan catatkan

Hentikan sesi apabila ujian selesai dan sahkan pendengar telah hilang. Jika port yang dipilih sudah diduduki, pilih port loopback lain yang belum digunakan dan kemas kini URL, arahan ujian dan nota bersama-sama, dan bukannya menghentikan perkhidmatan setempat yang tidak berkaitan untuk melepaskan nombor itu. Membiarkan penghantaran terbuka pada komputer riba menjadikan diagnosis sebagai perkhidmatan yang tidak diurus.

Catatkan hos lompat, destinasi yang dihantar, port setempat dan siapa yang meluluskan susunan itu. Penghantaran yang hanya wujud dalam sejarah shell seseorang berada satu but semula daripada penyiasatan berulang, dan orang seterusnya tidak akan tahu prasyarat mana antara tiga itu yang sudah diperiksa.