Daftar Game LAN Kosong lewat OpenVPN? Periksa Jalur Penemuan

Melakukan ping ke alamat tunnel pemain lain dan melihat game yang ia host adalah dua pencapaian berbeda. Daftar di lobi biasanya bergantung pada pertukaran penemuan yang ditulis untuk satu jaringan lokal, sedangkan sesi game adalah koneksi biasa ke alamat dan port. Menganggap daftar kosong sebagai kegagalan routing akan mengarahkan Anda ke jembatan yang mungkin tidak diperlukan, jadi pisahkan kedua pertanyaan itu sebelum mengubah apa pun.

Pisahkan bergabung ke sesi dari menemukannya

Gabung yang gagal menunjuk pada rute, aturan firewall, dan layanan yang mendengarkan. Gabung yang berhasil dengan daftar kosong menunjuk pada penemuan, atau pada alamat yang dibawa pengumuman. Kedua hasil itu mengarah ke pekerjaan yang sama sekali berbeda, dan Anda hanya bisa membedakannya dengan sengaja mencoba yang pertama.

Catat hasilnya sebelum Anda menyentuh konfigurasi VPN. Itu adalah uji termurah dalam seluruh penyelidikan dan menghapus separuh ruang desain. Catat juga alamat yang Anda pakai, karena itulah yang menjadi titik acuan untuk setiap uji berikutnya. Tanpa baris itu di catatan Anda, perbandingan berikutnya hanyalah dugaan.

Uji gabung langsung sebelum menyentuh tunnel

Jika game menawarkan opsi koneksi langsung, gunakan alamat tunnel host dan port game yang terdokumentasi, dan biarkan autentikasi game itu sendiri serta aturan firewall host tetap utuh. Gabung yang berhasil mempersempit masalah ke penemuan. Gabung yang gagal tetap memerlukan penyelidikannya sendiri, dan tidak ada relai yang akan memperbaikinya.

Jangan menganggap port penemuan dan port sesi adalah nomor yang sama. Game biasanya mengumumkan pada satu port UDP dan menerima pemain di port lain, dan relai yang dibuat untuk port yang salah menghasilkan daftar yang tetap kosong.

Periksa juga adaptor mana yang dipilih proses hosting. Proses yang terikat ke alamat LAN rumah akan mengumumkan alamat itu, dan pemain jarak jauh tidak dapat merutekan ke sana meskipun pengumumannya sampai. Daftar bisa terisi dan gabung tetap gagal hanya karena itu.

Pahami di mana siaran berhenti

Tunnel TUN yang dirutekan membawa paket IP antar peer dan tidak mereproduksi siaran lokal di jaringan setiap peer. Alamat siaran terbatas 255.255.255.255 tetap di dalam antarmuka yang memancarkannya, dan siaran yang diarahkan ke subnet adalah kasus tersendiri, bukan lisensi umum bagi router untuk membanjiri pengumuman.

Itu sifat desain, bukan cacat yang ditambal dengan opsi. OpenVPN dan opsi client-to-client mengatur lalu lintas peer di dalam tunnel dan bukan relai penemuan, meskipun disarankan untuk tujuan ini di banyak utas. Relai adalah komponen terpisah dengan konfigurasinya sendiri dan mode kegagalannya sendiri. Menganggap opsi yang sudah ada sudah mencakupnya adalah cara paling umum penyelidikan ini mandek.

Penemuan multicast punya masalah yang sama dengan kelas alamat berbeda, dan memerlukan routing multicast atau relai, bukan pengecualian siaran.

Saat relai dibenarkan, buatlah sempit

Jika penemuan otomatis adalah syarat, identifikasi dulu pertukaran sebenarnya: siaran atau multicast, alamat tujuan, port UDP, antarmuka yang mengirimkannya, dan alamat di dalam balasan. Relai yang sesuai protokol dan dibatasi pada lima fakta itu jauh lebih sempit daripada memperluas seluruh segmen Ethernet.

Meneruskan paket tanpa perubahan bisa tetap tidak cukup. Jika payload memberi tahu penerima untuk terhubung ke alamat yang tidak dapat dijangkau, relai memberikan jawaban yang tidak berguna, karena itu antarmuka game itu sendiri atau pengaturan alamat yang diumumkan harus dicoba sebelum ada relai apa pun.

Batasi relai pada antarmuka dan peer yang membutuhkannya, dan tentukan bagaimana balasan menemukan peminta. Mengulang siaran yang tidak terkait mengekspos layanan lokal lain dan menciptakan loop yang menyakitkan untuk di-debug nanti.

Jembatan hanya bila desain membutuhkan Ethernet

Frame Ethernet berjalan di dalam TAP, jadi tunnel TAP dapat menjadi bagian dari domain siaran yang sengaja dijembatani. Sekadar mengganti dev tun menjadi dev tap tidak membangun jembatan itu, tidak membuat konfigurasi server kompatibel, dan tidak membuat aplikasi memilih antarmuka baru. Panduan jembatan OpenVPN menjelaskan susunan yang lebih luas, bukan obat untuk satu lobi kosong.

Penjembatanan juga meratakan rencana alamat, karena itu keputusan ini pantas mendapat alasan selain ketidaksabaran. Dua jaringan yang tadinya terpisah menjadi satu, dan setiap layanan di kedua sisi mulai melihat siaran sisi lain. Konsekuensi itu harus masuk catatan perubahan sebelum siapa pun mengaktifkannya. Tidak ada aturan bahwa klien game harus berada di rentang 192.168; pilih rencana tanpa tumpang tindih dan periksa batasan game bersangkutan alih-alih menomori ulang tunnel karena sebuah kiriman forum melakukannya.

Pada akhirnya pisahkan kedua hasil: apakah host bisa dimasuki, dan apakah balasan penemuan mengumumkan tujuan yang benar-benar dapat dipakai pemain lain. Memperbaiki yang kedua tanpa memastikan yang pertama adalah cara orang akhirnya memelihara jembatan untuk masalah yang tidak pernah soal siaran.