Port yang Diblokir

Port mana yang diblokir?

Port jaringan adalah nomor yang digunakan untuk membedakan layanan pada suatu alamat jaringan. Server yang sama dapat menerima koneksi web pada satu port dan koneksi ke aplikasi lain pada port berbeda. Aplikasi memerlukan alamat server, port yang sesuai, dan transport yang digunakan: TCP atau UDP.

Koneksi proksi memiliki dua tujuan terpisah. Pertama, aplikasi Anda terhubung ke proksi pada alamat dan port yang diberikan penyedia. Kemudian aplikasi meminta proksi menjangkau server tujuan pada alamat dan port server itu. Port dalam pengaturan proksi Anda termasuk langkah pertama; pembatasan port tujuan berlaku pada langkah kedua.

Misalnya, program dapat terhubung ke proxy.example:1080 dan meminta portal.example:443. Titik masuk proksi yang sama juga dapat menerima permintaan untuk mail.example:587. Jika penyedia mengizinkan port tujuan pertama dan memblokir yang kedua, koneksi web dapat berhasil sementara koneksi email ditolak.

Pembatasan ini menyangkut koneksi keluar dari proksi ke layanan eksternal. Mengizinkan koneksi semacam itu tidak memberi aplikasi di komputer Anda port masuk yang dapat dijangkau pengguna internet lain. Penerusan port masuk adalah kemampuan terpisah.

Mengapa penyedia membatasi port

Alasan paling jelas adalah mencegah penyalahgunaan layanan tertentu. Akses langsung ke server email dapat digunakan untuk kampanye spam. Keluhan dan daftar blokir pengirim memengaruhi alamat IP yang membawa trafik, sehingga akibatnya dapat meluas melampaui pelanggan yang mengirim pesan. Penyedia dapat mengurangi risiko itu dengan menolak koneksi ke port pengiriman email sebelum pesan apa pun dikirim.

Pertimbangan serupa dapat berlaku untuk administrasi jarak jauh, berbagi berkas, atau layanan basis data. Penyedia mungkin membatasi akses ke port yang terkait dengan layanan tersebut untuk mengurangi percobaan login tanpa izin dan serangan lain. Pembatasan berlaku pada koneksinya sendiri: administrator yang sah juga mungkin tidak dapat menjangkau server miliknya melalui produk tersebut.

Aturan tidak selalu berasal dari penjual proksi. Perusahaan hosting atau operator jaringan dapat memfilter koneksi keluar dari infrastruktur yang digunakan proksi. Izin dalam perangkat lunak proksi sendiri tidak dapat mengesampingkan pembatasan yang diberlakukan lebih jauh di sepanjang rute.

Filter port adalah langkah yang luas. Filter dapat menghentikan trafik tidak diinginkan tanpa memeriksa setiap pesan atau menentukan keabsahan setiap operasi, tetapi juga membatasi aplikasi berguna yang memerlukan port sama. Konsekuensi ini menjelaskan mengapa penyedia dapat tetap menutup port meskipun pelanggan membayar dan memiliki tugas yang wajar.

Cara kerja aturan akses port

Ada dua pendekatan dasar. Daftar blokir menyebut port yang tidak boleh digunakan pelanggan; koneksi lain dipertimbangkan berdasarkan aturan layanan lainnya. Daftar yang diizinkan bekerja sebaliknya: penyedia mengizinkan sekumpulan port tertentu dan menolak sisanya. Pada model kedua, aplikasi web biasa pada port nonstandar dapat tidak tersedia hanya karena portnya berada di luar kumpulan yang diizinkan.

Aturan dapat mencakup suatu port pada setiap alamat eksternal atau menggabungkan port dengan tujuan tertentu. Penyedia juga dapat menerapkan aturan berbeda pada produk atau penggunaan yang disetujui berbeda. Karena itu, akses melalui satu jaringan tidak membuktikan izin produk lain yang dijual perusahaan sama.

Proksi tidak perlu mendekripsi trafik aplikasi untuk menerapkan aturan port tujuan. Dalam permintaan HTTP CONNECT, klien memberikan host dan port tujuan. SOCKS5 juga membawa tujuan yang diminta dalam permintaan koneksinya. Proksi dapat menolak permintaan itu sebelum sesi terlindungi dengan server tujuan dimulai.

Trafik TCP dan UDP yang menggunakan nomor port sama dapat diizinkan atau diblokir secara terpisah. Koneksi berhasil ke port TCP 443 tidak membuktikan ketersediaan port UDP 443. Ada pula kemungkinan lain: produk proksi yang dipilih sama sekali tidak membawa UDP. Dalam kasus itu, pembatasan menyangkut transport, bukan satu port UDP tertentu.

Nomor port saja juga tidak membuktikan aktivitas aplikasi. Layanan dapat berjalan pada port nonstandar, dan nomor yang diizinkan tidak membuat setiap penggunaannya dapat diterima. Penyedia dapat menggabungkan filter port dengan pembatasan tujuan dan aturan atas aktivitas itu sendiri.

