Di mana memantau trafik klien OpenVPN pada get laluan

Anda ingin tahu destinasi mana yang dicapai oleh klien yang bersambung, jadi anda membuka shell pada pelayan VPN dan menaip ss. Tiada apa yang berguna muncul, dan kesimpulan bahawa terowong rosak datang sedikit terlalu mudah. Get laluan OpenVPN berpenghalaan memajukan paket klien; ia tidak menamatkan sambungan TCP mereka dan tidak memiliki soket untuknya. Bukti hidup di tempat lain, dan tempat itu bergantung pada cara trafik dikendalikan selepas ia meninggalkan terowong.

Tentukan susunan mana yang anda lihat

Dua bentuk lazim menghasilkan bukti yang sama sekali berbeza. Get laluan penghalaan menyahkapsul, memajukan dan mungkin melakukan NAT sumber, jadi sambungan klien terus wujud dari hujung ke hujung tanpa soket setempat.

Proksi menamatkan trafik: ia menerima sambungan, kemudian membuka sambungan hulunya sendiri. Dalam susunan itu terdapat dua sambungan untuk satu permintaan, dan kaitan antara keduanya hanya wujud dalam rekod proksi itu sendiri. Mengetahui yang mana antara keduanya anda gunakan menentukan sama ada anda perlu membaca keadaan aliran kernel atau log aplikasi.

Sebahagian besar kekeliruan datang daripada meneka. Sahkan bentuk sebelum memilih alat. Baca konfigurasi pelayan untuk arahan proksi terlebih dahulu, kerana kehadirannya mengubah setiap langkah berikutnya. Tanpanya, laluan paket ialah penghalaan dan keadaan aliran kernel ialah bukti anda.

Ikat alamat pada sesi terlebih dahulu

Mulakan daripada keadaan sesi pelayan dan kenal pasti alamat dalaman semasa klien. Alamat kolam dikitar semula, jadi alamat sahaja ialah pajakan, bukan orang.

Catat masa dan identiti yang disahkan bersama-sama, dan perhatikan sama ada seluruh LAN bersembunyi di sebalik klien itu. Jika hujung jauh menghala subrangkaian, alamat dalaman yang anda lihat mungkin hos asal atau yang diterjemah.

ip -4 addr show dev tun0
journalctl -u [email protected] --since '-10 min' | tail -n 40

Pasangan itu menjawab dua soalan sekali gus: awalan mana yang dilayan oleh antara muka terowong, dan sesi mana yang aktif sepanjang selang yang anda ambil berat. Lakukan ini sebelum mentafsir mana-mana entri aliran, kerana tuple meyakinkan yang terikat pada sesi yang salah lebih buruk daripada tiada bukti sama sekali.

Baca jadual aliran pada get laluan penghalaan

Setelah alamat dan selang ditetapkan, senarai baca-sahaja sambungan yang dijejaki menunjukkan apa yang dimajukan oleh get laluan untuknya. Tapis pada sumber asal supaya anda tidak membaca seluruh jadual.

sudo conntrack -L -p tcp -f ipv4 --orig-src 10.8.0.37

Setiap entri menyimpan dua tuple, asal dan balasan, yang merupakan dua arah satu aliran dan bukan dua aplikasi. Pada laluan NAT sumber, tuple asal mengekalkan alamat terowong manakala sisi balasan menunjukkan alamat get laluan yang diterjemah, dan itulah yang membuatkan output kelihatan salah pada pandangan pertama.

Layan senarai itu sebagai keadaan hidup dan bukan sejarah. Aliran pendek mungkin sudah luput, trafik yang tidak dijejaki tidak pernah muncul, dan ruang nama rangkaian lain menunjukkan jadual lain. Rujukan conntrack mendokumenkan penapis dan output dua arah.

Satu tangkapan terhad untuk mengesahkan bacaan

Jika antara muka terowong kelihatan di tempat anda memandang, satu tangkapan terhad menyelesaikan sama ada paket yang anda kenal pasti ialah yang berada pada wayar. Kekalkan penapis sempit dan had paket kecil.

sudo tcpdump -ni tun0 -nn -c 50 'host 10.8.0.37 and tcp'

Bandingkan cap masa, protokol dan port dengan entri aliran serta dengan permintaan yang anda buat sebagai ujian. Tangkapan yang diambil selepas NAT hanya menunjukkan alamat awam get laluan, manakala sisi terowong mungkin masih menunjukkan alamat klien, dan perbezaan itu ialah maklumat, bukan ketidakselarasan.

Jika antara muka tidak melihat apa-apa, periksa laluan data sebelum membuat kesimpulan bahawa klien melahu: trafik klien-ke-klien dan sesetengah laluan pemunggahan tidak pernah melalui titik yang anda perhatikan.

Log proksi, dan had apa yang anda lihat

Apabila proksi berada di laluan, soket hulunya kelihatan dalam jadual soket tetapi ia tidak memetakan satu-ke-satu kepada klien VPN, terutamanya dengan pengumpulan atau pemultipleksan. Gunakan log transaksi proksi yang dikonfigurasikan untuk mengaitkan identiti klien, destinasi, cap masa dan apa-apa pengecam permintaan yang direkodkannya.

Periksa konfigurasi pengelogan versi yang digunakan dan bukannya menganggap setiap permintaan dilog secara lalai.

Akhir sekali, tepatlah tentang skop. Alamat destinasi dan port ialah metadata, bukan URL dan bukan kandungan halaman, kerana sesi HTTPS dalaman mengekalkan perlindungannya sendiri tanpa mengira terowong. Laporkan apa yang anda perhatikan, dari titik pemerhatian mana, dan pada masa apa.