OpenVPN di balik stunnel: teruskan pembungkusnya, bukan port 1194

Letakkan pembungkus TLS di depan OpenVPN dan penerapan mendapatkan pendengar kedua, yang hanya satu di antaranya boleh menghadap internet. Saat terowongan bekerja dari mesin yang sama dan gagal dari luar, penerusan biasanya diarahkan ke yang salah dari keduanya. Yang harus sejajar adalah rantai: aturan publik mencapai pembungkus, dan koneksi backend pembungkus itu sendiri mencapai soket VPN sebenarnya. Empat lompatan membawa rantai itu, dan salah satunya dapat mengakhiri penyelidikan lebih awal.

Dua soket, dua pemilik, salah satunya publik

Pembungkus menuntaskan TLS untuk koneksi luar dan meneruskan aliran byte yang didekripsi ke pendengar OpenVPN TCP biasa. Keduanya soket terpisah dengan berkas konfigurasi terpisah, jadi menyunting satu membiarkan yang lain tak tersentuh dan tampak sehat. Artinya juga keduanya bisa saling menjauh setiap kali satu diubah tanpa yang lain.

Bekerja dari mesin itu sendiri karena itu membuktikan sangat sedikit tentang jalur publik. Koneksi langsung ke port asli melewati pembungkus, koneksi ke pembungkus pada alamat LAN-nya melewati terjemahan, dan hanya susunan lengkap di sisi klien yang melatih apa yang dilakukan pengguna luar. Nama juga perlu dibaca cermat, karena localhost berarti host yang menjalankan komponen tersebut, bukan host yang kebetulan Anda ketik. Simpan perbedaan itu dalam catatan Anda, karena uji yang dicatat tanpa lompatan yang dicakupnya mengundang perbandingan antara dua hal berbeda.

Ke mana penerusan benar-benar mendarat

Rantai lebih mudah dipegang sebagai empat lompatan daripada tiga nomor port, karena nomor yang sama bisa berarti hal berbeda di tiap ujung. Baca tabel baris demi baris: setiap baris adalah satu soket yang harus menerima koneksi lalu membuka yang berikutnya. Saat sebuah baris diarahkan ke pasangan yang salah, gejala di kolom terakhir itulah yang dilaporkan pengguna.

Aturan yang menyasar port VPN asli alih-alih pembungkus melewati penuntasan TLS sepenuhnya, dan itulah versi paling umum dari kesalahan ini: klien membuka jabat tangan dengan pendengar yang mengharapkan pembingkaian OpenVPN, sehingga koneksi bisa terbuka lalu macet. Pastikan port terjemahan terhadap berkas konfigurasi pembungkus, bukan terhadap ingatan, karena orang berikutnya yang menyunting berkas itu mungkin memilih nomor lain. Dua perintah di bawah menunjukkan kedua sisi pertanyaan itu sekaligus.

grep -nE '^[[:space:]]*(accept|connect)' /etc/stunnel/stunnel.conf
ss -lntp | grep -E ':443|:8443|:1194'

Alamat pengikatan yang menolak Anda

Baris accept yang terikat ke 127.0.0.1 hanya menjawab host itu sendiri, sehingga penerusan yang tiba di alamat LAN tidak dapat terhubung dan klien melihat penolakan yang terdengar seperti masalah penyaring paket. Lihat soketnya sebelum menyentuh firewall, karena soket adalah jawaban yang lebih murah. Entah ikat pembungkus ke antarmuka yang disasar penerusan, atau biarkan di loopback dan buat penerusan mencapai loopback melalui sesuatu yang benar-benar bekerja. Itu dua rancangan, dan masing-masing butuh aturannya sendiri.

Mencampur keduanya adalah cara pembungkus yang berfungsi menjadi tak terjangkau dari luar sementara setiap berkas tampak benar. Pemeriksaan di bawah adalah satu perintah, dan ia menjawab pertanyaan yang tidak bisa dijawab tinjauan aturan firewall. Jika keluaran menunjukkan alamat loopback sementara penerusan menyasar alamat LAN, perbaikannya ada di baris accept, bukan di penyaring paket.

ss -lntp '( sport = :8443 )'

Apa yang sebenarnya dibuktikan uji lokal

Keberhasilan yang dicatat tanpa lompatan yang dicakupnya bukan bukti tentang lompatan lain. Catat alamat mana yang dipakai uji dan proses mana yang menjawab. Lalu ulangi dari luar jaringan, bukan dari ponsel di Wi-Fi yang sama, karena perilaku jepit rambut berbeda antar router dan koneksi yang tak pernah meninggalkan LAN bisa memuaskan klien tanpa penerusan terlibat sama sekali. Hanya percobaan kedua itulah yang melatih jalur yang ditempuh orang asing.

Saat percobaan gagal, ikuti satu koneksi di kedua log: baris diterima dan terhubung milik pembungkus, lalu log sesi daemon VPN sendiri. Batas pertama yang tidak mencatat apa pun adalah tempat perubahan berikutnya. Begitu OpenVPN membandingkan opsi pasangan, nilai pesan itu menurut aturan implementasi tersebut. Peringatan ketidaksesuaian link-mtu tidak otomatis fatal, memakukan link-mtu pada 1500 tidak membuktikan fragmentasi berhenti, dan negosiasi cipher milik konfigurasi OpenVPN bagian dalam, bukan penerusan router.

nc -vz 127.0.0.1 1194
journalctl -u stunnel -n 50 --no-pager

Probe itu mencakup soket backend dan log pembungkus, yang memisahkan backend yang ditolak dari jabat tangan yang ditolak. Jalankan selagi satu percobaan berlangsung, bukan sesudahnya. Stempel waktu dari satu percobaan itulah yang membuat perbandingan tepercaya.

Dua identitas, dua urutan kegagalan

Sertifikat luar milik pembungkus dan identitas dalam milik OpenVPN, dan keduanya bisa berasal dari otoritas berbeda. Menonaktifkan salah satu pemeriksaan agar jalur tampak sehat menukar perlindungan nyata dengan hasil kosmetik. Pertahankan kedua verifikasi dan awakutu sesuai urutan, karena urutan pesan menamai lapisan: masalah sertifikat pembungkus muncul sebelum opsi VPN apa pun dinegosiasikan, sedangkan kegagalan identitas dalam baru muncul setelah aliran terbentuk.

manual stunnel mendefinisikan accept, connect, dan mode klien dengan tepat, dan bagian itu menjawab pertanyaan soket lebih cepat daripada menebak. Saat Anda masih belum bisa mengatakan lapisan mana yang menjawab, baca sertifikat yang disajikan port publik dengan perintah di bawah. Sertifikat pembungkus dalam keluaran berarti penerusan mencapai pembungkus, sedangkan keheningan atau galat protokol berarti tidak. Satu perbedaan itu menghemat lebih banyak waktu daripada pemeriksaan lain di sini.

openssl s_client -connect vpn.example:443 -servername vpn.example </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer