VPN bersambung tetapi alamat IP tidak berubah: mengapa
Tunel aktif dan ujian alamat masih memaparkan IP lama anda. Ukur IPv4 dan IPv6 secara berasingan, kemudian semak tunel berpecah, skop setiap aplikasi dan laluan proksi.
Anda bersambung, klien berkata bersambung, dan ujian alamat masih memaparkan nombor yang sama seperti sebelum ini. Tiada apa-apa yang salah dengan penunjuk; sesuatu antara profil dan aplikasi mengekalkan permintaan itu di luar tunel. Tentukan yang mana antara tiga perkara yang anda lihat sebelum menyentuh sebarang konfigurasi: ujian yang tidak pernah mengukur alamat awam, tunel yang hanya meliputi sebahagian trafik, atau laluan kedua yang memenangi keputusan penghalaan. Setiap satu mempunyai satu semakan yang mengambil masa kurang daripada satu minit.
Pastikan apa yang sebenarnya diukur oleh ujian
Alamat yang dipaparkan dalam dialog Wi-Fi atau Ethernet ialah alamat antara muka pada segmen anda sendiri, bukan alamat yang dilihat oleh laman web, jadi ia boleh kekal sama semasa tunel berfungsi dengan sempurna. Lokasi pula isyarat berasingan: wilayah akaun tersimpan atau bacaan geolokasi yang dibenarkan tidak bergerak apabila anda menukar exit, dan log masuk yang sudah mengenali anda juga tidak.
Gunakan gema alamat awam dan tanya setiap keluarga secara berasingan, kerana keputusan ujian tindanan berganda menyembunyikan kes yang menarik:
curl -4 -s https://ifconfig.me
curl -6 -s https://ifconfig.me
Jalankan kedua-duanya sebelum dan selepas bersambung. Jika jawapan IPv4 berubah kepada alamat exit dan jawapan IPv6 tidak, anda tidak mempunyai tunel rosak; satu keluarga bergerak di luarnya. Jika kedua-dua jawapan kekal sama, permintaan itu tidak pernah sampai ke tunel dan selebihnya di sini terpakai.
Profil mungkin hanya meliputi sebahagian trafik
Profil tunel berpecah ialah jawapan biasa, dan ia bukan kecacatan. OpenVPN menghantar segala-galanya melalui tunel hanya apabila redirect-gateway ada dalam pilihan yang ditolak; tanpanya klien menerima beberapa laluan khusus dan laluan lalai anda kekal pada pautan fizikal. Pada Windows suis yang sama muncul sebagai „Gunakan gateway lalai pada rangkaian jauh“ dalam sifat IPv4 penyesuai, dan menyah tandanya ialah pilihan sedar yang kekal selepas setiap sambungan semula.
Skop setiap aplikasi ialah lapisan kedua. Tetapan VPN setiap aplikasi Android menentukan aplikasi mana yang disertakan, jadi kunci VPN dalam bar status tidak membuktikan pelayar berada di dalamnya. Sambungan pelayar yang memproksi trafiknya sendiri mencipta imej cermin: pelayar memaparkan alamat exit manakala klien mel atau permainan pada mesin yang sama masih memaparkan alamat anda. Bandingkan permintaan yang sama dalam dua aplikasi. Jika satu berubah dan yang lain tidak, anda melihat skop, bukan tunel yang gagal.
Satu keluarga alamat masih boleh pergi terus
Kebanyakan profil VPN ditulis untuk IPv4, dan banyak masih begitu. Pada rangkaian tindanan berganda tunel mengambil 10.8.0.x untuk IPv4 manakala pautan fizikal mengekalkan alamat IPv6 global dan laluan lalai, jadi laman yang menyokong IPv6 dicapai secara terus dan alamat yang dilaporkannya ialah milik pembekal anda. Itu kebocoran dengan tunel IPv4 yang berfungsi, dan ia tidak kelihatan kepada ujian yang hanya bertutur IPv4.
ip -4 route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111
Baca antara muka dalam setiap jawapan. Jika carian IPv6 menamakan peranti Ethernet atau Wi-Fi anda manakala carian IPv4 menamakan tunel, dasar untuk keluarga itu tiada, bukan rosak. Mematikan IPv6 pada seluruh peranti membuat gejala hilang dan menyembunyikan keputusan; lebih baik betulkan liputan profil atau lumpuhkan keluarga itu hanya pada sambungan tersebut, dan catat yang mana antara kedua-duanya yang anda pilih.
Laluan kedua boleh memenangi carian
Proksi pesaing, klien VPN kedua, penyesuai maya daripada kontena atau alat desktop jauh, atau laluan tambahan untuk awalan tepat yang anda uji semuanya boleh mendapat keutamaan. Laluan khusus sentiasa mengalahkan laluan lalai, jadi /24 sisa untuk laman yang anda ukur, yang menunjuk ke gateway LAN anda, terus menghantar trafik itu ke luar tunel sebaik apa pun keadaan tunel.
Buat inventori sebelum mengubah apa-apa, dengan arahan baca sahaja:
route print -4
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
nmcli connection show --active
Cari lebih daripada satu laluan lalai dengan metrik yang munasabah, dan laluan khusus yang meliputi destinasi. Dalam pelayar, semak juga sama ada sambungan proksi atau tetapan proksi sistem memiliki sambungan itu; sambungan boleh menamakan huluan sendiri dan membiarkan exit sistem pengendalian tidak tersentuh, yang menghasilkan alamat berbeza dalam pelayar berbanding terminal pada mesin yang sama.
Ukur semula dengan permintaan baharu
Sambung semula, kemudian ulangi pengukuran dari aplikasi yang sama yang anda uji kali pertama, kerana halaman yang dicache atau sambungan yang digunakan semula melaporkan keadaan lama. Perhatikan log atau paparan peristiwa klien semasa bersambung: ralat semasa menggunakan laluan selepas pengesahan ialah bukti yang lebih kuat daripada sebarang penunjuk, dan ia biasanya menamakan laluan atau penyesuai yang gagal.
Simpan dua hasil secara berasingan. Jika alamat berubah tetapi satu laman masih menolak anda, tunel berfungsi dan laman menolak alamat pusat data; itu masalah lain dengan jawapan lain. Jika alamat tidak pernah berubah, lakukan empat soalan mengikut urutan: alamat mana yang dicetak oleh ujian, keluarga mana ia, aplikasi mana yang membuat permintaan, dan laluan mana yang diikuti permintaan itu. Dokumentasi Microsoft tentang keputusan penghalaan VPN menerangkan bagaimana klien Windows memilih antara tunel dan penyesuai fizikal apabila kedua-duanya mempunyai laluan.