Adakah trafik benar-benar melalui VPN? Cara mengesahkannya
Carian laluan, hop pertama, tangkapan pada penyesuai fizikal dan semakan alamat dari luar masing-masing menjawab bahagian berbeza soalan.
Dua kegagalan kelihatan sama dari ikon dulang sistem: trafik yang masuk ke terowong dan trafik yang memutarnya secara senyap. Klien menunjukkan Connected dalam kedua-dua kes, kerana Connected hanya bermaksud antara muka terowong wujud dan klien telah memasang laluan yang dikehendakinya. Sama ada satu paket daripada satu aplikasi menggunakan laluan itu ialah soalan berasingan, yang dijawab di tempat lain dalam tindanan. Empat ukuran menyelesaikan sebahagian besarnya — carian laluan, hop pertama, tangkapan pada penyesuai fizikal dan pemerhatian dari luar — dan paparan sesi pada pelayan meliputi selebihnya.
Mulakan dengan laluan yang akan diambil paket
Jadual penghalaan ialah keputusannya, jadi tanyalah tentang satu destinasi dan bukan membaca keseluruhannya lalu meneka. Pada Linux, ip route get menamakan antara muka dan alamat sumber yang dipilih kernel:
ip route get 203.0.113.10
ip route get 10.20.5.7Pada Windows, Find-NetRoute -RemoteIPAddress 203.0.113.10 lebih berguna daripada route print -4 atas sebab yang sama: ia melaporkan laluan yang menang, bukan semua laluan yang wujud. Namun bacalah jadual itu sekali kerana baris 0.0.0.0-nya. Pasangan /1 di situ bermakna klien terowong penuh telah menulis semula laluan lalai: pilihan redirect-gateway def1 OpenVPN memasang 0.0.0.0/1 dan 128.0.0.0/1 melalui terowong, yang mengalahkan 0.0.0.0/0 sedia ada pada padanan awalan terpanjang tanpa memadam laluan lalai fizikal. Itulah sebabnya dua laluan lalai boleh wujud bersama sementara semuanya masih masuk ke terowong.
Dua butiran menjadikan jadual itu pembohong. Pertama, lihat awalan yang padan dan bukan bilangan laluan lalai, kerana metrik antara muka atau pasangan /1 menentukan pemenang. Kedua, sambungan yang sudah wujud mengekalkan laluan ia ditubuhkan; selepas terowong naik, sesi terbuka mungkin terus menggunakan laluan lama sehingga ia diset semula, dan itulah sebabnya menyambung semula kelihatan membaiki masalah penghalaan. Klien yang berjalan — ps ax | grep openvpn — hanya membuktikan proses itu bermula.
Jejaki satu nama dalaman dan satu nama awam
Carian laluan menunjukkan niat; laluan menunjukkan penyampaian. Semasa bersambung, jejaki nama yang mesti dalaman dan nama yang tidak sepatutnya, dan bandingkan hop pertama:
traceroute intranet.corp.example
traceroute 1.1.1.1Hop pertama yang sama untuk kedua-duanya bermakna nama dalaman tidak pernah masuk ke terowong dan kerosakan terletak di atasnya, biasanya nama yang menyelesaikan kepada alamat awam atau laluan yang tidak pernah dipasang. Jika trafik dalaman keluar melalui 10.8.0.1 manakala trafik awam keluar melalui 192.168.1.1, terowong terpisah melakukan tepat apa yang dikonfigurasikan. Jejak yang sampai ke gerbang VPN dan kemudian hanya memulangkan tamat masa biasanya masalah laluan balik atau tembok api pelayan, bukan laluan penghantaran yang hilang.
ICMP yang ditapis membuatkan semakan ini pembohong: bintang pada kedua-dua jejak kelihatan seperti terowong mati dan biasanya ia tembok api. Uji port TCP di mana anda boleh — traceroute -T -p 443 pada Linux — dan ingat jejak tidak menyatakan penyelesai mana yang menjawab: nama boleh diselesaikan secara setempat dan masih boleh dicapai melalui terowong.
Tangkap pada penyesuai fizikal, bukan pada terowong
Pautan fizikal ialah satu-satunya tempat yang menunjukkan apa yang rangkaian benar-benar lihat. Dengan terowong naik, sesi ke pejabat sepatutnya muncul sebagai muatan disulitkan yang dialamatkan kepada pelayan VPN, bukan sebagai sambungan ke 10.20.5.7:
sudo tcpdump -ni eth0 udp port 53
sudo tcpdump -ni eth0 host 10.20.0.5Penapis pertama menangkap penyelesaian nama yang keluar secara setempat, iaitu kebocoran paling biasa dan paling senyap — halaman masih dimuatkan, penyelesai hanya melihat pertanyaan itu. Yang kedua menangkap trafik biasa ke alamat dalaman yang sepatutnya wujud hanya di dalam terowong. Pada Windows, pktmon melakukan kerja yang sama tanpa pemacu: pktmon filter add -p 53, kemudian pktmon start --capture --pkt-size 128, kemudian pktmon stop dan pktmon format pktmon.etl -o capture.txt. Bendera ini berbeza sedikit antara binaan Windows, jadi semak pktmon filter add /? sebelum mempercayai sintaksnya.
Tangkap antara muka fizikal untuk mencari kebocoran; tangkapan pada terowong mengandungi paket yang anda sudah percaya ada di situ, dan pada pelayan ia mengandungi paket luar yang tidak boleh dibaca yang sumbernya ialah gerbang. Pembilang bait pada mana-mana antara muka menerangkan paket, bukan program; untuk mengaitkan trafik dengan proses diperlukan pemantau yang memetakan soket kepada proses.
Tanya perkhidmatan luar, kemudian tanya semula bagi setiap aplikasi
Satu-satunya semakan yang membuktikan jalan keluar ialah jawapan dari luar: perkhidmatan yang menggemakan alamat sumber yang dilihatnya. Jalankannya dari shell, di mana anda boleh memilih antara muka, dan jalankannya dua kali:
sudo curl --interface tun0 https://example.net/ip
sudo curl --interface eth0 https://example.net/ipJawapan berbeza memberi anda bukti kedua-dua laluan dan cara menguji aplikasi tertentu: ikatkannya, atau jalankannya dalam ruang nama rangkaian dengan satu laluan, dan lihat alamat mana yang dicatat hujung jauh. Jawapan serupa ialah kegagalan yang menarik: sama ada pengikatan tidak berkesan, atau sesuatu antara hos dan hujung jauh menulis semula alamat sumber sebelum ia tiba. Pada Windows, curl --interface mahukan alamat penyesuai dan bukan namanya.
Pelayar yang melaporkan alamat VPN membuktikan pelayar itu. Klien mel, pengurus pakej, agen sandaran atau profil pelayar kedua masing-masing boleh mengambil laluan berbeza, terutamanya apabila tetapan proksi atau laluan terowong terpisah meliputi salah satunya. Perubahan alamat bukan bukti kebocoran dengan sendirinya: pengimbang beban boleh menjawab secara berbeza bergantung pada keluar yang dilihatnya, jadi bandingkan alamat sumber yang direkodkan, bukan halaman.
Gunakan paparan pelayan untuk mengesahkan rakan setara
Pelayan menjawab soalan lain: sama ada rakan setara bersambung, berapa banyak yang telah dibawanya dan sama ada sesi dimulakan semula. Rakan setara yang aktif pada pelayan sementara pembilang klien hampir tidak bergerak bermakna trafik aplikasi tidak masuk ke terowong, apa pun kata jadual klien. Rakan setara yang memindahkan banyak data untuk pengguna yang melaporkan tiada apa berfungsi ialah siasatan lain.
Terdapat dua perangkap di sini. Terowong bertopeng membuatkan setiap aliran kelihatan datang dari gerbang, jadi log dan perakaunan setiap klien runtuh kepada satu alamat. Dan klien dianggap hos setempat, jadi persoalan sama ada seseorang menyalin fail melalui VPN dijawab oleh trafik perkongsian fail pada pelayan atau oleh audit hos pada pelayan — memerhati terowong memberi titik akhir dan isipadu, bukan nama fail.
Bezakan keputusan reka bentuk daripada kebocoran
Bukan semua di luar terowong ialah kebocoran. Trafik pautan-setempat dan siaran kekal setempat mengikut reka bentuk, pencetak yang ditemui melalui multicast terus mengumumkan diri di LAN, dan DHCP mesti keluar secara setempat. Aplikasi yang diikat pada antara muka tertentu memintas jadual penghalaan dengan sengaja, dan hanya peraturan tembok api, ruang nama atau laluan dasar yang mengubahnya.
IPv6 layak mendapat barisnya sendiri dalam senarai semak. Terowong yang hanya membawa IPv4 meninggalkan hos tindanan berganda dengan laluan kedua yang boleh digunakan, dan destinasi tindanan berganda akan mengutamakannya — termasuk DNS, jika penyelesai boleh dicapai melalui IPv6. Lumpuhkan IPv6 pada penyesuai atau pastikan terowong membawanya sebelum menganggap hasil IPv4 lengkap.
Apabila semakan tidak bersetuju, ketidaksetujuan itu biasanya menamakan kerosakannya:
| What you see | What it means | Next step |
|---|---|---|
| The route picks tun0 but the capture shows cleartext to 10.20.5.7 | Something bypassed the table: a bound app, a policy route or a session older than the tunnel | Reset the flow, check the app bind, check the ip rule list |
| The route picks eth0 for an internal name | The name resolves to a public address, or the route was never installed | Compare the resolved address with the routes the server pushes |
| The capture shows DNS to the LAN resolver | Resolver leak: data is tunneled, lookups are not | Point the resolver inside, or push it from the server |
| All four checks agree and one app still fails | Path selection is fine; suspect MTU, a per-app proxy or the far end | Test the same destination from a known-good client |
Susunan yang berkesan: simpan jadual penghalaan sebelum dan selepas bersambung, jejaki satu nama dalaman dan satu nama awam, tangkap DNS pada penyesuai fizikal, gemakan alamat keluar dari shell untuk aplikasi tertentu, kemudian baca pelayan untuk isipadu. Jika empat yang pertama bersetuju, terowong membawa apa yang anda fikirkan dan masalah yang tinggal berada di atasnya. Jika dua daripadanya tidak bersetuju, pasangan yang tidak bersetuju itulah kerosakannya, bukan ikonnya.