Apakah lalu lintas benar-benar lewat VPN? Cara memverifikasinya

Dua kegagalan tampak sama dari ikon baki sistem: lalu lintas yang masuk ke terowongan dan lalu lintas yang diam-diam menghindarinya. Klien menampilkan Connected pada kedua kasus, karena Connected hanya berarti antarmuka terowongan ada dan klien telah memasang rute yang diinginkannya. Apakah satu paket dari satu aplikasi memakai rute itu adalah pertanyaan terpisah, yang dijawab di tempat lain dalam tumpukan. Empat pengukuran menyelesaikan sebagian besarnya — pencarian rute, hop pertama, tangkapan pada adaptor fisik, dan pengamatan dari luar — dan tampilan sesi di server menutupi sisanya.

Mulailah dari rute yang akan diambil paket

Tabel perutean adalah keputusannya, jadi tanyakan tentang satu tujuan alih-alih membaca seluruhnya lalu menebak. Di Linux, ip route get menyebutkan antarmuka dan alamat sumber yang dipilih kernel:

ip route get 203.0.113.10
ip route get 10.20.5.7

Di Windows, Find-NetRoute -RemoteIPAddress 203.0.113.10 lebih berguna daripada route print -4 karena alasan yang sama: ia melaporkan rute yang menang, bukan semua rute yang ada. Tetap bacalah tabelnya sekali untuk baris 0.0.0.0. Sepasang /1 di sana berarti klien terowongan penuh menulis ulang rute bawaan: opsi redirect-gateway def1 OpenVPN memasang 0.0.0.0/1 dan 128.0.0.0/1 melalui terowongan, yang mengalahkan 0.0.0.0/0 yang ada pada pencocokan prefiks terpanjang tanpa menghapus rute bawaan fisik. Itu sebabnya dua rute bawaan dapat hidup berdampingan sementara semuanya tetap masuk ke terowongan.

Dua detail membuat tabel itu berbohong. Pertama, lihat prefiks yang cocok, bukan jumlah rute bawaan, karena metrik antarmuka atau sepasang /1 menentukan pemenangnya. Kedua, koneksi yang sudah ada mempertahankan jalur saat ia dibentuk; setelah terowongan naik, sesi terbuka dapat terus memakai rute lama sampai direset, dan itulah sebabnya menyambung ulang tampak memperbaiki masalah perutean. Klien yang berjalan — ps ax | grep openvpn — hanya membuktikan bahwa prosesnya dimulai.

Lacak satu nama internal dan satu nama publik

Pencarian rute menunjukkan niat; jalur menunjukkan pengiriman. Saat terhubung, lacak nama yang harus internal dan nama yang tidak boleh, lalu bandingkan hop pertama:

traceroute intranet.corp.example
traceroute 1.1.1.1

Hop pertama yang sama untuk keduanya berarti nama internal tidak pernah masuk ke terowongan dan kesalahannya ada di atasnya, biasanya nama yang beresolusi ke alamat publik atau rute yang tidak pernah dipasang. Jika lalu lintas internal keluar lewat 10.8.0.1 sementara lalu lintas publik keluar lewat 192.168.1.1, terowongan terpisah melakukan tepat apa yang dikonfigurasikan. Jejak yang mencapai gerbang VPN lalu hanya mengembalikan batas waktu biasanya masalah jalur balik atau firewall server, bukan rute penerusan yang hilang.

ICMP yang difilter membuat pemeriksaan ini berbohong: bintang di kedua jejak tampak seperti terowongan mati dan biasanya itu firewall. Uji porta TCP di tempat yang memungkinkan — traceroute -T -p 443 di Linux — dan ingat jejak tidak mengatakan resolver mana yang menjawab: nama bisa beresolusi lokal dan tetap dapat dijangkau lewat terowongan.

Tangkap pada adaptor fisik, bukan pada terowongan

Tautan fisik adalah satu-satunya tempat yang menunjukkan apa yang sebenarnya dilihat jaringan. Dengan terowongan naik, sesi ke kantor seharusnya muncul sebagai muatan terenkripsi yang dialamatkan ke server VPN, bukan sebagai koneksi ke 10.20.5.7:

sudo tcpdump -ni eth0 udp port 53
sudo tcpdump -ni eth0 host 10.20.0.5

Filter pertama menangkap resolusi nama yang keluar secara lokal, yang merupakan kebocoran paling umum dan paling senyap — halaman tetap dimuat, resolver hanya melihat kuerinya. Yang kedua menangkap lalu lintas biasa ke alamat internal yang seharusnya hanya ada di dalam terowongan. Di Windows, pktmon melakukan pekerjaan yang sama tanpa driver: pktmon filter add -p 53, lalu pktmon start --capture --pkt-size 128, lalu pktmon stop dan pktmon format pktmon.etl -o capture.txt. Flag itu sedikit berbeda antarversi Windows, jadi periksa pktmon filter add /? sebelum mempercayai sintaksnya.

