VPN đã kết nối nhưng tường lửa vẫn chặn: làm sao biết bên nào

Máy khách báo đã kết nối, tài nguyên vẫn từ chối, và bước tiếp theo thường là tắt một thứ gì đó. Hai biện pháp kiểm soát trong câu đó làm việc khác nhau: VPN dựng đường đi cho lưu lượng được bao phủ, còn tường lửa quyết định theo từng kết nối liệu lưu lượng có được đi qua. Một đường hầm hoạt động với chính sách từ chối trông giống hệt đường hầm hỏng từ chỗ ngồi của người dùng, nên việc cần làm là tìm ra lớp nào đang trả lời. Đây là thứ tự tôi làm, kèm cách đọc cho bạn biết khi nào nên dừng.

Tách đường đi khỏi chính sách

Bắt đầu từ hình dạng của sự cố, vì đó là thông tin miễn phí. Gói bị bỏ cho ra hết thời gian: máy khách thử lại, không có gì trở về và lệnh treo cho đến khi bỏ cuộc. Bị từ chối cho ra lời từ chối hoặc đặt lại: có thứ gì đó trả lời và nói không. Một dịch vụ không lắng nghe sẽ từ chối ngay trên máy chủ, không có tường lửa nào tham gia.

Ba kết quả đó chỉ về các lớp khác nhau. Hết thời gian nghĩa là đâu đó có chính sách âm thầm bỏ gói, hoặc đường đi không bao giờ rời khỏi máy. Bị từ chối nghĩa là bạn đã đến được máy chủ và ngăn xếp hoặc tường lửa cục bộ của nó từ chối. Im lặng hoàn toàn, khi giao diện đường hầm đang bật và không có đường đến đích, nghĩa là đường đi sai và không quy tắc tường lửa nào sửa được.

Đọc đường đi trong một lượt

Xác nhận đường hầm bao phủ đích trước khi nhìn đến một quy tắc nào. Một đường hầm chia tách chỉ mang mạng con văn phòng sẽ không định tuyến yêu cầu sang dải khác, và khi đó sự cố trông như chặn của tường lửa trong khi không phải:

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

Kết quả của tuyến nêu giao diện mà gói sẽ đi ra và địa chỉ nguồn mà nó mang theo. Nếu giao diện đó là card mạng vật lý của bạn chứ không phải đường hầm, vấn đề nằm ở định tuyến hoặc ở các dải được phép của đường hầm, và thuộc cấu hình VPN chứ không phải tường lửa.

Một cái bẫy riêng của VPN đáng được kiểm tra riêng. Trong WireGuard, AllowedIPs của một peer vừa là tuyến vừa là bộ lọc mật mã: gói có địa chỉ nguồn không khớp tập được phép của peer bị bỏ trước khi bất kỳ quy tắc tường lửa nào được xem xét. Vì vậy một tường lửa máy chủ hoàn toàn đúng vẫn có thể nằm sau một lần bỏ im lặng trông như chính sách, và cách sửa là một dòng cấu hình khóa, không phải một quy tắc.

Đọc chính sách ở lớp đang trả lời

Khi đường đi đúng, đi qua chính sách từ máy chủ ra ngoài và để ý lớp duy nhất có bộ đếm nhúc nhích:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

Socket đang lắng nghe trả lời câu hỏi khác với các quy tắc. Nếu không có gì lắng nghe trên cổng, nhân từ chối kết nối và không quy tắc vào nào liên quan. Nếu socket tồn tại và kết nối từ máy khách từ xa hết hạn, một lần bỏ đang xảy ra đâu đó trên đường đi, và bộ đếm của các quy tắc cho bạn biết nó có xảy ra ở đây không.

Bật ghi nhật ký cho hồ sơ hoặc chuỗi bạn nghi ngờ thay vì đoán từ bên ngoài. Một lần bỏ được ghi lại có nêu nguồn, đích và cổng sẽ xác định lớp và quy tắc, và cũng chứng minh gói đã đến, điều mà không thử nghiệm phía máy khách nào xác lập được.

Đọc quyết định của cổng khi đường hầm kết thúc ở đó

Trên cổng site-to-site hoặc truy cập từ xa, VPN xác thực người dùng và chính sách cấp quyền cho tài nguyên, và đó là những cấp quyền riêng. Người dùng được vào đường hầm không tự động được vào mọi máy chủ nội bộ, và việc từ chối thường đến từ quy tắc chuyển tiếp trong khi bản thân đường hầm vẫn khỏe. Cùng sự tách biệt đó xuất hiện trong IPsec, nơi chính sách bảo mật chọn lưu lượng khác với bộ lọc cho phép nó, và vì thế cả hai được ghi nhận là các cơ chế khác nhau trong RFC 4301.

Kiểm tra đường về cẩn thận như đường đi. Lọc theo trạng thái cần thấy câu trả lời, nên định tuyến bất đối xứng qua đường hầm theo một hướng và vòng quanh nó theo hướng kia tạo ra những lần bỏ trông ngẫu nhiên và chỉ lặp lại từ một số máy khách. Nếu lưu lượng đến cổng và dừng lại, hãy đọc quy tắc chuyển tiếp và đường về cùng nhau trước khi mở rộng bất cứ điều gì.

Cổng cũng là nơi một quy tắc NAT hoặc che giấu có thể ẩn nguồn thật. Nếu máy chủ nội bộ thấy địa chỉ của cổng thay vì máy khách, các quy tắc tường lửa máy chủ của họ lẽ ra phải khớp với nhóm máy khách sẽ không bao giờ khớp, và cách sửa thuộc về cổng chứ không phải từng máy chủ.

Sửa lớp hẹp nhất, rồi kiểm chứng

Chống lại việc sửa rộng. Tắt tường lửa máy chủ, thêm quy tắc cho phép mọi thứ hoặc ép mọi giao diện vào hồ sơ tin cậy đều gỡ bỏ biện pháp kiểm soát đang làm việc của nó, và thay đổi còn sống lâu hơn sự cố. Một quy tắc giới hạn ở dải nguồn và cổng liên quan dễ xem lại hơn, dễ gỡ hơn, và để nguyên phần còn lại của chính sách trên máy.

Kiểm chứng bằng đúng thử nghiệm đã thất bại, từ đúng máy khách đó, rồi một lần nữa sau khi kết nối lại, vì một quy tắc khớp trước khi đường hầm đàm phán lại có thể thôi khớp sau đó:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

Trước khi đóng lại:

• Đường đến đích đi ra qua giao diện đường hầm, và địa chỉ nguồn khớp với điều chính sách mong đợi.
• Có thứ gì đó đang lắng nghe trên cổng, và việc từ chối hoặc hết thời gian được quy cho một quy tắc có tên chứ không phải giả định.
• Cổng chuyển tiếp theo cả hai hướng, và đích thấy nguồn mà các quy tắc của bạn được viết cho.
• Không biện pháp kiểm soát nào bị tắt để thử nghiệm qua, và thay đổi bạn làm nêu một dải nguồn và một cổng.