OpenVPN dan HTTPS pada port 443: siapa pemilik pendengar?
TCP dan UDP 443 ialah soket berasingan. Berkongsi satu pendengar TCP memerlukan pemilik, dan perkongsian port OpenVPN ialah aturan sempit, bukan tipu helah proksi.
Dua perkhidmatan boleh kedua-duanya menjawab pada port 443 tanpa pernah bersaing, kerana pendengar ditentukan oleh pengangkutan, alamat dan port secara bersama, bukan oleh nombor semata-mata. Letakkan pelayan web dan OpenVPN pada satu mesin, dan satu-satunya soalan yang wajar dijawab dahulu ialah soket mana yang diminta setiap proses daripada kernel. Tulis senarai itu sebelum menyunting konfigurasi, dan kebanyakan ralat «alamat sudah digunakan» menjelaskan dirinya sendiri. Segala-galanya selepas senarai ialah pilihan antara pendengar UDP, soket TCP dikongsi atau bahagian hadapan yang menghala mengikut protokol.
Mulakan dengan soket yang diminta setiap proses
Bind berjaya atau gagal pada rangkap tiga itu, jadi dua daemon hanya berlanggar apabila ketiga-tiga bahagian bertepatan. Itulah sebabnya laman web pada TCP 443 wujud bersama pendengar OpenVPN pada UDP 443 tanpa had, dan itulah sebabnya memindahkan salah satu daripadanya ke alamat setempat kedua pada hos yang sama juga menamatkan perdebatan. Baca pendengar yang hidup dan bukan fail yang sepatutnya menciptanya, kerana include lapuk atau fail unit yang dilupakan hidup lebih lama daripada suntingan yang anda ingat lakukan.
| Line in the listener list | What it establishes | What to do next |
|---|---|---|
| One udp row and one tcp row, each on 443 | Separate transport sockets, nothing contested | Point the VPN profile at udp and stop editing |
| A single tcp address and port listed by two processes | A real bind collision between two daemons | Move one service, or put a dispatcher in front of both |
| A proxy process owns the socket, no vpn process | The proxy accepts and has to hand off correctly | Check that its backend speaks the protocol it forwards |
Jalankan ss -lntup sebagai root dan baca setiap baris yang menyebut 443, termasuk entri IPv6. Pendengar v6 kad liar biasanya juga menerima trafik v4, dan begitulah pendengar yang anda lupakan terus menduduki port selepas anda menukar fail yang anda sangka bertanggungjawab. Jika nama proses mengejutkan anda, sempitkan output dengan ss -lntup 'sport = :443' sebelum menyentuh apa-apa.
Tukar terowong ke UDP apabila rangkaian membenarkannya
Pendengar UDP mengelak perlanggaran sepenuhnya dan biasanya pembaikan terpendek, kerana tiada soket dikongsi dan tiada produk tambahan memasuki laluan. Tetapi ia tidak percuma. Sesetengah rangkaian klien menggugurkan UDP 443 tanpa menghantar reset, jadi terowong berhenti terbentuk dan bukannya gagal pada bind, dan pengguna melaporkan VPN mati tanpa ralat untuk dibaca. Pendengar UDP juga bertahan daripada permulaan semula lapisan web, yang penting pada mesin yang lamannya sering dilancarkan semula. Uji dari rangkaian tempat pengguna berada, kerana shell pada pelayan hanya membuktikan pelayan dapat mencapai dirinya sendiri.
Tukar pengangkutan dalam konfigurasi pelayan dan dalam profil klien serentak. Profil yang masih meminta TCP akan berputar dalam kitaran sambung semula terhadap pendengar UDP sahaja, dan itu kelihatan seperti kerosakan rangkaian sehingga anda membandingkan kedua-dua fail.
Biarkan proses VPN memiliki TCP 443 dan teruskan yang lain
Community OpenVPN dalam mod pelayan TCP membaca bait pertama sambungan masuk dan meneruskan apa-apa yang bukan protokolnya sendiri ke backend HTTPS, itulah kegunaan direktif port-share. Backend ialah pelayan web biasa dengan TLS diaktifkan, dinamakan mengikut hos dan port dalam direktif itu dan bukan mengikut URL.
port-share 10.0.0.5 8080
Pada mesin tempat laman memegang alamat peribadi kedua, baris itu menghantar trafik bukan VPN ke 10.0.0.5:8080, jadi hos maya HTTPS mesti diikat di sana dan tembok api mesti membenarkan lompatan setempat. Pelayan web mesti menamatkan TLS sendiri, kerana bait yang tiba ialah jabat tangan asal pelayar dan tiada apa di antaranya menyahsulitnya. Halakan direktif ke pendengar HTTP biasa dan pelayar mendapat ralat kaedah tidak sah, yang terbaca sebagai laman rosak dan bukan sebagai backend yang salah tempat. Direktif itu hanya wujud dalam mod pelayan TCP, dan pendengar UDP tiada aliran untuk diperiksa.
Kerana proses VPN menerima setiap sambungan, aplikasi web melihat permintaan yang diteruskan tiba dari salah satu alamat hos itu sendiri dan bukan daripada pelawat. Apa-apa yang memerlukan alamat klien sebenar bergantung pada sokongan protokol PROXY dalam backend atau pada bahagian hadapan yang menambahnya. Memindahkan backend ke alamat setempat lain tidak mengembalikan alamat pelawat; ia hanya menukar alamat hos mana yang direkodkan laman. Tulis had itu dalam nota penggunaan sebelum laporan analitik menimbulkan soalan.
Proksi songsang ialah alat yang salah; penghala lapisan empat bukan
Proksi songsang HTTP menamatkan TLS supaya dapat membaca permintaan, yang bermakna ia tidak boleh melepaskan aliran OpenVPN tanpa disentuh. Penghala lapisan empat yang meneruskan mengikut SNI atau pemeriksaan paket pertama boleh berdiri di hadapan kedua-duanya, asalkan ia tidak menamatkan sesi yang bergantung pada VPN. Kedua-dua peranti kelihatan serupa pada gambar rajah dan berkelakuan sama sekali berbeza pada soket.
Access Server komersial membawa tetapan perkongsian port sendiri, dan tetapan itu tidak memetakan satu-ke-satu kepada direktif komuniti. Kenal pasti produk dan versi sebelum menyesuaikan panduan yang ditulis untuk yang lain. Tetapan disalin yang diabaikan secara senyap lebih buruk daripada tiada tetapan, kerana senarai pendengar selepas itu masih kelihatan munasabah.
Uji laman web dan terowong sebagai dua laluan berasingan
Muatkan laman dan sambungkan terowong, kemudian baca senarai pendengar sekali lagi untuk melihat proses mana yang memiliki 443 sekarang. Halaman yang dimuatkan tidak membuktikan apa-apa tentang VPN, dan terowong yang bersambung tidak membuktikan apa-apa tentang laman, walaupun kedua-duanya menggunakan nombor yang sama. Tiga arahan di bawah memeriksa soket dikongsi, laluan web dan perkhidmatan VPN dalam urutan itu.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
Bandingkan alamat klien dalam log akses backend dengan yang dalam log VPN untuk saat yang sama. Jika laman merekodkan setiap pelawat sebagai hos itu sendiri, penghantaran berfungsi dan pengendalian alamat tidak. Jika kedua-dua log senyap, bahagian hadapan tidak pernah menyerahkan sambungan itu. Walau apa pun, senarai pendengar menentukan siapa menerima soket, dan itulah fakta yang perlu disahkan sebelum anda menukar fail lain.
Biarkan peta pendengar itu di sebelah konfigurasi supaya orang seterusnya yang menyentuh 443 tahu proses mana yang menerima dan ke mana protokol lain pergi. Sahkan pemilikan selepas perubahan dan bukan mempercayai apa yang suntingan itu bertujuan lakukan.