OpenVPN dan HTTPS di port 443: siapa pemilik listener?

Dua layanan dapat sama-sama menjawab di port 443 tanpa pernah bersaing, karena listener ditentukan oleh transport, alamat, dan port secara bersama, bukan oleh nomornya saja. Pasang server web dan OpenVPN pada satu mesin, dan satu-satunya pertanyaan yang layak dijawab lebih dulu adalah soket mana yang diminta setiap proses kepada kernel. Tuliskan daftar itu sebelum menyunting konfigurasi, dan sebagian besar galat «alamat sudah dipakai» menjelaskan dirinya sendiri. Segala hal setelah daftar adalah pilihan antara listener UDP, soket TCP bersama, atau frontend yang merutekan menurut protokol.

Mulailah dari soket yang diminta setiap proses

Bind berhasil atau gagal pada rangkap tiga itu, jadi dua daemon hanya bertabrakan bila ketiga bagiannya bertepatan. Karena itulah situs web di TCP 443 hidup berdampingan tanpa batas dengan listener OpenVPN di UDP 443, dan karena itulah memindahkan salah satunya ke alamat lokal kedua pada host yang sama juga mengakhiri perdebatan. Baca listener yang hidup alih-alih berkas yang seharusnya membuatnya, karena include usang atau berkas unit yang terlupakan bertahan lebih lama daripada suntingan yang Anda ingat lakukan.

Jalankan ss -lntup sebagai root dan baca setiap baris yang menyebut 443, termasuk entri IPv6. Listener v6 wildcard biasanya juga menerima lalu lintas v4, dan begitulah listener yang Anda lupakan tetap menempati port setelah Anda mengubah berkas yang Anda anggap bertanggung jawab. Jika nama proses mengejutkan Anda, persempit keluaran dengan ss -lntup 'sport = :443' sebelum menyentuh apa pun.

Pindahkan terowongan ke UDP bila jaringan mengizinkannya

Listener UDP menghindari tabrakan sepenuhnya dan biasanya merupakan perbaikan terpendek, karena tidak ada soket yang dibagi dan tidak ada produk tambahan yang masuk ke jalur. Namun itu tidak gratis. Sebagian jaringan klien membuang UDP 443 tanpa mengirim reset, sehingga terowongan berhenti terbentuk alih-alih gagal pada bind, dan pengguna melaporkan VPN mati tanpa galat untuk dibaca. Listener UDP juga bertahan terhadap mulai ulang lapisan web, yang penting pada mesin yang situsnya sering diterapkan ulang. Ujilah dari jaringan tempat pengguna berada, karena shell di server hanya membuktikan bahwa server dapat menjangkau dirinya sendiri.

Ubah transport pada konfigurasi server dan pada profil klien sekaligus. Profil yang masih meminta TCP akan berputar dalam siklus sambung ulang terhadap listener yang hanya UDP, dan itu tampak seperti gangguan jaringan sampai Anda membandingkan kedua berkas.

Biarkan proses VPN memiliki TCP 443 dan teruskan sisanya

Community OpenVPN dalam mode server TCP membaca bita pertama koneksi masuk dan meneruskan apa pun yang bukan protokolnya sendiri ke backend HTTPS, itulah gunanya direktif port-share. Backend adalah server web biasa dengan TLS aktif, dinamai berdasarkan host dan port dalam direktif itu, bukan berdasarkan URL.

port-share 10.0.0.5 8080

Pada mesin tempat situs memiliki alamat privat kedua, baris itu mengirim lalu lintas non-VPN ke 10.0.0.5:8080, jadi host virtual HTTPS harus diikat di sana dan firewall harus mengizinkan lompatan lokal. Server web harus mengakhiri TLS sendiri, karena bita yang datang adalah jabat tangan asli peramban dan tidak ada yang mendekripsinya di antaranya. Arahkan direktif ke listener HTTP biasa dan peramban mendapat galat metode tidak valid, yang terbaca sebagai situs rusak alih-alih backend yang salah tempat. Direktif itu hanya ada dalam mode server TCP, dan listener UDP tidak memiliki aliran untuk diperiksa.

Karena proses VPN menerima setiap koneksi, aplikasi web melihat permintaan yang diteruskan datang dari salah satu alamat host itu sendiri alih-alih dari pengunjung. Apa pun yang memerlukan alamat klien sebenarnya bergantung pada dukungan protokol PROXY di backend atau pada frontend yang menambahkannya. Memindahkan backend ke alamat lokal lain tidak mengembalikan alamat pengunjung; itu hanya mengubah alamat host mana yang dicatat situs. Tuliskan batasan itu di catatan penerapan sebelum laporan analitik memunculkan pertanyaan.

Proxy terbalik adalah alat yang salah; router lapisan empat bukan

Proxy terbalik HTTP mengakhiri TLS agar dapat membaca permintaan, yang berarti tidak dapat melewatkan aliran OpenVPN tanpa disentuh. Router lapisan empat yang meneruskan menurut SNI atau menurut pemeriksaan paket pertama dapat berdiri di depan keduanya, asalkan tidak mengakhiri sesi yang menjadi tumpuan VPN. Kedua perangkat tampak serupa pada diagram dan berperilaku sangat berbeda pada soket.

Access Server komersial membawa pengaturan berbagi port sendiri, dan pengaturan itu tidak memetakan satu-ke-satu ke direktif komunitas. Identifikasi produk dan versinya sebelum menyesuaikan panduan yang ditulis untuk yang lain. Pengaturan hasil salin yang diabaikan diam-diam lebih buruk daripada tanpa pengaturan, karena daftar listener sesudahnya masih tampak masuk akal.

Uji situs web dan terowongan sebagai dua jalur terpisah

Muat situs dan hubungkan terowongan, lalu baca lagi daftar listener untuk melihat proses mana yang kini memiliki 443. Halaman yang termuat tidak membuktikan apa pun tentang VPN, dan terowongan yang tersambung tidak membuktikan apa pun tentang situs, meskipun keduanya memakai nomor yang sama. Tiga perintah di bawah memeriksa soket bersama, jalur web, dan layanan 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 di log akses backend dengan yang di log VPN untuk saat yang sama. Jika situs mencatat setiap pengunjung sebagai host itu sendiri, penerusan berfungsi dan penanganan alamat tidak. Jika kedua log diam, frontend tidak pernah menyerahkan koneksi. Bagaimanapun, daftar listener menentukan siapa yang menerima soket, dan itulah fakta yang harus dikonfirmasi sebelum Anda mengubah berkas lain.

Tinggalkan peta listener itu di samping konfigurasi agar orang berikutnya yang menyentuh 443 tahu proses mana yang menerima dan ke mana protokol lain pergi. Konfirmasikan kepemilikan setelah perubahan alih-alih memercayai apa yang dimaksudkan suntingan.