Ping hanya berfungsi satu arah: mengapa Windows menggugurkan gema pelayan
Ping daripada klien berjaya kerana tembok api menerima balasan, bukan permintaan. Ikuti gema ke arah bertentangan dan hadkan satu peraturan kepada terowong.
Klien anda mengeping pelayan, pelayan tidak dapat mengeping klien, dan terowong jelas membawa paket dalam kedua-dua kenyataan itu. Yang berbeza bukan laluannya tetapi paket pertama setiap ujian: satu ialah balasan kepada aliran yang sudah dijejaki Windows, satu lagi ialah permintaan masuk baharu yang belum diterima mana-mana peraturan. Perbezaan itu menjelaskan kebanyakan laporan ping sehala dan terus menunjuk kepada peraturan yang perlu anda tulis. Dua ujian dalam arah bertentangan memisahkan kes itu dalam kira-kira seminit.
Dua arah, dua keputusan berbeza
Apabila klien menghantar permintaan gema, tembok api Windows melihat sambungan keluar yang telah diputuskan untuk dibenarkan. Balasan kembali di dalam aliran yang sudah terbentuk itu, jadi enjin yang menjejaki keadaan menerimanya tanpa bertanya mana-mana peraturan masuk bagi ICMP. Itulah maksud penapisan berasaskan keadaan dalam amalan, dan peraturan yang tidak ditulis sesiapa tidak terlibat. Jadi kejayaan klien tidak menyatakan apa-apa tentang dasar masuk.
Apabila pelayan menghantar permintaan lebih dahulu, tiada keadaan yang sepadan dengannya. Windows menganggap paket itu sebagai sambungan masuk baharu dan bertanya kepada dasar masuk, yang secara lalai tidak menyediakan apa-apa untuk permintaan gema yang datang daripada sumber sewenang-wenangnya.
Jadi kejayaan klien membuktikan bahawa ICMP keluar dan laluan balik berfungsi. Ia tidak pernah menguji keputusan masuk, dan kesimpulan semula jadi, bahawa tembok api itu elok, munasabah dan salah. Itulah sebabnya kesilapan ini berulang dalam tiket yang sudah mengandungi buktinya.
Ikuti paket sehingga ia hilang
Sahkan alamat sebelum mengubah apa-apa: gunakan alamat terowong yang benar-benar dipegang klien, dan periksa bahawa pelayan menghalakan ke alamat itu dan bukan ke alamat LAN di belakang klien. Kedua-dua kegagalan kelihatan sama daripada prompt pelayan, kerana kedua-duanya berakhir dengan tamat masa. Di mana paket itu mati ialah satu-satunya fakta yang menentukan apa yang perlu diubah.
Jika permintaan sampai ke antara muka terowong dan tiada apa yang keluar, tembok api setempat ialah punca yang mungkin. Jika ia tidak pernah sampai ke antara muka, jawapannya di hulu: laluan pada pelayan, dasar keluar, atau penghantaran sesama rakan sebaya VPN itu sendiri.
Tangkap pada antara muka terowong klien semasa pelayan mengeping. Melihat permintaan tiba tanpa balasan di sisinya ialah bukti yang mewajarkan penulisan peraturan Windows. Tidak melihat apa-apa menghantar anda ke hulu, dan peraturan yang ditambah dalam keadaan itu hanya menjadikan mesin lebih permisif terhadap paket yang tidak pernah tiba. Dalam apa jua keadaan, tangkapan itu lebih murah daripada andaian yang digantikannya.
Hadkan satu peraturan daripada membuka ICMP
Kenal pasti penyesuai dan kategorinya sekarang sebelum menulis apa-apa, kerana kedua-duanya muncul dalam skop yang anda akan tetapkan. Alias itu ialah nama antara muka Windows, yang belum tentu nama profil VPN yang anda import. Arahan di bawah menyenaraikan apa yang ada, kemudian mempratonton peraturan terhad tanpa menerapkannya.
Get-NetConnectionProfile
Get-NetAdapter | Where-Object Status -eq 'Up'
New-NetFirewallRule -DisplayName "VPN server echo" -Direction Inbound -Protocol ICMPv4 -IcmpType 8 -RemoteAddress 10.63.0.1 -InterfaceAlias "Office VPN" -Profile Private -Action Allow -WhatIf
ICMPv4 jenis 8 ialah permintaan gema, satu-satunya mesej yang perlu dijawab oleh pelayan. Hadkannya kepada alamat terowong pelayan dan kepada antara muka terowong, dan biarkan profil sebagaimana penyesuai sebenarnya. Menamakan semula rangkaian supaya sepadan dengan contoh ialah perubahan berasingan dengan akibatnya sendiri.
Apa yang tidak diliputi peraturan
Gema IPv6 ialah protokol lain dengan jenis mesej lain, jadi peraturan ICMPv4 tidak menyatakan apa-apa tentangnya, dan terowong yang membawa kedua-dua keluarga memerlukan peraturannya sendiri untuk yang satu lagi. Peraturan ini juga tidak membuka apa-apa yang lain: RDP, perkongsian fail dan setiap perkhidmatan lain masih bergantung pada dasar masing-masing. Itulah keseluruhan inti menghadkan satu peraturan sempit daripada membolehkan kebenaran ICMP yang luas. Kebenaran luas ialah pembaikan yang mudah dan yang paling lama bertahan, kerana tiada siapa menyedarinya selepas itu.
Pada peranti terurus, peraturan boleh diganti pada penyegaran dasar seterusnya, jadi pemilik dasar perlu membuat perubahan setara dan bukan pentadbir setempat. Tulis niat itu dalam tiket bersama arahan, kerana penyegaran akan memadam arahan itu dan membiarkan keperluannya utuh. Kedua-duanya bukan artifak yang sama, dan hanya satu daripadanya bertahan.
Baca hasilnya dalam arah yang betul
Selepas peraturan berkuat kuasa, mengeping dari pelayan dan sahkan balasan sampai kepada klien, kemudian mengeping daripada sumber yang sepatutnya masih dikecualikan dan sahkan ia tidak sampai. Ulang ujian kebolehcapaian pada keluarga alamat yang lain jika terowong membawanya.
Get-NetFirewallRule -DisplayName "VPN server echo" | Get-NetFirewallAddressFilter
ping 10.63.4.17
ping -6 fd00:63::17
Mencetak peraturan yang berkuat kuasa lebih berguna daripada mempercayai arahan yang menciptanya, kerana pratonton dan peraturan yang diterapkan ialah dua keadaan berbeza. Jika penapis alamat menunjukkan sumber yang anda maksudkan dan sumber yang dikecualikan masih tamat masa, peraturan itu melakukan tepat seperti yang dikatakan skopnya. Ping berjaya yang bermula daripada klien tidak akan pernah membuktikannya, dan itulah sebabnya arah setiap ujian tergolong dalam rekod di sebelah hasilnya. Simpan kedua-dua arah dalam tiket, atau pembaca seterusnya akan mengulangi ujian yang tidak mungkin gagal.