Relay VPN berhenti menerima SSH: batas deskriptor berkas

Sebuah jabat tangan WireGuard masih selesai, peer masih menampilkan endpoint terbaru, namun sesi SSH baru melalui relay di belakangnya menggantung tanpa banner. Kombinasi itu menjauh dari terowongan dan menuju proses yang menerima soket. Relay seperti socat duduk di jalur aplikasi dengan anggaran deskriptornya sendiri, anak-anaknya sendiri, dan batas warisannya sendiri. Penelusuran di bawah dimulai di klien dan berhenti pada komponen pertama yang tidak dapat membuka soket lain.

Telusuri jalurnya sebelum mengubah angka

Telusuri satu permintaan yang gagal daripada menalar tentang terowongan secara keseluruhan. Klien menulis ke terowongan, daemon VPN mendekripsi dan merutekan, dan relay menerima di sisi jauh. Setiap langkah memakai deskriptor, dan yang biasanya habis adalah yang terakhir.

Mulailah dengan permintaan yang dapat Anda reproduksi dan ukur waktunya. Jika jabat tangan TCP selesai tetapi banner aplikasi tidak datang, relay mengambil soket lalu macet di anak atau di kaki hulunya. Jika jabat tangan itu sendiri tidak pernah selesai, penyebabnya adalah perutean, firewall, atau status pendengar, bukan plafon deskriptor. Catat bentuk mana dari keduanya yang Anda amati, karena keduanya menunjuk ke proses berbeda.

Hitung juga lompatan yang menggandakan pekerjaan. Pendengar bercabang menyerahkan setiap soket yang diterima ke anak yang menyimpan salinannya sendiri, jadi total sebenarnya adalah sifat seluruh pohon, bukan hanya induknya.

Baca batas yang diwarisi relay

Satu-satunya batas yang penting milik proses yang berjalan, dan itu ditetapkan oleh apa pun yang meluncurkan proses tersebut. Mengetik ulimit -n di shell menjelaskan shell. Tanyakan kepada manajer layanan apa yang diterapkannya, lalu konfirmasi pada PID.

systemctl show -p MainPID -p LimitNOFILE vpn-relay.service
cat /proc/$(systemctl show -p MainPID --value vpn-relay.service)/limits

Berkas limits mencetak plafon lunak dan keras seperti yang dilihat proses. Nilai lunak rendah di bawah nilai keras yang lapang berarti daemon diizinkan menaikkan plafonnya sendiri, dan sebagian melakukannya saat mulai; nilai lunak rendah yang sama berarti berkas unit adalah sumbernya.

Drop-in dimuat dalam urutan leksikal dan berkas yang lebih akhir menang, jadi systemctl cat vpn-relay.service adalah pandangan otoritatif tentang apa yang berlaku. Menyunting berkas yang tidak pernah dibaca manajer adalah alasan paling umum mengapa angka yang dinaikkan tidak berefek.

Pisahkan konkurensi mantap dari keadaan yang tertahan

Dua proses dapat menabrak plafon yang sama karena alasan yang tidak terkait, dan obatnya berbeda. Permintaan yang mengikuti sesi bersamaan yang berguna adalah pertanyaan kapasitas. Pertumbuhan yang berlanjut setelah pekerjaan selesai adalah kebocoran atau kumpulan sesi yang tidak ditutup siapa pun.

Ukur saat menganggur, pada puncak normal Anda, dan lagi beberapa menit setelah beban berhenti. Menghitung entri terbuka dengan ls /proc/PID/fd | wc -l terhadap batas lunak memberi tahu Anda selisihnya, dan hitungan satu atau dua di bawah plafon adalah penghentian keras, bukan jalur lambat.

Ketika hitungan menolak turun, lihat keadaan soket alih-alih total. Deskriptor yang duduk di CLOSE_WAIT berarti peer menutup dan sisi Anda tidak pernah melakukannya, yang merupakan cacat siklus hidup aplikasi yang hanya ditunda oleh batas yang lebih besar. Batasi juga model anak: relay bercabang tanpa batas atas anak bersamaan menghabiskan deskriptor, slot proses, dan memori sekaligus.

Periksa nilai baru pada proses yang hidup

Setelah menyunting unit, muat ulang manajer dan mulai ulang layanan, karena memuat ulang saja tidak pernah mengganti batas yang sudah diwarisi proses yang berjalan. Verifikasi pada proses yang benar-benar melayani lalu lintas.

systemctl daemon-reload
systemctl restart vpn-relay.service
awk '/Max open files/ {print}' /proc/$(systemctl show -p MainPID --value vpn-relay.service)/limits
ss -tnp state established '( sport = :2222 )' | wc -l

Baris awk mengembalikan pasangan baru; jika masih menampilkan yang lama, drop-in yang Anda sunting bukan yang dimuat. Hitungan ss adalah pemeriksaan beban kerja Anda, jadi buka jumlah sesi yang Anda harapkan dan lihat ia menanjak. Hitungan yang terus naik setelah sesi itu ditutup berarti batas itu bukan seluruh masalahnya.

Satu peringatan menyertai setiap kenaikan besar. Aplikasi yang melakukan polling dengan select() tidak dapat mengawasi deskriptor di atas FD_SETSIZE, yang bernilai 1024 pada build biasa, jadi plafon yang dinaikkan melewatinya dapat menghasilkan kegagalan yang tampak tidak terkait. Referensi eksekusi systemd membawa peringatan yang sama untuk layanan yang diluncurkannya.

Jauhkan mulai ulang dari ketersediaan terowongan

Memulai ulang relay menjatuhkan sesi aktifnya, dan itu peristiwa terpisah dari VPN yang mati. Aturlah perubahan agar terowongan tetap hidup sementara relay berputar, dan beri tahu siapa pun yang sesi panjangnya melewatinya.

Pengembalian mundur adalah berkas unit sebelumnya plus satu mulai ulang lagi, dan berkas itu tetap di tempatnya sampai nilai baru bertahan satu hari kerja. Lalu tutup lingkaran dengan permintaan yang semula gagal: satu sesi SSH baru melalui relay, satu transfer yang cukup panjang untuk berarti, dan hitungan deskriptor yang kembali ke tingkat menganggurnya.