Các máy khách VPN bị chặn bởi hồ sơ Tường lửa Công cộng của Windows
Windows phân loại bộ điều hợp VPN là Công cộng, vì vậy các quy tắc LAN của bạn không bao giờ được áp dụng. Hãy kiểm tra hồ sơ, giới hạn một quy tắc vào đến nhóm và sau đó xác minh cổng.
Đường hầm của bạn đã hoạt động, cổng mạng trả lời ping, và việc chia sẻ tệp vẫn hết thời gian chờ. Sự kết hợp đó hiếm khi là vấn đề định tuyến: Windows đã đặt mạng con của bộ điều hợp VPN vào hồ sơ Công cộng, và mọi quy tắc cho phép được viết cho Riêng tư hoặc Miền đều không bao giờ được áp dụng. Tôi đã gặp điều này trên máy tính xách tay kết nối văn phòng bình thường và trên máy chủ RRAS phục vụ mọi máy khách khác, và việc sửa chữa ngắn gọn khi bạn gọi tên hồ sơ đang liên quan. Đây là trình tự tôi làm việc, cùng với bước kiểm tra cho bạn biết khi nào nên dừng trước bước tiếp theo.
Xác định hồ sơ nào mà lưu lượng thực sự đi vào
Tường lửa Windows không có một chế độ toàn cục duy nhất. Mỗi giao diện được kết nối mang một danh mục, và các gói đến được lọc theo danh mục của giao diện mà chúng đi vào, vì vậy hồ sơ của bộ điều hợp VPN quyết định máy khách trong đường hầm có thể truy cập gì, chứ không phải bộ điều hợp Wi-Fi hay Ethernet bên cạnh. Hãy đọc cả hai sự thật trước khi thay đổi bất cứ điều gì:
Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory, IPv4Connectivity
Get-NetFirewallProfile -Name Public | Select-Object Name, Enabled, DefaultInboundAction
Trong một bản cài đặt OpenVPN hoặc WireGuard tiêu chuẩn, bộ điều hợp VPN xuất hiện như một mạng không xác định và rơi vào Công cộng, đây là mặc định cho mọi mạng mà Windows không thể phân loại: không có bộ điều khiển miền nào trả lời qua nó và không có hồ sơ cổng nào khớp. Tên giao diện không quan trọng ở đây, vì vậy gọi bộ điều hợp là "VPN" hay "Corp" không thay đổi gì. DomainAuthenticated yêu cầu một máy đã tham gia miền , máy đó thực sự có thể tiếp cận bộ điều khiển miền qua giao diện ấy; một đường hầm chia tách chỉ mang một mạng con sẽ không đáp ứng điều kiện đó.
Nếu quy tắc bạn cần đã được giới hạn trong nhóm VPN và đã áp dụng cho danh mục bạn vừa đọc, hãy dừng ở đây: lọc không phải lớp của bạn, và nơi tiếp theo cần xem là cấu hình dịch vụ. Bước kiểm tra đó mất mười giây và tiết kiệm một giờ chỉnh sửa quy tắc. Tên danh mục và những gì mỗi danh mục bao gồm được ghi trong tài liệu tham chiếu Get-NetConnectionProfile.
Xác nhận việc lọc, không phải định tuyến, trước khi chỉnh sửa quy tắc
Ping là một phép thử yếu. ICMP có thể đi qua trong khi cổng dịch vụ bị loại bỏ, và một máy chủ có thể trả lời từ LAN trong khi từ chối cùng yêu cầu qua đường hầm. Hãy thử cổng mà máy khách cần, từ máy khách:
Test-NetConnection 10.8.0.1 -Port 445
Test-NetConnection 10.8.0.1 -Port 3389 -InformationLevel Detailed
Nếu phép thử cổng thất bại, hãy tách hai lớp. Lỗi đường hầm hoặc tuyến thường biểu hiện là không có phản hồi nào từ địa chỉ cổng, trong khi việc tường lửa loại bỏ cho thấy một cổng có phản hồi và một cổng dịch vụ không phản hồi. Trên máy chủ Windows công bố nhóm qua RRAS, hãy chạy cùng phép thử từ máy khách và đọc hồ sơ của chính máy chủ: giao diện RAS có thể nằm trong một danh mục mà các quy tắc vào của nó không bao giờ nhắc đến dải máy khách, và đó là lý do máy phục vụ LAN của mình và từ chối mọi máy khách trong đường hầm.
Khi kết quả vẫn chưa rõ ràng, hãy ghi lại các lần loại bỏ cho hồ sơ đang liên quan và đọc chúng:
Set-NetFirewallProfile -Name Public -LogBlocked True `
-LogFileName "$env:systemroot\system32\LogFiles\Firewall\pfirewall.log"
Các mục ghi địa chỉ và cổng của máy khách với DROP là quyết định, và chúng cũng cho bạn biết quy tắc nào bị thiếu. Một nhật ký không có gì trong khi SYN của máy khách không bao giờ xuất hiện cho thấy vấn đề ở phía trước máy chủ, vì vậy hãy quay lại đường hầm, quy tắc NAT hoặc tuyến của nhóm trước khi chạm vào một đối tượng tường lửa khác.
Giới hạn một quy tắc vào cho nhóm máy khách
Cách sửa là một quy tắc cho phép vào duy nhất có địa chỉ từ xa là nhóm, không phải cả thế giới. Từ một phiên nâng cao:
New-NetFirewallRule -DisplayName "VPN clients - SMB 445" `
-Direction Inbound -Action Allow -Protocol TCP -LocalPort 445 `
-RemoteAddress 10.8.0.0/24 -Profile PublicKhi dịch vụ là một tệp nhị phân duy nhất, hãy ưu tiên quy tắc giới hạn theo chương trình với -Program thay vì danh sách cổng; điều đó giới hạn ngoại lệ cả theo tiến trình lẫn theo dải nguồn.
Việc chọn hồ sơ là nơi cùng một lỗi được thực hiện theo hướng ngược lại. -Profile Public là đủ khi bộ điều hợp là Công cộng và vẫn là Công cộng. -Profile Any là có thể bảo vệ khi dịch vụ phải hoạt động bất kể Windows phân loại bộ điều hợp thế nào, nhưng chỉ khi phạm vi từ xa còn giữ. Điều không bao giờ có thể bảo vệ là -RemoteAddress Any trên hồ sơ Công cộng: quy tắc đó đi theo máy tính xách tay vào mọi mạng quán cà phê và khách sạn mà nó tham gia và mở cổng cho bất kỳ ai chia sẻ mạng con đó.
Ghi lại nhóm bên cạnh quy tắc. -RemoteAddress 10.8.0.0/24 âm thầm ngừng khớp vào ngày nhóm VPN được đánh số lại, và lỗi trông giống hệt lỗi ban đầu, vì vậy nó tốn thêm một buổi chiều. Đặt tên quy tắc theo dịch vụ và dải nguồn, giữ chúng cùng nhau với -Group, và đọc lại chúng mỗi khi định nghĩa nhóm thay đổi. Một bản kiểm kê quy tắc bạn có thể kiểm toán trên một màn hình tốt hơn một quy tắc đúng mà không ai tìm thấy.
Chỉ thay đổi danh mục khi danh mục chính là quyết định
Chuyển giao diện sang Riêng tư cũng hiệu quả, và đó là mặc định sai. Hồ sơ Riêng tư mang một danh sách dài các quy tắc cho phép có sẵn, bao gồm chia sẻ tệp và máy in, khám phá mạng, máy tính từ xa và nhiều hơn tùy theo đường cơ sở, vì vậy việc phân loại lại bộ điều hợp VPN bật tất cả chúng cùng lúc cho mọi máy khách trong đường hầm. Một quy tắc giới hạn cấp một dịch vụ cho một dải. Trên máy tính xách tay cũng tham gia các mạng không tin cậy, sự khác biệt đó không phải là thẩm mỹ.
Có những trường hợp việc phân loại thực sự sai: một đường hầm luôn bật hoặc giữa các site mang mạng con văn phòng là hạ tầng tin cậy, và đánh dấu bộ điều hợp đó là Riêng tư là một lựa chọn thiết kế hợp pháp, được đưa ra một lần theo chính sách chứ không phải theo từng phiếu. Khi bạn làm điều đó, hãy làm rõ ràng:
Set-NetConnectionProfile -InterfaceAlias "OpenVPN TAP-Windows6" -NetworkCategory PrivateTrên thiết bị được quản lý, trước tiên hãy kiểm tra xem Chính sách nhóm hay đường cơ sở MDM có sở hữu thiết lập đó không. Nếu có, thay đổi cục bộ sẽ bị hoàn tác ở lần làm mới tiếp theo, và gpresult /h sẽ nêu tên chính sách sở hữu nó; hãy sửa ở đó, không phải ở điểm cuối.
Xác minh từ cả hai đầu và để lại dấu vết
Xác minh luồng mà người dùng báo cáo, từ máy khách, sau thay đổi:
Test-NetConnection 10.8.0.1 -Port 445
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallAddressFilter | Select-Object RemoteAddress
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallPortFilter | Select-Object Protocol, LocalPort
Sau đó đóng vòng lặp với những thứ sẽ hỏng vào tuần sau. Khởi động lại máy chủ và thử lại, vì quy tắc giới hạn ở hồ sơ sai vẫn hoạt động cho đến khi bộ điều hợp trở lại ở danh mục khác. Thử từ máy khách thứ hai, vì một máy khách giữ một hợp đồng thuê cũ có thể che giấu sự không khớp của nhóm. Đếm các quy tắc bạn đã thêm so với những quy tắc đã xóa, vì các ngoại lệ chồng chéo là cách một bản sửa hai dòng trở thành một chính sách lọc mà không ai có thể xem xét.
Trước khi bạn coi là xong:
- Hồ sơ được nêu trong quy tắc là hồ sơ trên giao diện mà lưu lượng đi vào.
- Phạm vi từ xa là nhóm VPN, và nhóm đó khớp với những gì máy chủ thực sự cấp phát.
- Không quy tắc nào bạn thêm sử dụng
-RemoteAddress Anytrên hồ sơ Công cộng. - Không có gì bị vô hiệu hóa để phép thử vượt qua, và mọi thay đổi danh mục đều ghi lại ai đã phê duyệt.