Mengapa hasil pemindaian port berubah di balik keluaran VPN?
Ubah keluaran dan sebuah port dapat menjawab berbeda tanpa layanan berpindah. Pisahkan pengamatan jalur dari inventaris yang benar-benar Anda butuhkan.
Jalankan pemeriksaan port yang sama dari jalur kantor dan dari keluaran VPN, dan kedua jawabannya bisa berbeda pendapat tentang alamat yang tidak diubah siapa pun. Selisih itu datang dari rute dan dari host mana yang menjawab, bukan dari layanan yang hidup atau mati. Tiga pertanyaan memisahkan penjelasan itu: apa yang sebenarnya ditanyakan probe, host mana yang menjawabnya, dan apa yang dicatat server Anda sendiri. Telusuri ketiganya dalam urutan itu dan tuliskan setiap jawaban sebelum pindah ke yang berikutnya.
Perbaiki probe sebelum membandingkan dua eksekusi
Sebuah kata status hanya dapat dibandingkan dengan kata status lain bila keduanya berasal dari eksperimen yang sama. Lima bidang memastikannya: alamat sumber yang dilihat sisi jauh, tujuan yang telah diresolusi, port, jenis pemindaian, dan waktu. Ubah salah satunya dan Anda telah menjalankan eksperimen kedua alih-alih mengukur yang pertama dua kali.
Periksa sumbernya sebelum hal lain, karena klien VPN bisa hidup sementara lalu lintas tetap keluar melalui antarmuka fisik. Tanyakan kepada sisi jauh apa yang dilihatnya, lalu tanyakan kepada kernel antarmuka mana yang dipilihnya:
curl -s https://ifconfig.me
ip route get 203.0.113.20Dua alamat di jaringan berbeda berarti penjelasannya sudah di tangan, dan sisa pemeriksaan ini hanya akan menegaskannya. Bila keduanya sepakat, rekam probe dengan tanda alasan menyala, agar status kembali terikat pada penjelasan alih-alih berdiri sendiri sebagai kata telanjang. Jenis pemindaian juga termasuk dalam catatan itu, karena ia menggambarkan apa yang ditanyakan, bukan apa yang kembali. Status tanpa sumber, tanpa metode, dan tanpa stempel waktu tidak dapat dibandingkan dengan apa pun:
nmap -sT -p 443,8443 --reason 203.0.113.20Simpan keluaran itu di samping catatan, bukan di buffer gulir yang tidak bisa dilihat orang berikutnya. Dua pemindaian jujur yang berbeda pendapat hanyalah perdebatan bila tidak ada yang menuliskan kondisinya. Setelah kondisinya tetap, entah hasilnya cocok dan pertanyaannya tertutup, atau keduanya berbeda dan perbedaannya adalah fakta tentang jalur.
Cari tahu host mana yang menyelesaikan jabat tangan
Jabat tangan yang selesai membuktikan bahwa suatu host menyelesaikannya, dan host itu belum tentu proses yang ada di pikiran Anda. Penyeimbang beban, proxy terbalik, atau proxy SYN dapat menjawab sebelum server sungguhan terlibat, yang merupakan desain biasa, bukan gejala. Sertifikat yang sah untuk nama yang diharapkan juga tidak mempersempitnya, karena sertifikat menggambarkan hubungan layanan dan tidak mengatakan apa pun tentang mesin mana yang mengakhiri koneksi.
Referensi status port Nmap menganggap ini dasar: status mencatat apa yang bisa diamati probe dari tempat ia dikirim, bukan sifat port. Baca kata status seperti itu dan dua eksekusi yang tadinya berbeda pendapat mulai tampak konsisten alih-alih bertentangan, sementara pertanyaannya bergeser dari apakah port terbuka menjadi siapa yang berdiri di depannya.
Jawab pertanyaan kedua di backend, bukan dari luar. Frontend yang menerima koneksi lalu gagal mencapai upstream-nya menghasilkan tepat gambaran luar layanan sehat dengan aplikasi yang lambat. Hanya catatan upstream itu sendiri yang memisahkan kedua kasus:
tail -n 5 /var/log/nginx/access.log
ss -ltnp 'sport = :443'Baris log menunjukkan alamat klien yang benar-benar dilihat aplikasi, dan perintah kedua menunjukkan apakah proses yang memegang port 443 adalah aplikasi Anda atau sesuatu di depannya. Bila keduanya berbeda pendapat tentang alamat mana yang tersambung, Anda sedang melihat dua kaki dari satu permintaan dan tiket seharusnya mengatakan itu.
Periksa aturan Anda sendiri sebelum menyalahkan terowongan
Kebijakan yang disengaja adalah alasan paling umum sebuah port menjawab di satu jaringan dan tidak di jaringan lain, dan itu penjelasan paling tidak menarik yang tersedia. Aturan akses ada untuk mengizinkan satu sumber dan membuang sisanya, jadi perubahan egress justru peristiwa yang menjadi alasan aturan itu ditulis. Karena itu status berbeda lewat VPN tidak menunjukkan bahwa penyedia memeriksa lalu lintas. Itu menunjukkan alamat sumber Anda sekarang berbeda, yang merupakan klaim jauh lebih kecil.
Aturan itu dapat dibaca di server, jadi bacalah alih-alih berspekulasi tentang bagian tengah jaringan. Daftar aturan filter yang menyebut salah satu dari dua rentang alamat, lalu periksa apakah koneksi sama sekali mencapai daemon:
nft list ruleset | grep -n -e 203.0.113 -e 198.51.100
journalctl -u sshd -n 50 | grep 203.0.113Hasil kedua yang kosong bersifat informatif, karena tidak ada yang mencapai daemon dan pertanyaannya milik filter, grup keamanan, atau jalur itu sendiri. Sebuah hit berarti layanan melihat sumber Anda dan memilih jawabannya, dan keputusan itu biasanya tertulis dalam aturan yang dapat Anda baca. Tidak satu pun hasil mendukung cerita tentang penyedia, dan keduanya lebih murah diperiksa daripada menangkap paket.
Baca transport, sertifikat, dan respons secara terpisah
Tiga lapisan menghasilkan tiga pengamatan, dan probe yang menguji salah satunya tidak dapat melaporkan dua lainnya. Simpan sebagai baris terpisah dalam catatan alih-alih melipatnya menjadi satu putusan, karena setiap baris gagal dengan caranya sendiri dan mode kegagalan memberi tahu di mana harus melihat berikutnya.
| Observation | What it settles | What it leaves open |
|---|---|---|
| Connection completed | A host on the path accepted the handshake | Which host, and whether its upstream is reachable |
| Certificate valid for the name | The endpoint holds a credential for that name | Whether the process behind it is the one you meant |
| Expected response body | The application handled the request | Anything about other ports or other paths |
| Connection refused | A host replied and nothing was listening | Whether a filter sits ahead of the refused port |
| Timeout | No reply arrived before the deadline | Drop, blackhole route or an overloaded host |
Satu perintah menghasilkan tiga baris pertama terhadap layanan yang Anda kendalikan. Taruh keluarannya di catatan di samping pemindaian, bukan di pesan obrolan:
curl -v --resolve office.example:443:203.0.113.20 https://office.example/Baca keluarannya berurutan: jabat tangan menjawab pertanyaan transport, subjek sertifikat menjawab pertanyaan nama, dan badan respons menjawab pertanyaan aplikasi. Bila baris jabat tangan berhasil dan baris respons tidak, Anda memiliki frontend dengan upstream rusak, bukan port yang diblokir. Itu tiket yang berbeda dari yang Anda buka, dan patut dikatakan terus terang.
Akhiri dengan menulis empat fakta di tiket: alamat sumber, jenis pemindaian, host yang menjawab, dan waktu. Semua yang dibutuhkan perbandingan nanti hidup dalam keempatnya, dan siapa pun yang mengambil kasus berikutnya tidak akan memiliki riwayat terminal Anda. Bila Anda tidak dapat mengisi keempatnya, eksekusinya belum selesai.