Terowong kembali, klien berkata bersambung, dan pelayar masih berpusing pada halaman yang sedang dimuatnya sebelum terputus. Sambung semula VPN memulihkan laluan, dan ia tidak memulihkan keadaan sambungan yang dikumpulkan aplikasi dan pihak jauh pada laluan lama. Kedua-duanya perkara berbeza untuk dibaiki, dan mengelirukannya menghantar anda kembali ke tetapan VPN tanpa sebab.

Satu ujian memisahkan kedua-duanya dengan bersih, dan ia mengambil sepuluh saat. Hantar permintaan baharu ke destinasi yang sama semasa yang lama masih tergantung.

Apa yang terselamat daripada sambung semula dan apa yang tidak

Terowong ialah satu set laluan, kunci dan alamat, dan sambung semula boleh memulihkan ketiga-tiganya sementara setiap aliran yang terjalin kekal mati. Sistem pengendalian menyimpan soket terbuka kerana aplikasi memintanya, dan had masa soket itu mungkin beberapa minit atau jam lagi. Di bawahnya, rakan setara telah lupa aliran itu, entri terjemahan telah luput, atau laluan kini melalui titik akhir yang tidak pernah melihat jabat tangan. Tiada apa pun dalam jujukan sambung semula yang menelusuri soket aplikasi dan membaikinya.

Sesetengah klien menambah cangkuk yang membuang sambungan usang semasa sambung semula, dan kebanyakannya tidak. Tingkah laku di sini berbeza mengikut klien, platform dan versi.

Pihak jauh juga melupakan anda

Hujung jauh menyimpan keadaannya sendiri: sesi TLS, blok kawalan TCP dan mungkin entri pemetaan yang mengikat alamat dan port anda pada aliran itu. Peranti terjemahan di sepanjang laluan boleh membiarkan pemetaan itu luput semasa jurang walaupun terowong pulih dengan pantas. Setelah pemetaan hilang, paket tiba untuk aliran yang tidak lagi dikenali pelayan, dan balasannya mungkin reset yang tidak pernah ditunjukkan oleh klien. Aplikasi melaporkan ini sebagai tersekat dan bukan sebagai ralat, kerana ia masih menunggu soket yang tidak akan menjawab.

Had masa melahu di sisi pelayan melakukan perkara yang sama mengikut jadualnya sendiri, sebab itulah sesi boleh mati tanpa sebarang peristiwa rangkaian. Sambungan yang melahu lebih lama daripada yang dijangkakan pelayan sudah hilang sebelum anda perasan terowong itu bergerak.

Permintaan baharu ialah ujian yang memisahkan kedua-duanya

Hantar permintaan baharu ke hos yang sama semasa yang lama masih tergantung, dan perhatikan kedua-duanya. Jika permintaan baharu berjaya, maka terowong, laluan dan penyelesaian nama semuanya berfungsi, dan kerosakan terhad kepada aliran usang. Jika permintaan baharu juga gagal, anda mempunyai masalah laluan dan keadaan sesi aplikasi itu ialah petunjuk palsu.

Biarkan sebarang sekatan trafik langsung kekal di tempatnya semasa ujian. Permintaan yang berjaya melalui laluan sandaran yang tidak disengajakan tidak membuktikan apa-apa tentang terowong.

Sahkan dengan sambungan baharu, bukan yang lama

Perintah di bawah menunjukkan soket yang masih terbuka, memulakan satu permintaan baharu, dan memeriksa sama ada jadual sesi masih menyimpan entri untuk aliran itu. Jalankan yang pertama sebelum dan selepas sambung semula supaya perbezaannya kelihatan. Gantikan hos dan port dengan perkhidmatan anda sendiri.

ss -tanp | grep -E ':(443|8443)'
curl -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 https://intranet.example.com/
conntrack -L 2>/dev/null | grep 8443
dig +short intranet.example.com

Soket yang terjalin tanpa trafik bergerak ialah tanda yang perlu dicari, dan permintaan baharu yang mengembalikan kod status menunjukkan laluan itu hidup. Jadual sambungan menjawab sama ada sesuatu masih memetakan aliran itu, dan itulah bahagian yang tidak dapat dilihat oleh klien. Pertanyaan penyelesai meliputi separuh lagi pemuatan halaman, kerana kegagalan nama dan sambungan tersekat kelihatan sama dalam pelayar. Bersama-sama, keempat-empat keluaran itu memisahkan sesi usang daripada terowong yang rosak.

Catat masa gangguan, masa sambung semula dan perbezaan antara permintaan lama dan baharu. Catatan itu menukar aduan kabur menjadi laporan yang boleh diambil tindakan oleh seseorang.

Artikel berkaitan