Di mana memantau lalu lintas klien OpenVPN di gateway

Anda ingin tahu tujuan mana yang dicapai klien yang terhubung, jadi Anda membuka shell di server VPN dan mengetik ss. Tidak ada yang berguna muncul, dan kesimpulan bahwa terowongan rusak datang sedikit terlalu mudah. Gateway OpenVPN yang merutekan meneruskan paket klien; gateway itu tidak mengakhiri koneksi TCP mereka dan tidak memiliki soket untuknya. Bukti hidup di tempat lain, dan tempat itu bergantung pada bagaimana lalu lintas ditangani setelah keluar dari terowongan.

Tentukan susunan mana yang Anda lihat

Dua bentuk umum menghasilkan bukti yang sangat berbeda. Gateway perutean melakukan dekapsulasi, meneruskan, dan mungkin melakukan NAT sumber, sehingga koneksi klien tetap ada dari ujung ke ujung tanpa soket lokal.

Proksi mengakhiri lalu lintas: ia menerima koneksi, lalu membuka koneksi hulunya sendiri. Dalam susunan itu ada dua koneksi untuk satu permintaan, dan kaitan di antara keduanya hanya ada dalam catatan proksi itu sendiri. Mengetahui mana dari keduanya yang Anda pasang menentukan apakah Anda harus membaca status aliran kernel atau log aplikasi.

Sebagian besar kebingungan datang dari menebak. Pastikan bentuknya sebelum memilih alat. Baca konfigurasi server untuk direktif proksi lebih dahulu, karena kehadirannya mengubah setiap langkah berikutnya. Tanpanya, jalur paket adalah perutean dan status aliran kernel adalah bukti Anda.

Ikat alamat ke sesi terlebih dahulu

Mulailah dari status sesi server dan kenali alamat dalam yang sekarang dipakai klien. Alamat dari kumpulan didaur ulang, jadi alamat sendirian adalah sewa, bukan orang.

Catat waktu dan identitas yang terautentikasi bersama-sama, dan perhatikan apakah seluruh LAN bersembunyi di balik klien itu. Jika ujung jauh merutekan subnet, alamat dalam yang Anda lihat mungkin host asli atau yang diterjemahkan.

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

Pasangan itu menjawab dua pertanyaan sekaligus: prefiks mana yang dilayani antarmuka terowongan, dan sesi mana yang aktif selama interval yang Anda pedulikan. Lakukan ini sebelum menafsirkan entri aliran apa pun, karena tuple meyakinkan yang tertambat pada sesi yang salah lebih buruk daripada tidak ada bukti sama sekali.

Baca tabel aliran di gateway perutean

Setelah alamat dan interval ditetapkan, daftar hanya-baca koneksi yang dilacak menunjukkan apa yang diteruskan gateway untuknya. Saring pada sumber asli agar Anda tidak membaca seluruh tabel.

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

Setiap entri memuat dua tuple, asli dan balasan, yang merupakan dua arah satu aliran, bukan dua aplikasi. Pada jalur NAT sumber, tuple asli mempertahankan alamat terowongan sementara sisi balasan menunjukkan alamat gateway yang diterjemahkan, dan itulah yang membuat keluaran tampak keliru pada pandangan pertama.

Perlakukan daftar sebagai status hidup dan bukan riwayat. Aliran pendek mungkin sudah kedaluwarsa, lalu lintas yang tidak dilacak tidak pernah muncul, dan ruang nama jaringan lain menunjukkan tabel lain. Referensi conntrack mendokumentasikan penyaring dan keluaran dua arah.

Satu tangkapan terbatas untuk menegaskan pembacaan

Jika antarmuka terowongan terlihat di tempat Anda memandang, satu tangkapan terbatas menuntaskan apakah paket yang Anda kenali adalah yang ada di kabel. Jaga penyaring tetap sempit dan batas paket kecil.

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

Bandingkan stempel waktu, protokol, dan port dengan entri aliran serta dengan permintaan yang Anda buat sebagai uji. Tangkapan yang diambil setelah NAT hanya menunjukkan alamat publik gateway, sedangkan sisi terowongan mungkin masih menunjukkan alamat klien, dan perbedaan itu adalah informasi, bukan ketidaksesuaian.

Jika antarmuka tidak melihat apa pun, periksa jalur data sebelum menyimpulkan klien menganggur: lalu lintas klien-ke-klien dan sebagian jalur pengurangan beban tidak pernah melewati titik yang Anda amati.

Log proksi, dan batas dari apa yang Anda lihat

Ketika proksi berada di jalur, soket hulunya terlihat di tabel soket tetapi tidak memetakan satu-ke-satu ke klien VPN, terutama dengan pengumpulan atau pemultipleksan. Gunakan log transaksi proksi yang dikonfigurasi untuk menghubungkan identitas klien, tujuan, stempel waktu, dan pengenal permintaan apa pun yang dicatatnya.

Periksa konfigurasi pencatatan versi yang dipasang alih-alih mengasumsikan setiap permintaan dicatat secara bawaan.

Terakhir, tepatlah soal cakupan. Alamat tujuan dan port adalah metadata, bukan URL dan bukan isi halaman, karena sesi HTTPS di dalam tetap memiliki perlindungannya sendiri terlepas dari terowongan. Laporkan apa yang Anda amati, dari titik pengamatan mana, dan pada waktu apa.