Setelan punchy Nebula: mana yang memperbaiki NAT Anda

Dua peer menemukan satu sama lain lewat mercusuar lalu gagal membangun jalur langsung, dan naluri pertama adalah menyalakan setiap opsi punchy. Naluri itu menghasilkan konfigurasi dengan tiga perubahan tanpa tahu mana yang penting. Setelan itu menjawab pertanyaan berbeda: satu memelihara pemetaan yang sudah ada, dan satu mencoba handshake ke arah sebaliknya. Putuskan pertanyaan mana yang Anda punya sebelum menyentuh keduanya.

Pastikan titik ujung sebelum waktu

Peer yang tidak pernah muncul di alamat yang diharapkan tidak akan diselamatkan oleh penyetelan punch. Periksa apa yang diketahui mercusuar tentang peer itu dan apa yang diumumkan konfigurasinya sendiri, karena alamat bootstrap yang basi atau alamat privat yang terbit karena kesalahan menggagalkan setiap trik penembusan. Pastikan juga sertifikatnya tepercaya, karena identitas yang tidak tepercaya menghentikan percakapan jauh sebelum NAT jadi soal. Lalu pastikan UDP benar-benar mencapai mercusuar. Nilai waktu adalah hal terakhir yang dilihat, bukan yang pertama.

Catat pasangan titik ujung yang Anda uji, supaya perbandingan berikutnya memakai peer yang sama, bukan dua mesin lain.

punch mempertahankan pemetaan, respond membuka arah

Opsi punch mengirim paket kosong secara berkala ke alamat lapisan bawah peer yang sudah punya terowongan. Tujuannya tidak mulia: mencegah NAT stateful atau firewall menghapus pemetaan yang menjadi tumpuan jalur langsung. Opsi respond mengubah apa yang terjadi saat ada notifikasi mercusuar, membuat host mencoba handshake balik ke arah peer yang berusaha menjangkaunya. Itu mekanisme berbeda dengan cara gagal yang berbeda.

Pilih punch saat jalur langsung bekerja lalu melemah. Pilih respond saat jalur tidak pernah terbentuk di satu arah. Menyalakan keduanya dan berharap adalah cara perbaikan lima menit menjadi seminggu penyetelan.

Jeda menentukan kapan, bukan apakah

Nilai jeda menggeser waktu: satu berlaku untuk paket yang dikirim setelah notifikasi, yang lain untuk upaya handshake terbalik. Keduanya tidak membuat arah yang terblokir berfungsi. Mengubah keduanya sekaligus merusak perbandingan yang hendak Anda jalankan.

Biarkan keduanya sampai mekanismenya benar. Lalu sesuaikan satu, dan catat nilai lamanya.

Saat relai adalah jawaban jujur

Sebagian kombinasi NAT tidak dapat mendukung jalur langsung, bagaimana pun waktunya ditata. NAT simetris di kedua sisi, atau firewall yang membuang seluruh lalu lintas masuk yang tidak diminta, tidak menyisakan apa pun untuk ditembus.

Simpul relai dengan alamat yang dapat dijangkau memberi peer tersebut jalur yang tidak bergantung pada keberhasilan penembusan. Itu memakan bandwidth lewat simpul itu, jadi ini keputusan tentang kapasitas, bukan jalan pintas. Konfigurasikan relai dengan sengaja dan pastikan peer dapat menjangkaunya, karena relai yang sendiri berada di balik NAT sulit tidak mengubah apa pun. Lalu berhenti menyetel punch untuk pasangan itu, karena jalur langsung tidak akan pernah muncul.

Uji pasangan yang gagal, setelah menganggur

Reproduksi kondisi yang rusak: biarkan pasangan menganggur selama interval yang sama, atau ulangi urutan handshake yang dulu gagal. Lalu jalankan aplikasi di antara kedua peer itu, bukan permintaan ke mercusuar. Jawaban mercusuar membuktikan jalur kendali dan bukan apa pun tentang jalur data.

Catat setelan mana yang berubah, waktunya, dan apakah jalur langsung muncul atau lalu lintas tetap di relai. Jika tetap, jawabannya relai dan catatan kapasitas, dan itu hasil yang sangat baik. Jika muncul, pertanyaan berikutnya apakah ia bertahan satu jam menganggur, karena pemetaan yang melemah justru masalah yang ada karena punch.