Tangkap antarmuka fisik untuk menemukan kebocoran; tangkapan pada terowongan berisi paket yang sudah Anda yakini ada di sana, dan pada server berisi paket luar yang tidak terbaca yang sumbernya adalah gerbang. Penghitung bita pada antarmuka mana pun menjelaskan paket, bukan program; untuk mengaitkan lalu lintas dengan proses diperlukan pemantau yang memetakan soket ke proses.

Tanyakan pada layanan luar, lalu tanyakan lagi per aplikasi

Satu-satunya pemeriksaan yang membuktikan jalan keluar adalah jawaban dari luar: layanan yang menggemakan alamat sumber yang dilihatnya. Jalankan dari shell, di mana Anda dapat memilih antarmuka, dan jalankan dua kali:

sudo curl --interface tun0 https://example.net/ip
sudo curl --interface eth0 https://example.net/ip

Jawaban berbeda memberi Anda bukti kedua jalur dan cara menguji aplikasi tertentu: ikat aplikasi itu, atau jalankan di ruang nama jaringan dengan satu rute, lalu lihat alamat mana yang dicatat ujung jauh. Jawaban identik adalah kegagalan yang menarik: entah pengikatan tidak berlaku, atau sesuatu antara host dan ujung jauh menulis ulang alamat sumber sebelum tiba. Di Windows, curl --interface menginginkan alamat adaptor, bukan namanya.

Peramban yang melaporkan alamat VPN membuktikan peramban itu. Klien surel, manajer paket, agen cadangan, atau profil peramban kedua dapat masing-masing mengambil jalur berbeda, terutama ketika pengaturan proksi atau rute terowongan terpisah menutupi salah satunya. Perubahan alamat bukan bukti kebocoran dengan sendirinya: penyeimbang beban dapat menjawab berbeda tergantung jalan keluar yang dilihatnya, jadi bandingkan alamat sumber yang tercatat, bukan halamannya.

Gunakan tampilan server untuk mengonfirmasi peer

Server menjawab pertanyaan lain: apakah peer terhubung, berapa banyak yang telah diangkut, dan apakah sesinya dimulai ulang. Peer yang aktif di server sementara penghitung klien hampir tidak bergerak berarti lalu lintas aplikasi tidak masuk ke terowongan, apa pun kata tabel klien. Peer yang memindahkan banyak data bagi pengguna yang melaporkan tidak ada yang berfungsi adalah penyelidikan lain.

Ada dua jebakan di sini. Terowongan bertopeng membuat setiap aliran tampak berasal dari gerbang, sehingga log dan pembukuan per klien runtuh ke satu alamat. Dan klien diperlakukan sebagai host lokal, sehingga pertanyaan apakah seseorang menyalin berkas lewat VPN dijawab oleh lalu lintas berbagi berkas di server atau oleh audit host di server — mengamati terowongan memberi titik akhir dan volume, bukan nama berkas.

Bedakan keputusan desain dari kebocoran

Tidak semua yang di luar terowongan adalah kebocoran. Lalu lintas tautan-lokal dan siaran tetap lokal secara desain, printer yang ditemukan lewat multicast terus mengumumkan diri di LAN, dan DHCP harus keluar secara lokal. Aplikasi yang diikat ke antarmuka tertentu sengaja melewati tabel perutean, dan hanya aturan firewall, ruang nama, atau rute kebijakan yang mengubahnya.

IPv6 layak mendapat barisnya sendiri dalam daftar periksa. Terowongan yang hanya membawa IPv4 meninggalkan host tumpukan ganda dengan jalur kedua yang bisa dipakai, dan tujuan tumpukan ganda akan memilihnya — termasuk DNS, jika resolver dapat dijangkau lewat IPv6. Nonaktifkan IPv6 pada adaptor atau pastikan terowongan membawanya sebelum menganggap hasil IPv4 sudah lengkap.

Ketika pemeriksaan tidak sepakat, ketidaksepakatan itu biasanya menamai kesalahannya:

Urutan yang berhasil: simpan tabel perutean sebelum dan sesudah terhubung, lacak satu nama internal dan satu nama publik, tangkap DNS pada adaptor fisik, gemakan alamat keluar dari shell untuk aplikasi tertentu, lalu baca server untuk volume. Jika empat yang pertama sepakat, terowongan membawa apa yang Anda pikirkan dan masalah yang tersisa ada di atasnya. Jika dua di antaranya tidak sepakat, pasangan yang tidak sepakat itulah kesalahannya, bukan ikonnya.