Klien hotspot baru yang macet di «Mendapatkan IP» bukan kerusakan VPN

Ponsel bergabung ke hotspot, berhenti di «Mendapatkan alamat IP», dan akhirnya menyerah. Kesimpulan alaminya adalah VPN ponsel mengganggu DNS, sehingga orang mulai mengedit resolver dan aturan tambahan. Itu tahap yang salah. Klien tidak pernah menerima alamat lokal, dan tanpa itu ia tidak punya gateway, tidak punya resolver, dan tidak ada yang bisa diteruskan, jadi tidak ada pengaturan VPN di ponsel host yang bisa menjelaskan kegagalan itu. Asosiasi, penetapan alamat lokal, dan penerusan adalah tiga tahap terpisah, dan hanya tahap terakhir yang melibatkan terowongan.

Tiga tahap itu, dan Anda ada di tahap mana

Asosiasi datang lebih dulu: klien bergabung ke jaringan nirkabel hotspot. Kata sandi yang salah, ketidakcocokan WPA3, atau masalah kompatibilitas radio gagal di sini, dan klien biasanya mengatakannya. Penetapan alamat datang kedua: untuk IPv4 klien meminta sewa dan menerima alamat plus pengaturan gateway lokal, sedangkan IPv6 biasanya memakai pengumuman router alih-alih DHCP, seperti yang dijelaskan dokumentasi tethering AOSP. Akses ke luar datang ketiga: ponsel host meneruskan lalu lintas yang diizinkan ke jalur hulu yang dipilihnya, yang mungkin atau mungkin bukan terowongannya.

Kata-kata di klien memberi tahu Anda tahapnya. Macet saat mendapatkan alamat adalah tahap dua, sebelum ada paket yang keluar ke internet. Tersambung, punya alamat, tetapi tidak ada yang termuat adalah tahap tiga, tempat perutean, nama, dan cakupan terowongan semuanya penting. Mendiagnosis tahap tiga saat klien macet di tahap dua adalah cara masalah sewa lima menit menjadi sore penuh pengeditan DNS.

Mitos: VPN yang dirutekan mengubah DHCP lokal menjadi permintaan jarak jauh

Terowongan yang dirutekan memindahkan paket IP untuk tujuan yang dipilihnya. Penemuan DHCP adalah siaran di segmen hotspot itu sendiri, dan layanan tethering di ponsel menjawabnya secara lokal, itulah sebabnya klien bisa mendapatkan alamat saat terowongan aktif. Hanya desain yang sengaja dijembatani atau diteruskan ulang yang mengirim pertukaran itu ke tempat lain, dan itu pengaturan berbeda dengan tanda kegagalan berbeda.

Jadi «server VPN tidak menjawab DHCP» bukan diagnosis, melainkan kesalahan model. Perantara lokal ada di ponsel. Jika ia berhenti menjawab, alasannya lokal: layanan tethering, batas klien, kumpulan sewa, atau klien yang tidak pernah menyelesaikan asosiasi dengan benar. Tidak satu pun dari itu berada di sisi jauh terowongan.

Apa yang sebenarnya dibuktikan klien lama yang berfungsi

Jika laptop yang sudah tersambung masih berfungsi sementara ponsel baru tidak, hotspot dan jalur hulu secara umum hidup. Perbandingan itu berguna dan bukan bukti komponen mana yang bersalah, karena klien yang berfungsi mungkin hanya memegang sewa dari sebelum perubahan dan memperbaruinya diam-diam.

Dua batas lokal layak diperiksa selagi Anda di sana. Hotspot melayani kumpulan sewa terbatas dan batas klien yang dapat dikonfigurasi, jadi perangkat yang bergabung lalu tidur dapat memegang alamat sementara perangkat baru menunggu. Dan klien yang mengingat konfigurasi statis dari jaringan lain tidak akan meminta sewa sama sekali, yang dari luar terlihat identik dan diperbaiki di klien, bukan di ponsel.

Jaga perbandingan tetap lokal dan dapat dibalik

Pada perangkat yang kebijakannya mengizinkan, bandingkan satu penyambungan klien baru dengan terowongan nonaktif lalu aktif, dengan hotspot dan klien selebihnya tidak berubah. Catat versi ponsel dan klien, profil yang dipilih, dan tahap tepat yang gagal. Pada ponsel terkelola, minta perbandingan yang disetujui alih-alih mematikan penegakan demi pengujian yang lebih bersih.

Kegagalan sewa yang konsisten dan bergantung pada terowongan adalah bukti berguna tentang kebijakan lokal atau interaksi implementasi. Itu bukan lisensi untuk membersihkan setiap aturan penerusan dan NAT di perangkat. Aturan itu melindungi lalu lintas tak terkait, dan penerimaan penerusan yang luas tidak menjelaskan mengapa layanan DHCP lokal berhenti menjawab.

Jangan menutupi sewa yang hilang dengan alamat statis tebakan. Konfigurasi statis yang disengaja membutuhkan subnet sebenarnya, gateway, rencana alokasi, dan pemeriksaan tabrakan. Mengubah DNS klien tidak menyediakan satu pun dari itu, dan ia meninggalkan perangkat berikutnya dengan kegagalan yang sama.

Apa yang tidak dibuktikan sewa

Mendapatkan alamat membuktikan penerimaan ke jaringan lokal, bukan perlindungan oleh terowongan ponsel. Setelah klien memegang sewa, evaluasi jalur hilir sendiri: apakah lalu lintas klien benar-benar melewati ponsel, apakah pencarian terurai di tempat yang Anda harapkan, dan apakah alamat luar cocok dengan jalan keluar yang Anda maksud? Itu pertanyaan tahap tiga dan layak mendapat pengujian sendiri alih-alih dilipat ke dalam penyambungan.

Kerjakan tahapannya berurutan dan kegagalan berhenti berpindah. Klien yang macet saat mendapatkan alamat adalah pertanyaan tethering lokal; klien dengan alamat tetapi tanpa halaman adalah pertanyaan penerusan atau penamaan; klien dengan halaman tetapi jalan keluar salah adalah pertanyaan cakupan terowongan. Menjaga semuanya terpisah adalah sebagian besar dari debugging.