Mengapa URL Anda perlu entri pada port 80 atau 443, bukan 45000

Ketik nama host di browser dan skema menentukan port tujuan: 80 untuk http, 443 untuk https. Tidak ada apa pun dalam jawaban DNS yang menimpanya, dan tidak ada aturan penerusan di mesin Anda yang bisa mengarang pendengar di tepi penyedia. Ketika penyedia VPN memberi Anda port publik tinggi seperti 45000, URL eksplisit berfungsi dan yang bersih tidak. Kesenjangannya ada di titik masuk, bukan di dalam aplikasi.

Telusuri jalur dari browser ke proses sekali, dan tiga opsi penerbitan berhenti tampak misterius.

Lihat ke mana permintaan sebenarnya pergi

Browser menyelesaikan nama menjadi alamat, lalu terhubung ke alamat itu pada port default skema kecuali URL menyebutkan port lain. Tepi penyedia Anda menentukan apa yang terjadi pada koneksi yang datang. Jika tabel penerusannya hanya memetakan 45000 ke alamat internal Anda, koneksi ke 80 tidak punya tujuan dan ditolak atau dibuang sebelum mesin Anda terlibat.

Penolakan itu terjadi di tepi, itulah sebabnya log aplikasi Anda tidak menunjukkan apa pun. Tidak adanya log adalah bukti tentang di mana paket berhenti, bukan bukti bahwa aplikasinya rusak.

Mengapa aturan lokal tidak bisa memperbaiki tepi

Pengalihan atau aturan DNAT pada host aplikasi bekerja pada paket yang sudah tiba. Paket yang dikirim ke port 80 di penyedia tidak pernah tiba, jadi aturannya tidak pernah dievaluasi. Ini jam yang paling sering terbuang dalam seluruh masalah ini.

DNS juga tidak bisa membawa port. spesifikasi HTTP mendefinisikan default skema, dan catatan A atau AAAA mengembalikan alamat sementara CNAME mengembalikan nama lain. Browser tetap menyambungkan port skema, jadi hanya port eksplisit di URL yang mengubah tujuan.

Opsi satu: pertahankan port eksplisit

Sering kali jawaban yang benar adalah yang tidak menarik. Terbitkan URL lengkap dengan port, akhiri TLS pada entri yang mendukungnya, dan pastikan setiap tautan yang dihasilkan mempertahankan asal yang sama. Untuk audiens kecil yang terkendali ini sudah lengkap, dan tidak ada biaya selain nomor port yang terlihat.

Periksa pengalihan dan cakupan cookie selagi Anda di sana, karena backend yang menulis nama hostnya sendiri ke header Location membatalkan pengaturan itu.

Opsi dua: dapatkan entri port default yang sebenarnya

Beberapa penyedia dan pengaturan hosting meneruskan 80 dan 443 pada alamat bersama atau khusus sebagai layanan yang didokumentasikan. Tanyakan apa yang sebenarnya termasuk alih-alih menganggap bahwa alamat keluar publik menyiratkan port masuk yang sembarang. Alamat keluar khusus tidak mengatakan apa pun tentang penerusan masuk.

Konfirmasikan kepemilikan dan ketersediaan secara tertulis, termasuk apa yang terjadi pada entri ketika terowongan tersambung ulang dengan alamat berbeda. Entri yang bergerak bersama terowongan menghasilkan pemadaman yang tampak seperti kegagalan DNS.

Opsi tiga: taruh frontend di depan

Proxy terbalik pada alamat yang dapat dijangkau dapat mendengarkan di 443 dan mengakhiri TLS dan membuka koneksi terpisah ke backend melalui VPN. Pengunjung melihat nama dan port default frontend, sementara frontend berbicara dengan port tinggi backend atas nama Anda. Ini berhasil karena mengubah arsitektur alih-alih melawan titik masuk. Backend kemudian tidak memerlukan port masuk apa pun di internet publik.

Ini juga mengubah apa yang Anda operasikan. Frontend memiliki TLS publik, kebijakan akses, log, dan ketersediaan, dan harus membatasi pemilihan backend pada layanan yang dimaksud. Jika lompatan dari frontend ke backend memakai HTTPS, pertahankan validasi sertifikat pada lompatan itu.

Pertahankan satu asal

Nama host publik, skema, dan port frontend membentuk asal yang digunakan pengunjung, jadi konfigurasikan URL eksternal aplikasi, pengalihan, dan cookie untuk asal itu. Kirim host asli dan skema yang diteruskan jika aplikasi membangun tautan absolut. Respons yang memantulkan pengguna ke nama privat atau port tinggi membatalkan entri bersih yang baru saja Anda bangun.

Lalu putuskan dengan mempertimbangkan audiens. URL pendek dapat membenarkan frontend terkelola, dan tidak sepadan untuk tanpa sengaja mengubah layanan privat khusus VPN menjadi publik.