Cara mencatat dan memverifikasi alamat keluar VPN yang Anda pakai

Tanyakan kepada klien VPN desktop server mana yang Anda pakai, dan jawaban jujurnya biasanya sebuah nama lokasi. Nama itu adalah titik masuk yang Anda pilih, dan alamat tempat lalu lintas Anda keluar bisa saja mesin yang sama sekali lain. Tidak ada apa pun di aplikasi yang dirancang untuk menyimpan angka kedua, jadi catatan harus dibangun pada saat pemakaian. Ada dua pendekatan, dan hanya satu yang bertahan saat berhadapan dengan kasus dukungan.

Dua catatan, dan hanya satu yang benar-benar ada

Tampilan klien sendiri paling banter adalah daftar lokasi terpilih dengan stempel waktu. Itu keputusan desain, bukan kelalaian: alamat adalah detail operasional, berganti di antara penugasan, dan menyingkap pemetaannya membuat dukungan maupun penanganan penyalahgunaan lebih sulit. Penyedia menaruh instans cloud di depan jaringan mereka justru agar titik akhir bisa berpindah tanpa memberi tahu siapa pun. Yang ditunjukkan aplikasi kepada Anda adalah pilihan yang Anda ambil, bukan rute yang ditempuh lalu lintas.

Catatan yang bisa Anda bangun adalah berkas lokal berisi satu alamat publik dan satu stempel waktu UTC per baris. Berkas itu lebih kecil, lebih jelek, dan jauh lebih berguna, karena menggambarkan persis apa yang juga bisa dilihat pengamat luar.

Opsi A: rekam sendiri alamat keluarnya

Layanan gema mengembalikan alamat sumber dari mana permintaan datang, yang menurut definisi adalah alamat keluar. Jalankan perekaman setelah terowongan melaporkan terhubung, karena klien yang mengatakan terhubung sebelum rute dan DNS stabil akan mencatat alamat sebelum terowongan dan meracuni log sejak baris pertama.

#!/bin/sh
umask 077
log="$HOME/vpn-exit.log"
printf '%s %s\n' "$(date -u +%Y-%m-%dT%H:%M:%SZ)" "$(curl -fsS https://api.ipify.org)" >> "$log"

Dua detail membuat potongan itu berguna, bukan sekadar hiasan. Stempel waktu dan alamat berbagi satu baris, sehingga penguraian nanti tidak perlu memasangkan catatan, dan umask 077 menjaga berkas tetap privat sejak dibuat. Jalankan sekali per koneksi, bukan sekali per boot, dan simpan satu berkas per perangkat.

Log mencatat kapan Anda memakai terowongan dan dari jaringan mana Anda muncul, yang lebih dekat ke riwayat penjelajahan daripada penghitung. Pilih masa simpan yang bisa Anda pertahankan, simpan berkas di luar folder sinkronisasi bersama, dan hapus dengan sengaja.

Opsi B: minta riwayat kepada penyedia

Sebagian penyedia menyimpan log koneksi dan akan menjawab pertanyaan dukungan dengan stempel waktu dan nama server. Catatan itu menggambarkan infrastruktur mereka, bukan lalu lintas Anda, dan nilainya hanya sebaik jendela penyimpanan serta kemauan mereka untuk melihat. Catatan itu juga menggambarkan sesi, bukan permintaan. Jendelanya biasanya pendek, dan diukur dari sisi penyedia terowongan.

Penyedia yang mengiklankan tidak mencatat log tidak dapat menyediakan ini saat diminta, dan daftar lokasi terbaru di sisi klien bukan hal yang sama. Meminta alamat keluar kepada penyedia tanpa log biasanya berakhir dengan penjelasan mengapa data itu tidak ada.

Apa yang bisa dibuktikan setiap catatan dalam kasus dukungan

Kedua catatan menjawab pertanyaan berbeda, dan di tabellah perbandingannya berhenti menjadi akademis.

Hanya kolom pertama yang ada dalam kendali Anda. Catatan penyedia dapat mengonfirmasi bahwa sebuah akun terhubung pada waktu tertentu, tetapi tidak dapat mengonfirmasi permintaan mana yang memakai terowongan, dan tidak akan menyebut alamat yang dianggap penyedia sebagai detail operasional. Tidak ada catatan yang mengidentifikasi orang, karena alamat keluar bersama bisa membawa banyak pelanggan pada menit yang sama.

Bandingkan keduanya dengan garis dasar sebelum percaya salah satunya

Alamat saja tidak membuktikan apa pun. Rekam alamat langsung sebelum terhubung, alamat lewat terowongan sesudahnya, dan bandingkan keduanya. Nilai yang identik berarti terowongan tidak membawa permintaan itu, entah karena terowongan terpisah, proksi yang mengungguli, atau klien yang jatuh kembali ke jalur langsung.

curl -fsS https://api.ipify.org; echo
curl -fsS https://api64.ipify.org; echo
dig +short TXT o-o.myaddr.l.google.com @1.1.1.1

Ulangi perbandingan untuk DNS dan IPv6, karena gema alamat membuktikan jalur satu permintaan HTTP dan tidak mengatakan apa pun tentang resolver mana yang menjawab. Perangkat yang bocor pada salah satunya bisa tampak sepenuhnya sehat pada yang lain.