Lompatan NAT mana yang menjatuhkan pemetaan VPN diam, dan cara mengetahuinya
Aliran VPN diam bisa mati di setiap lompatan yang menyimpan status. Ulangi satu uji, bandingkan apa yang dilihat tiap batas, dan laporkan hasil terbatas alih-alih tersangka dugaan.
Setelah masa tenang terowongan tersambung lagi, tidak ada log yang menyebut pelaku, dan langkah jelasnya adalah memilih perangkat dengan dokumentasi batas waktu paling mengesankan. Itu dugaan yang berpakaian diagnosis. Status bisa bertahan sebentar di router rumah, di penerjemah operator, dan di tepi cloud, dan salah satunya bisa menjatuhkan aliran yang menjadi diam. Yang bisa Anda lakukan sebagai gantinya adalah memetakan jalur, menandai perangkat mana yang benar-benar bisa Anda amati, dan menjalankan satu uji diam yang bisa Anda ulangi.
Uji yang bisa diulang mengubah anekdot menjadi pengukuran. Semua di bawah mengasumsikan satu klien, satu server, dan satu protokol, dan mengasumsikan Anda menahan diri mengubah dua variabel sekaligus. Intinya adalah membuat kejadian berikutnya lebih murah daripada yang ini.
Jalankan uji diam yang sama setiap kali
Catat kapan aliran terakhir diketahui baik, berapa lama ia diam setelah itu, dan apakah satu paket segar mengembalikannya. Ketiga fakta itu adalah pengukurannya; tanpanya Anda hanya punya cerita tentang laptop yang jatuh. Gunakan klien yang sama, server yang sama, dan protokol yang sama pada setiap pengulangan, dan catat saat paket pertama setelah keheningan dikirim.
Lalu bandingkan apa yang benar-benar dilihat setiap batas yang Anda miliki. Pembeda yang menentukan penyelidikan adalah apakah server tidak melihat apa pun setelah jeda, atau melihat permintaan dan menjawab ke jalur yang tidak lagi membawa balasan.
| What you observe | What it suggests | What it does not prove |
|---|---|---|
| server records no packet after the pause | state was lost upstream of the server | which hop dropped it |
| server answers, client never receives | return-path state or filtering | that the timer belongs to the client |
| client sends nothing at all | client-side timer or application behaviour | that the network path is healthy |
Membandingkan jalur tanpa mengubah lima hal
Jaringan akses kedua yang disetujui adalah perbandingan yang sah, karena rantai NAT-nya berbeda. Ia juga berbeda dalam penyedia, kondisi radio, dan mungkin keluarga alamat, jadi hasilnya adalah batas, bukan atribusi. Catat keterbatasannya bersama hasilnya alih-alih diam-diam membuangnya saat melapor. Tuliskan jalurnya sekalian: perangkat, peran, dan apakah statusnya bisa dibaca sama sekali.
Yang dibeli perbandingan jalur adalah pertanyaan terbatas: aliran bertahan di satu dan mati di yang lain setelah keheningan serupa, jadi variabelnya ada di suatu tempat pada bagian yang berbeda. Itu hasil nyata bahkan saat tidak ada perangkat yang disebut, dan itu memberi tahu insinyur berikutnya di mana menghabiskan satu sore dan di mana tidak.
Status lokal layak dibaca sebelum Anda berspekulasi tentang operator. Di gateway Linux, conntrack -L mendaftar aliran yang dilacak dengan sisa masa hidupnya, yang mengubah dugaan tentang pengatur waktu menjadi angka yang bisa Anda lihat kedaluwarsa. Bacalah sebelum dan sesudah periode diam, bukan hanya sesudah.
Apa yang akan ditahan sinyal jaga dan apa yang tidak
Sinyal jaga yang didukung menahan pemetaan tetap terbuka, dan menahan pemetaan terbuka tidak membuktikan apa pun tentang layanan di belakangnya. Terowongan bisa tetap terpetakan sementara aplikasi yang dibawanya sudah berhenti menjawab, dan dari lampu status kedua situasi itu tampak sama. Perlakukan sinyal jaga sebagai asuransi terhadap kedaluwarsa diam, bukan sebagai pemeriksaan kesehatan.
Atur interval terhadap batas waktu terpendek yang benar-benar Anda ukur, bukan angka yang disalin dari forum. Sinyal jaga yang disetel di bawah setiap pengatur waktu yang masuk akal adalah lalu lintas yang tidak dibutuhkan siapa pun, dan itu juga menghapus gejala yang akan memberi tahu Anda batas mana yang kedaluwarsa lebih dulu. Pilih intervalnya dari angka yang diukur dan biarkan hal lain apa adanya.
Satu perubahan, lalu ukur lagi
Tahan dorongan untuk menaikkan setiap batas waktu dan membersihkan setiap gateway selama uji langsung. Itu menghapus bukti yang Anda cari dan mengganggu aliran orang lain, yang merupakan pertukaran buruk untuk hipotesis yang belum Anda uji. Ubah satu pengaturan yang didukung pada satu perangkat, lalu ulangi periode diam dan pemulihan aplikasi.
Catat pengamatan batas mana yang bergeser, dan catat bahkan ketika tidak ada yang membaik. Pengaturan yang tidak memperbaiki apa pun adalah informasi, dan lebih murah menyadarinya sekali daripada menggulirkannya ke seluruh estate.
Menulis temuan yang bisa Anda pertahankan
Ketika penerjemah di hulu tidak bisa diperiksa, katakan hanya apa yang didukung bukti: pertukaran mati di suatu tempat di sepanjang bentang jalur ini setelah sekian lama tenang, dan lompatan yang bertanggung jawab tetap tanpa atribusi. Pernyataan terbatas bertahan dalam tinjauan dan mengarahkan orang berikutnya ke segmen yang tepat. Menyebut router tersembunyi sebagai penyebab tidak melakukan keduanya. Serahkan temuan terbatas kepada pemilik segmen yang tidak teramati, dengan interval terlampir.
RFC 4787 menjelaskan mengapa pengatur waktu pemetaan UDP sulit disimpulkan dari satu ujung, dan kesulitan itulah alasan temuan terbatas adalah yang jujur. Pengatur waktu itu nyata, dan begitu pula ketidakpastian di sekitarnya.