Mengapa hanya satu klien VPN yang terhubung di belakang router yang sama

Dua laptop berada di jaringan rumah yang sama, dan VPN kantor hanya menerima satu di antaranya. Yang kedua kehabisan waktu atau menunggu sampai yang pertama terputus, dan tidak ada yang menyentuh pengaturan klien di antara kedua percobaan. Kredensialnya sama dengan yang berhasil satu menit lalu, dan itulah petunjuk bahwa autentikasi bukan penyebab kegagalan. Tiga mekanisme menghasilkan pola ini, dan log server sendiri mengatakan mana yang Anda hadapi.

Baca log gateway sebelum menyentuh klien

Catatan server atas kedua percobaan menjawab pertanyaan pertama, dan menjawabnya dengan salah satu dari tiga cara. Jika percobaan kedua tidak pernah muncul di log itu, paketnya tidak pernah sampai ke pendengar, dan masalahnya ada pada router rumah atau jalur penyedia. Jika log mencatat percobaan lalu menolaknya, terowongan sudah sampai, jadi persoalannya identitas, lisensi, atau batas sesi, bukan sesuatu di kabel. Jika log mencatat sesi berhasil sementara klien masih melaporkan kegagalan, periksa jalur balik atau kemungkinan dua klien diberi alamat terowongan yang sama.

Hotspot ponsel memisahkan kedua keluarga itu dengan murah: jalankan klien kedua melalui data seluler sementara yang pertama tetap terhubung. Keberhasilan di sana menunjuk jaringan rumah, dan kegagalan yang sama di sana menunjuk gateway, sehingga router tetap tidak bersalah. Tidak ada hasil yang menentukan sendirian, tetapi masing-masing menyingkirkan separuh ruang pencarian dalam satu percobaan.

Tulis hasilnya sebelum mengubah apa pun, karena tiga hasil log menuntun ke tiga perbaikan yang tidak berkaitan. Catatan yang menyebut mana dari ketiganya yang Anda lihat lebih bernilai daripada tangkapan layar kesalahan klien.

Apa yang dilakukan router dengan GRE dan NAT-T

PPTP adalah pelaku klasik: kanal kendali adalah TCP 1723 sedangkan jalur data adalah GRE, protokol IP 47. Banyak router konsumen menyertakan pembantu PPTP yang melacak satu koneksi kendali, sehingga klien kedua di belakang NAT yang sama membuka kanal kendalinya lalu tidak menerima jalur data sama sekali. Meneruskan port TCP bernomor 47 tidak melakukan apa pun untuk GRE, karena GRE adalah nomor protokol, bukan port.

L2TP di atas IPsec berperilaku berbeda secara desain: IKE memakai UDP 500, penembusan NAT memindahkan muatan terlindungi ke UDP 4500, dan enkapsulasi ada justru agar beberapa klien di belakang satu alamat dapat mencapai gateway yang sama. Desain itu tidak mencegah gateway atau kotak perantara memberlakukan batas sesi per alamat, dan dari sofa kedua kegagalan tampak identik. Protokol asli SoftEther memiliki kelas masalah yang sama: router tanpa penerusan yang berfungsi menerima klien pertama dari LAN dan menjatuhkan yang kedua. Uji sakelar ALG atau penerusan router pada kedua posisi, karena pembantu yang ditulis untuk klien lama dapat merusak paket yang dikirim klien sekarang.

nc -vz 203.0.113.5 1723
sudo tcpdump -ni any proto gre

Batas identitas yang tampak seperti batas transportasi

Router bukan satu-satunya tersangka, dan log membedakannya dari alternatif. Ketika server OpenVPN menyematkan nama umum ke satu alamat terowongan, kedua perangkat menerima alamat itu, dan tanpa duplicate-cn sesi yang lebih baru mendorong yang lama keluar. Mengaktifkan opsi itu membiarkan keduanya terhubung tetapi meninggalkan mereka dengan satu identitas, satu sertifikat, dan satu keputusan pencabutan, yang lebih buruk daripada kelihatannya. Perangkat kedua lalu tidak akan pernah bisa dicabut sendiri, jadi satu sakelar kenyamanan diam-diam menghapus kendali yang mungkin Anda butuhkan nanti.

Baca jurnal server dan berkas statusnya bersama-sama, karena yang satu menunjukkan keputusan autentikasi dan yang lain menunjukkan siapa yang sedang terhubung. Dua entri dengan nama umum yang sama dan satu alamat virtual memastikan tabrakan identitas, bukan batas router. Gateway komersial menambahkan batasnya sendiri, seperti paket yang mengizinkan satu sesi bersamaan, jumlah lisensi, atau aturan yang mengizinkan satu sesi per alamat publik, dan tidak ada pengaturan router yang mengubah satu pun dari itu.

sudo journalctl -u openvpn-server@server -n 60 --no-pager
cat /run/openvpn/server.status

Cocokkan perbaikan dengan entri log

Penolakan di log menuntut kredensial terpisah per perangkat, batas lebih tinggi dari pengelola layanan, atau titik akhir gateway kedua untuk satu mesin. Jika tidak ada percobaan kedua yang pernah sampai ke server, perbaikan yang tahan lama adalah router yang meneruskan protokol dan menahan lebih dari satu sesi, atau transportasi yang ditangani router dengan baik, seperti satu aliran TCP atau UDP. Memilih di antara itu adalah keputusan tentang umur perangkat keras, bukan tentang pengaturan klien.

Jangan menyalin profil perangkat yang berfungsi ke mesin kedua lalu menganggapnya selesai. Itu mengubah masalah koneksi menjadi masalah kendali akses, karena laptop yang hilang tidak lagi bisa dibedakan dari salinan yang masih dipakai. Itu juga menyembunyikan gangguan aslinya, yang kembali begitu perangkat ketiga muncul.

Memverifikasi dua sesi aktif

Hubungkan kedua perangkat pada waktu yang sama, jalankan aplikasi yang dimaksud di masing-masing, lalu sambungkan ulang salah satunya dan ulangi. Ikon kedua yang muncul sebentar tidak membuktikan apa pun tentang lalu lintas, dan sesi yang putus setelah sepuluh menit adalah bug lain dengan pemilik lain. Bandingkan apa yang dilaporkan server pada akhirnya dengan apa yang dilihat pengguna, karena kedua catatan itu sering tidak sepakat.

Jika kedua sesi bertahan dan membawa lalu lintas, perbaikannya bertahan dan catatan yang Anda tulis di awal menjadi rekam jejak apa yang salah. Jika hanya satu yang bertahan, kembalilah ke langkah pertama dan periksa mana dari tiga hasil log yang sekarang Anda miliki, karena jawabannya mungkin sudah berubah. Pembantu router dapat menyamarkan masalah yang muncul lagi di jaringan lain, sedangkan batas per alamat mengikuti pengguna, bukan perangkat. Menguji dari jaringan kedua adalah cara termurah untuk mengetahui mana yang benar-benar Anda perbaiki.