Dampaknya bagi aplikasi

Aplikasi menggunakan koneksi untuk fungsi tertentu. Pengujian browser memeriksa koneksi web yang dibuatnya; pengujian itu tidak mencoba setiap koneksi yang mungkin dibutuhkan program lain. Contoh berikut menunjukkan cara pembatasan port memengaruhi layanan yang sebenarnya bekerja.

Email memperjelas pembedaan ini. Aplikasi email mengirim pesan keluar ke server email, biasanya pada port 587 atau 465. Port 465 dimulai dengan enkripsi TLS; port 587 umumnya menggunakan STARTTLS untuk membentuk enkripsi. Pembatasan port dapat mencegah kedua koneksi itu sebelum pesan dikirim. Enkripsi melindungi pertukaran, tetapi tidak menghapus aturan akses penyedia.

Dalam antarmuka webmail, browser berkomunikasi dengan situs melalui HTTPS dan layanan email menangani pengiriman. Browser tidak meminta proksi membentuk koneksi SMTP yang sama. Karena itu, kotak surat web dapat tetap digunakan sementara akses SMTP diblokir. Penerimaan email dalam aplikasi terpisah merupakan koneksi lain lagi: akses IMAP atau POP harus dipertimbangkan terpisah dari pengiriman.

FTP menunjukkan mengapa menguji login saja dapat melewatkan masalah. Dalam mode pasif, klien terlebih dahulu mengirim perintah melalui satu koneksi, kemudian terhubung ke port yang ditentukan server untuk mentransfer data. Jika koneksi kedua dibatasi, autentikasi mungkin bekerja sementara daftar berkas atau unduhan gagal. Aplikasi dengan koneksi terpisah untuk login, suara, atau pertukaran berkas dapat mengalami kegagalan sebagian yang serupa.

Mengapa mengubah pengaturan proksi mungkin tidak membantu

Mengubah port masuk dalam pengaturan proksi mengubah tempat aplikasi menghubungi proksi. Hal itu tidak mengubah port tujuan yang diminta untuk layanan eksternal. Jika penyedia menawarkan titik masuk pada port 443, terhubung ke sana tetap membuat permintaan untuk port 587 server email terkena pembatasan port email.

Beralih dari proksi HTTP ke SOCKS5 dapat mengatasi masalah kompatibilitas ketika aplikasi memerlukan kemampuan yang didukung metode koneksi baru. Peralihan itu sendiri tidak membatalkan aturan penyedia. SOCKS5 mendefinisikan cara meminta koneksi TCP dan penerusan UDP; layanan memutuskan permintaan mana yang diterima.

Mengganti IP keluar juga tidak mengubah pembatasan yang berlaku untuk seluruh produk. Rute berbeda mungkin berperilaku berbeda ketika jaringan eksternal tertentu menyebabkan kegagalan, tetapi rotasi bukan cara menghapus aturan yang berlaku pada seluruh produk. Lebih banyak IP atau kuota trafik yang lebih besar juga tidak mengubah izin tersebut.

Cara mengenali pembatasan port

Bukti paling berguna adalah respons penyedia yang secara eksplisit menyatakan bahwa port tujuan yang diminta tidak diizinkan. Pesan akses ditolak yang umum kurang tepat. Misalnya, balasan SOCKS5 untuk permintaan yang ditolak oleh kumpulan aturan menunjukkan penolakan kebijakan, tetapi tidak menunjukkan aturan penyebabnya. Timeout atau reset saja merupakan bukti yang lebih lemah lagi.

Server tujuan mungkin tidak memiliki layanan yang mendengarkan pada port tersebut, mungkin hanya menerima alamat sumber tertentu, atau mungkin tidak tersedia sementara. Aplikasi juga mungkin menggunakan protokol yang salah atau mengirim sebagian trafik di luar proksi yang dikonfigurasi. Memeriksa satu permintaan web yang berhasil tidak dapat membedakan penyebab tersebut dari pembatasan yang memengaruhi koneksi lain.

Untuk permintaan dukungan yang berguna, berikan produk proksi, nama host atau IP tujuan, portnya, TCP atau UDP, aplikasi, dan kesalahan tepat beserta waktu percobaan. Detail ini memungkinkan dukungan memeriksa koneksi yang relevan alih-alih hanya memastikan proksi online. Untuk rencana pembelian, informasi yang sama membantu memastikan apakah produk mendukung tugas tersebut.

Jika penyedia mengizinkan pengecualian, persetujuannya harus menyebut tujuan dan penggunaan yang diperlukan. Sebagian pembatasan tetap permanen atau berasal dari infrastruktur yang tidak dikendalikan penyedia. Pertanyaan yang berguna adalah apakah koneksi tertentu dapat didukung berdasarkan aturan layanan; permintaan untuk “membuka semua port” membuat persyaratan maupun batasnya tidak jelas.