Apakah Firewall Memblokir VPN? Pemeriksaan Bertahap

Satu batas waktu VPN membuktikan bahwa tidak ada balasan yang dapat dipakai, dan tidak membuktikan apa pun tentang penyebabnya. Profil bisa menyebut port yang salah, server bisa mati, atau permintaan bisa tiba tanpa jalur balik yang berfungsi. Masing-masing meninggalkan jejak berbeda, dan jejak itulah yang memberi tahu aturan mana yang harus disentuh. Jalani empat tahap di bawah ini secara berurutan. Berhenti begitu salah satunya menjelaskan gejalanya.

Tahap 1: pastikan server dan transportnya

Baca nama server, transport, dan port dari profil penyedia yang berlaku, bukan dari perubahan lokal. Port yang diubah di laptop Anda tidak bisa membuat pendengar di server publik, dan ketidakcocokan itu menghasilkan batas waktu yang identik dengan pemblokiran. Jika profil menawarkan transport alternatif yang didukung, catat sebagai cadangan dan bukan sebagai perbaikan. Selesaikan nama dan bandingkan jawabannya dengan alamat yang diterbitkan penyedia.

Catatan DNS yang kedaluwarsa mengirim klien ke host yang tidak pernah menjawab. Itu kerusakan lain yang meniru penyaring, dan menghapusnya hanya butuh satu kueri.

Tulis kedua nilai itu ke tiket. Setiap perbandingan berikutnya memakainya, dan tiket tanpa keduanya memulai penyelidikan dari awal.

Tahap 2: buktikan jalurnya dengan satu perbandingan terkendali

Biarkan perangkat dan profil tidak berubah lalu coba jaringan akses tepercaya lain. Jika terowongan naik di sana, selisihnya adalah jalur asal atau kebijakannya. Jika perangkat kedua yang disetujui berfungsi di jaringan asal, selisihnya adalah perangkat pertama. Salah satu dari dua perbandingan itu hampir selalu menentukan.

Selesaikan dulu setiap masuk jaringan yang sah, karena portal tertangkap tampak seperti pemblokiran sampai selesai.

Uji port yang sebenarnya Anda pakai, dan perlakukan hasil TCP sebagai informasi tentang TCP saja.

Resolve-DnsName vpn.corp.example
tracert -h 8 -w 500 vpn.corp.example
Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailed

Jabat tangan TCP yang berhasil pada port 443 berarti ada pendengar yang menjawab di sana. Itu tidak mengatakan apa pun tentang pendengar UDP pada 51820, dan tidak tentang selesainya negosiasi.

Tahap 3: baca peristiwa keamanan pada saat kegagalan

Peristiwa firewall adalah bukti terkuat yang tersedia, dan ada satu catatan yang layak disebut lebih dulu. Pencatatan dimatikan pada banyak profil bawaan, jadi periksa apakah profil terkait mencatat penolakan sebelum membaca log kosong sebagai bukti tidak bersalah. Saat pencatatan aktif, peristiwa menyebut aturan, arah, dan alamat, yang persis dibutuhkan untuk mengubah aturan. Aturan aplikasi dan aturan port adalah objek terpisah, dan kebijakan terkelola bisa menimpa pengaturan lokal. Pastikan klien dan layanan mana yang benar-benar dicakup sebuah aturan.

Kumpulkan keadaan profil dan peristiwa terbaru dari mesin yang gagal, bukan dari host tetangga.

Baca waktu peristiwa terhadap waktu percobaan uji Anda, karena nama aturan yang cocok dengan stempel waktu berbeda hanyalah kebetulan.

Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, LogBlocked
Get-NetFirewallRule -Enabled True -Direction Outbound | Where-Object DisplayName -match 'VPN'
Get-WinEvent -LogName 'Microsoft-Windows-Windows Firewall With Advanced Security/Firewall' -MaxEvents 20

Di server yang Anda kelola, tanyakan apakah permintaan itu sampai ke pendengar sama sekali. Paket yang tiba tanpa balasan adalah masalah penerusan atau rute balik. Permintaan yang tidak pernah muncul adalah masalah penyaringan atau pengalamatan.

Tahap 4: uji penerusan setelah terowongan naik

Firewall bisa mengizinkan sesi dan tetap menolak semua yang ingin dicapai sesi. Sysctl penerusan, aturan NAT, dan rute balik semuanya berada setelah autentikasi, dan pengecualian luas untuk port VPN tidak memperbaiki satu pun. Uji satu tujuan internal dan satu tujuan internet secara terpisah, karena keduanya biasanya gagal karena alasan berbeda. Jika nama internal gagal tetapi alamat berfungsi, lihat DNS yang didorong sebelum aturan apa pun.

Jalankan tiga pemeriksaan di bawah pada server saat klien terhubung dan mencoba permintaan yang gagal.

Penghitung pada antarmuka terowongan adalah intinya, karena menunjukkan apakah paket masuk dan apakah ada yang keluar.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -n -E 'forward|masquerade'
tcpdump -ni tun0 -c 10

Ketika paket tiba di terowongan dan tidak ada yang keluar menuju tujuan, tersangkanya adalah penerusan atau NAT. Ketika tidak ada yang tiba, sesi naik tetapi klien tidak mengirim, dan tempat mencarinya adalah tabel rute klien.

Periksa perbaikannya dan hapus yang tidak membantu

Setelah koreksi disetujui, ulangi persis uji yang gagal dan catat hasilnya terhadap profil dan perangkat yang sama. Lalu hapus pengecualian sementara yang tidak mengubah hasil, karena pengecualian yang tidak terpakai menumpuk dan masing-masing adalah keputusan yang tidak diingat siapa pun. Jaga yang tersisa tetap sempit: satu tujuan, satu port, satu arah, satu pemilik.

Jalankan lagi tiga perintah yang sama dan bandingkan dengan keluaran yang Anda simpan sebelum perubahan.

Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailed
tracert -h 8 -w 500 vpn.corp.example
Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match 'VPN' | Select-Object DisplayName, Action

Ketika jaringan pembanding berfungsi, jaringan asal masih gagal, dan peristiwanya tetap kosong, tersangka yang tersisa adalah jalurnya dan bukan hostnya. Serahkan itu kepada pemilik jaringan sebagai pernyataan yang spesifik, dengan kedua hasil perbandingan terlampir. Itu tempat berhenti yang lebih baik daripada profil firewall yang dinonaktifkan.