VPN kết nối nhưng không tới được thiết bị LAN: cần kiểm tra gì

Lưu lượng đi vào đường hầm, cổng vào trả lời trên địa chỉ của chính nó và không có gì phía sau trả lời. Mẫu hình đó là phổ biến và không phải mâu thuẫn: một câu trả lời từ cổng vào chứng minh đường hầm đã kết thúc, và nó không chứng minh gì về điều xảy ra với một gói tin được đánh địa chỉ ra phía sau. Hai bài kiểm tra dùng những đường mã khác nhau trên cùng một máy.

Từ giờ hãy thử một thứ gì đó ở phía bên kia cổng vào. Địa chỉ của chính cổng vào vẫn sẽ trả lời, dù việc chuyển tiếp hỏng đến đâu.

Cổng vào trả lời từ ngăn xếp của chính nó

Một gói tin được đánh địa chỉ tới cổng vào được giao cho đường nhập cục bộ của nó, nơi nhân quyết định liệu một ổ cắm đang lắng nghe có nhận nó hay không. Một gói tin được đánh địa chỉ tới một máy chủ phía sau cổng vào thay vào đó được giao cho đường chuyển tiếp, nơi áp dụng một bộ kiểm tra khác. Việc chuyển tiếp có thể bị vô hiệu hoàn toàn, hoặc nhân bật nó lên rồi một quy tắc lọc không bao giờ nhắc tới đường hầm lại từ chối nó. Không điều nào trong số đó ảnh hưởng tới câu trả lời của chính cổng vào, vì thế triệu chứng đánh lừa một cách đáng tin cậy đến vậy.

Các trang quản trị tiếp cận qua đường hầm cũng thuộc nhóm thứ nhất. Chúng là bằng chứng về đường hầm, không phải về mạng phía sau nó.

Lần theo luồng tới ranh giới đầu tiên đánh rơi nó

Bắt đầu từ máy khách và xác nhận tuyến cùng địa chỉ nguồn mà luồng sẽ dùng. Sau đó quan sát cổng vào xem đúng luồng đó có tới không, và một lần nữa xem cùng luồng đó đi ra hướng LAN. Nếu nó không bao giờ tới, vấn đề nằm ở phía máy khách hoặc ở các tiền tố được cho phép của đường hầm. Nếu nó tới và không bao giờ đi ra, vấn đề nằm ở việc chuyển tiếp hoặc ở bộ lọc đường đi phía trước, và bản ghi đã nói rõ là cái nào.

Chạy cùng bài kiểm tra từ cổng vào sẽ giấu đi nửa thú vị, vì một gói tin bắt nguồn từ cổng vào có nguồn khác và yêu cầu quay về khác. Hãy dùng luồng của máy khách, mang theo địa chỉ nguồn của chính nó, ở mọi bước. Một bản ghi lấy trên giao diện sai tạo ra những điều vô nghĩa đầy tự tin.

Các tuyến quay về và tường lửa của máy chủ hỏng riêng rẽ

Khi gói tin tới máy chủ, ba điều nữa phải đúng. Dịch vụ phải đang lắng nghe trên địa chỉ mà gói tin được gửi tới, tường lửa của máy chủ phải chấp nhận nó, và câu trả lời phải có tuyến quay về phía nhóm máy khách. Điều cuối thường hỏng, vì tuyến mặc định của máy chủ trỏ tới một bộ định tuyến chưa từng nghe về dải của đường hầm. Kết quả là một kết nối được thiết lập theo góc nhìn của máy chủ và chết lặng lẽ theo hướng kia.

Hãy thử đường quay về một cách có chủ đích bằng cách gửi từ máy khách và quan sát sự quay lại. Một bản ghi một chiều giải quyết trong vài giây điều mà một giờ phỏng đoán sẽ không giải quyết.

Xác nhận từng chặng bằng địa chỉ nguồn của máy khách

Chạy các bước kiểm tra theo thứ tự và giữ lại mọi kết quả, vì giá trị nằm ở sự so sánh chứ không ở một dòng đơn lẻ. Các lệnh dưới đây ghim địa chỉ nguồn, hiển thị tuyến đã chọn và ghi lại hai phía của việc chuyển tiếp. Thay máy chủ LAN và giao diện đường hầm của bạn vào.

ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20

Truy vấn tuyến cho biết máy khách có gửi gói tin đó vào đường hầm hay không, và ping cho biết có gì quay về từ máy chủ hay không. So sánh hai bản ghi tách sự tới khỏi sự đi ra, vì một khung trên giao diện đường hầm không có bản tương ứng trên giao diện LAN là quyết định chuyển tiếp chứ không phải sự cố dịch vụ. Khi cả hai bản ghi đều cho thấy yêu cầu và chỉ một cho thấy câu trả lời, tuyến quay về là nghi phạm còn lại.

Ghi lại địa chỉ nào đã trả lời và đích được chuyển tiếp nào đã hỏng. Câu đó làm cho báo cáo có thể hành động thay vì một khẳng định rằng máy chủ không thể tới được.