Ping chỉ chạy một chiều: vì sao Windows bỏ phản hồi của máy chủ

Máy khách của bạn ping tới máy chủ, máy chủ không ping được máy khách, và đường hầm rõ ràng đang chở gói tin trong cả hai câu đó. Điều khác biệt không phải đường đi mà là gói đầu tiên của mỗi lần thử: một là phản hồi cho một luồng mà Windows đã theo dõi, còn lại là yêu cầu vào mới mà không quy tắc nào chấp nhận. Khác biệt đó giải thích phần lớn báo cáo ping một chiều và chỉ thẳng vào quy tắc bạn phải viết. Hai lần thử theo hai chiều ngược nhau tách các trường hợp trong khoảng một phút.

Hai chiều, hai quyết định khác nhau

Khi máy khách gửi yêu cầu phản hồi, tường lửa Windows thấy một kết nối đi ra mà nó đã quyết định cho phép. Phản hồi quay về bên trong luồng đã thiết lập đó, nên bộ máy theo dõi trạng thái cho qua mà không hỏi bất kỳ quy tắc vào nào cho ICMP. Đó là ý nghĩa của lọc theo trạng thái trong thực tế, và quy tắc mà không ai viết không tham gia. Vì vậy thành công của máy khách không nói gì về chính sách vào.

Khi máy chủ gửi yêu cầu trước, không trạng thái nào khớp với nó. Windows coi gói đó là một kết nối vào mới và hỏi chính sách vào, mà mặc định không dự liệu gì cho các yêu cầu phản hồi đến từ nguồn tùy ý.

Vậy thành công của máy khách đã chứng minh ICMP đi ra và đường quay về hoạt động. Nó chưa bao giờ kiểm tra quyết định vào, và kết luận tự nhiên, rằng tường lửa ổn, là hợp lý và sai. Đó là lý do lỗi này lặp lại trong những phiếu đã có sẵn bằng chứng.

Theo gói tin cho đến khi nó biến mất

Xác nhận địa chỉ trước khi thay đổi bất cứ điều gì: dùng địa chỉ đường hầm mà máy khách thực sự có, và kiểm tra rằng máy chủ định tuyến tới đó chứ không phải tới một địa chỉ LAN phía sau máy khách. Hai lỗi trông giống nhau từ dấu nhắc của máy chủ, vì cả hai đều kết thúc bằng hết thời gian chờ. Gói chết ở đâu là sự thật duy nhất quyết định phải thay đổi điều gì.

Nếu yêu cầu tới được giao diện đường hầm mà không có gì đi ra, tường lửa cục bộ là nguyên nhân khả dĩ. Nếu nó không bao giờ tới giao diện, câu trả lời nằm ở phía trên: một tuyến trên máy chủ, một chính sách đi ra, hoặc chính việc chuyển tiếp giữa các nút của VPN.

Bắt gói trên giao diện đường hầm của máy khách trong khi máy chủ ping. Thấy yêu cầu đến mà bên cạnh không có phản hồi là bằng chứng biện minh cho việc viết một quy tắc Windows. Không thấy gì sẽ đưa bạn lên phía trên, và một quy tắc thêm vào trong trạng thái đó chỉ làm máy dễ dãi hơn với một gói chưa bao giờ tới. Dù thế nào, việc bắt gói cũng rẻ hơn những phỏng đoán mà nó thay thế.

Giới hạn một quy tắc thay vì mở ICMP

Xác định bộ điều hợp và danh mục hiện tại của nó trước khi viết bất cứ điều gì, vì cả hai đều xuất hiện trong phạm vi bạn sắp đặt. Bí danh đó là tên giao diện của Windows, không nhất thiết là tên hồ sơ VPN bạn đã nhập. Các lệnh bên dưới liệt kê những gì đang có, rồi xem trước một quy tắc giới hạn mà không áp dụng nó.

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 kiểu 8 là yêu cầu phản hồi, thông điệp duy nhất mà máy chủ cần được trả lời. Giới hạn nó cho địa chỉ đường hầm của máy chủ và cho giao diện đường hầm, và để hồ sơ đúng như bộ điều hợp thực sự là. Đổi tên một mạng để khớp với ví dụ là một thay đổi riêng với hậu quả riêng của nó.

Điều quy tắc không bao phủ

Phản hồi IPv6 là giao thức khác với kiểu thông điệp khác, nên một quy tắc ICMPv4 không nói gì về nó, và đường hầm chở cả hai họ cần quy tắc riêng cho họ còn lại. Quy tắc này cũng không mở gì khác: RDP, chia sẻ tệp và mọi dịch vụ khác vẫn phụ thuộc vào chính sách của chúng. Đó là toàn bộ ý nghĩa của việc giới hạn một quy tắc hẹp thay vì bật một quyền ICMP rộng. Quyền rộng là cách sửa dễ và là thứ tồn tại lâu nhất, vì sau đó không ai để ý tới nó.

Trên thiết bị được quản lý, quy tắc có thể bị thay thế ở lần làm mới chính sách tiếp theo, nên chủ sở hữu chính sách phải thực hiện thay đổi tương đương chứ không phải quản trị viên cục bộ. Ghi ý định vào phiếu cùng với lệnh, vì lần làm mới sẽ xóa lệnh và để yêu cầu nguyên vẹn. Hai thứ đó không phải cùng một tạo tác, và chỉ một trong hai tồn tại.

Đọc kết quả theo đúng chiều

Sau khi quy tắc có hiệu lực, ping từ máy chủ và xác nhận có phản hồi tới máy khách, sau đó ping từ một nguồn vẫn phải bị loại trừ và xác nhận nó không tới. Lặp lại bài kiểm tra khả năng tiếp cận trên họ địa chỉ còn lại nếu đường hầm chở nó.

Get-NetFirewallRule -DisplayName "VPN server echo" | Get-NetFirewallAddressFilter
ping 10.63.4.17
ping -6 fd00:63::17

In ra quy tắc đã có hiệu lực hữu ích hơn là tin vào lệnh đã tạo ra nó, vì bản xem trước và quy tắc đã áp dụng là hai trạng thái khác nhau. Nếu bộ lọc địa chỉ hiển thị nguồn bạn định và nguồn bị loại trừ vẫn hết thời gian chờ, quy tắc làm đúng những gì phạm vi của nó nói. Một ping thành công khởi phát từ máy khách sẽ không bao giờ chứng minh được điều đó, nên chiều của mỗi lần thử thuộc vào bản ghi bên cạnh kết quả. Giữ cả hai chiều trong phiếu, nếu không người đọc sau sẽ lặp lại bài kiểm tra không thể thất bại.