Membaiki putus VPN semasa melahu: senarai semak penjimatan kuasa Wi-Fi

Terowong anda mati selepas komputer riba dibiarkan tanpa disentuh untuk seketika, dan ia kembali pada saat anda menyentuh pad jejak. Corak ini menunjukkan pautan wayarles masuk ke mod penjimatan kuasa, bukan bahawa get laluan VPN menolak kelayakan anda. Pagi yang sibuk pada profil yang sama ialah buktinya: terowong bertahan selagi trafik mengalir dan gagal apabila radio menjadi senyap. Lakukan pemeriksaan di bawah mengikut urutan, berhenti pada yang pertama gagal, dan hanya kemudian tukar satu tetapan.

Pemeriksaan satu: adakah putus mengikut masa melahu?

Mulakan dengan membuktikan korelasi dan bukannya menganggapnya. Catat masa jam dinding paket terakhir yang anda hantar, masa klien melaporkan terowong turun, dan sama ada skrin terpadam dalam tempoh itu. Jika jurangnya sama setiap kali, anda mempunyai masalah pada laluan melahu; jika putus berlaku secara rawak semasa penggunaan aktif, lompat ke pemeriksaan lima.

Ujian murah yang tidak rugi untuk dibatalkan: hantar ping mantap berkadar rendah ke get laluan anda selama dua puluh minit dan biarkan mesin itu bersendirian. Jika terowong bertahan sepanjang ujian, trafik kecil yang berterusan menyembunyikan gejala dan bukannya membaikinya, yang masih bukti berguna. Saya menyimpan output ping itu dalam terminal draf dan membandingkannya dengan log klien selepas itu, kerana kedua-dua jam jarang bersetuju.

Pemeriksaan dua: adakah ia hanya trafik VPN?

Sebelum menyalahkan terowong, ketahui sama ada pautan itu sendiri masih boleh digunakan. Semasa terowong mati tetapi skrin masih terpadam, cuba capai alamat titik akses dan hos awam melalui IP. Jika ping biasa juga gagal, radio atau titik akses telah melepaskan anda, dan klien VPN hanyalah penonton.

Jika trafik biasa mengalir sementara terowong senyap, pautan itu sihat dan masalahnya terletak pada pemasa terowong itu sendiri atau pada cara klien mengendalikan penyambungan semula. Itu dua pembaikan berbeza, jadi jangan langkau langkah ini. Pada komputer riba dengan Wi-Fi dan Ethernet sekali, cabut kabel dan ulang ujian melahu: putus melahu yang hilang pada Ethernet berkabel ialah bukti kuat untuk lapisan wayarles.

Pemeriksaan tiga: baca keadaan penjimatan kuasa

Kebanyakan desktop memberi anda kotak semak, tetapi kotak itu bukan keadaan pemacu sebenarnya. Baca laporan pemacu itu sendiri dahulu, kemudian putuskan. Pada Linux dengan mac80211 antara muka menjawab terus:

iw dev wlan0 get power_save          # on or off, per interface
sudo iw dev wlan0 set power_save off # diagnostic only, lost on reconnect

Perintah kedua ialah ujian, bukan pembaikan. Ia tidak bertahan selepas pemutusan, tidur atau but semula, yang menjadikannya cara bersih untuk menguji hipotesis tanpa meninggalkan perubahan kekal.

Pada Windows powercfg /q SCHEME_CURRENT mencetak skema aktif, dan subpokok penyesuai wayarles menunjukkan sama ada penyesuai boleh diperintahkan menjimatkan kuasa; pilihan yang sama juga ada dalam Device Manager pada tab pengurusan kuasa penyesuai. Pada macOS penjimatan kuasa 802.11 bagi setiap antara muka tidak didedahkan kepada anda, jadi lihat sebaliknya pmset -g untuk tingkah laku tidur dan sedia. Di situ kegagalan biasanya terbukti sebagai laluan tidur dan bangun dan bukan tingkah laku melahu radio.

Pemeriksaan empat: tukar satu perkara, kemudian uji semula

Tukar tepat satu pemboleh ubah setiap larian dan ulang beban kerja yang sama. Jika terowong kini bertahan sejam melahu dengan penjimatan kuasa dimatikan, anda telah mempelajari sesuatu yang nyata. Jika ia masih gagal, kembalikan sebelum menguji idea seterusnya, jika tidak anda berakhir dengan tiga tetapan bertindih dan tiada idea yang mana penting.

Mengekalkan sambungan hidup ialah pemboleh ubah bebas yang lain dan ia sentiasa dikelirukan dengan penjimatan kuasa. Nilai PersistentKeepalive = 25 WireGuard memastikan pemetaan NAT kekal hangat;OpenVPN di kedua-dua hujung keepalive dan ping-restart menggunakan. Kedua-duanya menjana trafik pada terowong yang sebaliknya senyap, jadi pengekalan hidup yang kelihatan membaiki putus itu mungkin menyembunyikan masalah radio dan bukannya menyelesaikannya. Uji kedua-duanya secara berasingan, satu demi satu:

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
PersistentKeepalive = 25

Pemeriksaan lima: apabila radio tidak bersalah

Jika putus melahu berterusan dengan penjimatan kuasa dimatikan dan pengekalan hidup dihidupkan, lihat di luar komputer riba. Titik akses dan penghala rumah membiarkan entri NAT atau sesi melahu luput mengikut jadual mereka sendiri, dan pelayan VPN boleh menggugurkan sesi tanpa trafik.Perayauan antara titik akses yang berkongsi SSID yang sama juga boleh menetapkan semula pautan tanpa klien menyatakannya dengan jelas.

Kemudian bandingkan dengan peranti kedua pada rangkaian yang sama yang melakukan ujian melahu yang sama. Dua peranti gagal pada selang yang sama ialah kisah laluan atau pelayan; satu peranti gagal ialah kisah pemacu atau kuasa setempat. Perbandingan itu mengambil masa sepuluh minit dan menyelamatkan anda daripada menulis semula konfigurasi yang salah.

Sebelum menjadikannya kekal

Putuskan apa yang anda sanggup kekalkan. Skrip setiap profil yang mematikan penjimatan kuasa hanya pada rangkaian tempat anda melihat putus itu boleh dipertahankan. Pelarasan global yang mematikan segala-galanya dengan bayaran hayat bateri pada setiap rangkaian biasanya bukan.

• Catat nilai penjimatan kuasa asal di sebelah skrip supaya ia boleh dipulihkan.
• Ulang ujian melahu selepas setiap kemas kini pemacu atau klien; nilai lalai berubah.
• Simpan log ping dan log klien bersama apabila anda melaporkan masalah itu.
• Jika langkah dua gagal, berhenti menukar tetapan VPN dan anggap ia kerosakan pautan setempat.

Jika anda hanya melakukan satu perkara, lakukan pemeriksaan dua. Itulah yang menentukan sama ada baki senarai ini terpakai kepada anda sama sekali, dan itulah langkah yang orang langkau selepas mereka sudah memutuskan jawapannya ialah penjimatan kuasa.