Tường lửa có chặn VPN không? Kiểm tra từng bước

Một lần hết thời gian của VPN chứng minh rằng không có phản hồi dùng được nào đến, và không chứng minh gì về nguyên nhân. Hồ sơ có thể ghi sai cổng, máy chủ có thể đang tắt, hoặc yêu cầu có thể đến mà không có đường quay về hoạt động. Mỗi trường hợp để lại một dấu vết khác nhau, và dấu vết chính là thứ cho bạn biết phải chạm vào quy tắc nào. Đi qua bốn giai đoạn dưới đây theo thứ tự. Dừng lại ngay khi một trong số chúng giải thích được triệu chứng.

Giai đoạn 1: xác nhận máy chủ và giao thức truyền

Đọc tên máy chủ, giao thức truyền và cổng từ hồ sơ hiện tại của nhà cung cấp chứ không phải từ chỉnh sửa cục bộ. Một cổng bị đổi trên máy tính xách tay của bạn không thể tạo ra bộ lắng nghe trên máy chủ công cộng, và sự không khớp đó tạo ra hết thời gian giống hệt như bị chặn. Nếu hồ sơ cung cấp giao thức truyền thay thế được hỗ trợ, hãy ghi lại như phương án dự phòng chứ không phải cách khắc phục. Phân giải tên và so sánh câu trả lời với địa chỉ mà nhà cung cấp đã công bố.

Một bản ghi DNS cũ gửi máy khách đến máy chủ chưa bao giờ trả lời. Đó là một lỗi khác bắt chước bộ lọc, và loại trừ nó chỉ tốn một truy vấn.

Ghi cả hai giá trị vào phiếu. Mọi so sánh sau này đều dùng chúng, và phiếu không có chúng sẽ bắt đầu lại cuộc điều tra.

Giai đoạn 2: chứng minh đường đi bằng một so sánh có kiểm soát

Giữ nguyên thiết bị và hồ sơ rồi thử một mạng truy cập đáng tin cậy khác. Nếu đường hầm dựng lên ở đó, khác biệt là đường đi ban đầu hoặc chính sách của nó. Nếu thiết bị thứ hai đã được phê duyệt hoạt động trên mạng ban đầu, khác biệt là thiết bị thứ nhất. Một trong hai so sánh đó gần như luôn mang tính quyết định.

Trước tiên hãy hoàn tất mọi lần đăng nhập mạng hợp pháp, vì cổng chặn giữ trông giống như bị chặn cho đến khi hoàn tất.

Kiểm tra cổng bạn thực sự dùng, và coi kết quả TCP là thông tin chỉ về TCP.

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

Một cái bắt tay TCP thành công trên cổng 443 cho biết có bộ lắng nghe đã trả lời ở đó. Nó không nói gì về bộ lắng nghe UDP trên 51820, cũng không nói gì về việc thương lượng đã hoàn tất hay chưa.

Giai đoạn 3: đọc các sự kiện bảo mật tại thời điểm thất bại

Sự kiện của tường lửa là bằng chứng mạnh nhất hiện có, và chúng mang một lưu ý nên nói trước. Ghi nhật ký bị tắt trong nhiều hồ sơ mặc định, vì vậy hãy kiểm tra xem hồ sơ liên quan có ghi lại việc loại bỏ hay không trước khi đọc một nhật ký trống như bằng chứng vô tội. Khi ghi nhật ký bật, sự kiện nêu quy tắc, hướng và địa chỉ, đúng là thứ mà một thay đổi quy tắc cần. Quy tắc ứng dụng và quy tắc cổng là các đối tượng riêng, và chính sách được quản lý có thể ghi đè thiết lập cục bộ. Xác nhận quy tắc thực sự bao phủ máy khách nào và dịch vụ nào.

Thu thập trạng thái hồ sơ và các sự kiện gần đây từ chính máy đã thất bại, không phải từ máy chủ lân cận.

Đọc thời điểm sự kiện so với thời điểm bạn thử nghiệm, vì một tên quy tắc trùng khớp với dấu thời gian khác là sự trùng hợp.

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

Trên máy chủ bạn quản trị, hãy hỏi liệu yêu cầu có đến được bộ lắng nghe hay không. Một gói đến mà không có phản hồi là vấn đề chuyển tiếp hoặc đường quay về. Một yêu cầu không bao giờ xuất hiện là vấn đề lọc hoặc đánh địa chỉ.

Giai đoạn 4: kiểm tra chuyển tiếp sau khi đường hầm dựng lên

Tường lửa có thể cho phép phiên và vẫn từ chối mọi thứ mà phiên muốn đến. Sysctl chuyển tiếp, quy tắc NAT và đường quay về đều nằm sau xác thực, và một ngoại lệ rộng cho cổng VPN không sửa được cái nào trong số đó. Kiểm tra riêng một đích nội bộ và một đích internet, vì chúng thường thất bại vì lý do khác nhau. Nếu tên nội bộ thất bại nhưng địa chỉ hoạt động, hãy xem DNS được đẩy trước bất kỳ quy tắc nào.

Chạy ba kiểm tra dưới đây trên máy chủ trong khi máy khách đã kết nối và đang thử yêu cầu thất bại.

Các bộ đếm trên giao diện đường hầm là điểm mấu chốt, vì chúng cho biết gói đã vào và có gì ra hay không.

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

Khi gói đến đường hầm mà không có gì đi ra về phía đích, nghi phạm là chuyển tiếp hoặc NAT. Khi không có gì đến, phiên đã dựng nhưng máy khách không gửi, và nơi cần xem là bảng định tuyến của máy khách.

Xác minh bản sửa và loại bỏ những gì không giúp ích

Sau một chỉnh sửa được phê duyệt, hãy lặp lại chính xác bài kiểm tra đã thất bại và ghi kết quả với cùng hồ sơ và thiết bị. Sau đó loại bỏ mọi ngoại lệ tạm thời không làm thay đổi kết quả, vì các ngoại lệ không dùng sẽ tích tụ và mỗi cái là một quyết định không ai nhớ đã đưa ra. Giữ những gì còn lại thật hẹp: một đích, một cổng, một hướng, một người phụ trách.

Chạy lại đúng ba lệnh đó và so sánh với đầu ra bạn đã lưu trước khi thay đổi.

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

Khi mạng so sánh hoạt động, mạng ban đầu vẫn thất bại và các sự kiện vẫn trống, nghi phạm còn lại là đường đi chứ không phải máy chủ. Chuyển giao cho chủ mạng như một tuyên bố cụ thể, kèm cả hai kết quả so sánh. Đó là nơi dừng tốt hơn một hồ sơ tường lửa bị vô hiệu hóa.