Máy chủ VPN tại nhà không truy cập được: đi dọc chuỗi NAT

Máy chủ trả lời trong LAN, quy tắc chuyển tiếp cổng trông đúng, và máy khách bên ngoài vẫn không kết nối được. Đi qua từng ranh giới một ra phía ngoài nhanh hơn sửa quy tắc lần thứ tư, vì mỗi ranh giới để lại bằng chứng riêng: trang WAN của bộ định tuyến, bản dịch của nhà cung cấp và trình lắng nghe trên máy chủ. Hãy bắt đầu từ trang quản trị bạn đã mở sẵn và kết thúc bằng một thử nghiệm từ mạng bạn không kiểm soát. Ghi lại từng kết quả trong khi làm, vì trình tự chính là chẩn đoán và một con số ghi nhớ không phải bằng chứng. Nếu bạn chỉ cần một đường hầm đi ra, bản dịch không phải vấn đề của bạn: chỉ lưu lượng vào không được yêu cầu mới bị chặn.

Bắt đầu từ trang WAN của bộ định tuyến

Đăng nhập vào bộ định tuyến và đọc trang trạng thái thay vì danh sách chuyển tiếp cổng. Ghi lại địa chỉ WAN, giao diện mà nó thuộc về và loại kết nối là DHCP, PPPoE hay thứ gì khác do nhà cung cấp cấp. Sau đó so sánh địa chỉ đó với điều một dịch vụ bên ngoài báo cáo, dùng điện thoại trên dữ liệu di động để quan sát không quay lại qua cùng bộ định tuyến. Hai con số trả lời hai câu hỏi khác nhau, và so sánh chúng là toàn bộ mục đích của bước này.

Địa chỉ WAN khác với địa chỉ công cộng quan sát được nghĩa là có ít nhất một bộ dịch nằm trên bộ định tuyến. Đây chưa phải lỗi, vì nhiều nhà cung cấp dịch theo thiết kế và dịch vụ vẫn hoạt động. Nếu hai địa chỉ khớp nhau, bộ định tuyến có lẽ sở hữu địa chỉ đó và vấn đề đã chuyển vào bên trong mạng của bạn. Dù thế nào, hãy ghi cặp địa chỉ kèm ngày, vì nhà cung cấp cấp lại địa chỉ và so sánh với ghi chú tháng trước không có giá trị.

Lên một chặng

Chạy traceroute ngay từ bộ định tuyến và đọc vài chặng đầu. Địa chỉ công cộng lặp lại, chặng đầu trả lời bằng địa chỉ riêng hoặc địa chỉ trong dải dùng chung 100.64.0.0/10 đều chỉ ra một bộ dịch ở phía trên. RFC 6598 định nghĩa dải đó đúng cho kiểu triển khai này, nên thấy nó trong trường WAN là tín hiệu mạnh chứ không phải điều lạ. Hai bộ dịch trên đường đi làm dấu vết kém rõ ràng hơn, vì vậy hãy đọc mẫu hình chứ không phải một dòng.

Một số nhà cung cấp chỉ hiển thị địa chỉ được cấp trong cổng khách hàng, nên hãy xem ở đó trước khi kết luận bộ định tuyến nói dối. Địa chỉ trong cổng khớp với quan sát bên ngoài của bạn trong khi bộ định tuyến báo cáo điều khác là bằng chứng rõ nhất về một bộ dịch phía trên. Lưu cả hai trang vào biên bản thay đổi, vì cuộc tranh luận ai sở hữu ranh giới nào diễn ra nhanh hơn nhiều khi có hai hình ảnh ghi ngày.

Xác nhận trình lắng nghe và chuyển tiếp

Thử nghiệm trong LAN chứng minh dịch vụ chạy cục bộ và không chứng minh gì về khả năng truy cập từ bên ngoài. Nhiều bộ định tuyến tự trả lời quy tắc chuyển tiếp của chính nó từ bên trong, nên thử nghiệm vòng lặp thành công trong khi đường ra bên ngoài vẫn đóng. Xác nhận tiến trình đang gắn với địa chỉ và cổng bạn nghĩ, rồi thử từ bên ngoài. Mọi thứ bên dưới chỉ để đọc.

ss -lunp | grep -E '1194|51820'
ip -4 addr show | grep -E 'inet '
curl -s --max-time 5 ifconfig.me
traceroute -n -m 5 1.1.1.1

Nếu thử nghiệm bên ngoài cho thấy không có gói nào đến bộ định tuyến, việc rơi gói đã xảy ra ở phía trên và không quy tắc cục bộ nào sửa được. Nếu gói đến mà không có gì trả lời, ranh giới tiếp theo là trình lắng nghe hoặc tường lửa của máy chủ. Bắt gói trên máy chủ phân định bạn đang nhìn cái nào trong hai thứ, và mất ít thời gian hơn một vòng đoán quy tắc nữa. Giữ nguyên trình lắng nghe và cách truyền của nó trong khi so sánh, nếu không thử nghiệm tiếp theo sẽ trả lời câu hỏi khác.

Thay đổi cấu trúc, không phải cùng một quy tắc

Khi bộ dịch thuộc nhà cung cấp, cách khắc phục là một đường khác chứ không phải thêm một chuyển tiếp. Một VPS nhỏ có địa chỉ công cộng, nối bằng đường hầm đi ra từ phía nhà, đặt một đầu cuối có thể truy cập trước dịch vụ. Địa chỉ công cộng do nhà cung cấp cấp đơn giản hơn ở nơi có và thường rẻ hơn vận hành một máy. IPv6 loại bỏ hoàn toàn việc dịch, với điều kiện mạng máy khách, bản ghi DNS và chính sách tường lửa đều hỗ trợ.

DNS động chỉ cập nhật một cái tên; nó không tạo ra khả năng truy cập, và trỏ nó tới một địa chỉ dùng chung sẽ đưa máy khách đến cổng của nhà cung cấp mà các thuê bao khác cũng dùng. Sự cố đó trông giống hệt một máy chủ đã chết, vì vậy biên bản từ các bước trước có ý nghĩa. Ghi lại tên đã phân giải tới địa chỉ nào khi thử nghiệm thất bại, và giữ câu trả lời cùng kết quả thử nghiệm.

Viết lại kế hoạch quanh ranh giới bạn kiểm soát: trình lắng nghe, đường hầm và các tuyến. Chỉ giữ quy tắc chuyển tiếp cũ khi nó còn mô tả điều gì đó đúng, vì một quy tắc không còn khớp với cấu trúc thì tệ hơn không có quy tắc. Ghi lại tầng nào thực sự đang chặn và bằng chứng nào cho thấy điều đó. Nếu không, người tiếp theo mở trang quản trị sẽ lặp lại từng bước của cuộc đi này từ đầu.