Vì sao VPN đang hoạt động vẫn hết thời gian chờ ở gói trả lời

Yêu cầu đến, máy chủ ghi lại, và máy khách vẫn báo hết thời gian chờ. Sự kết hợp đó có nghĩa là câu trả lời không tìm được đường quay về, và đây là một trong số ít lỗi bạn có thể xác nhận từ cả hai đầu cùng lúc. Hãy làm các bước kiểm tra theo thứ tự và dừng lại khi một bước thất bại.

Bắt đầu từ nơi yêu cầu đã đến

Trước khi xem xét bất cứ điều gì khác, hãy xác nhận gói tin đã tới dịch vụ. Một dòng nhật ký phía máy chủ, một bộ đếm kết nối hay một lần bắt gói được phép ở đầu xa đều trả lời cùng một câu hỏi, và việc thiếu chúng đưa bạn trở lại đường hầm thay vì tiến tới câu trả lời. Đây là bước kiểm tra phân biệt vấn đề chuyển tiếp với vấn đề đường về.

Nếu yêu cầu chưa từng đến, hãy dừng ở đây. Đường hầm, việc định tuyến tới tiền tố riêng hay quy tắc truy cập là chủ đề, và đường của câu trả lời chưa liên quan. Cũng ghi lại địa chỉ nguồn mà máy chủ đã thấy. Đó hoặc là địa chỉ từ bể mà máy khách nhận được, hoặc là địa chỉ đã dịch, và sự khác biệt này quyết định bước kiểm tra nào tiếp theo được áp dụng.

Câu trả lời cần một tuyến đường tới bể địa chỉ

Máy khách truy cập từ xa thường nhận địa chỉ từ một bể, và mạng riêng cần tuyến đường quay lại bể đó. Máy chủ có tuyến mặc định trỏ tới cổng của chính nó sẽ giao gói tin cho cổng đó, cổng này không biết bể nằm ở đâu, nên câu trả lời chết tại đó. Máy khách thấy hết thời gian chờ vì không có gì quay lại, và điều đó không thể phân biệt với một yêu cầu chưa bao giờ rời đi.

Hãy kiểm tra tuyến đường máy chủ chọn cho địa chỉ máy khách, không phải tuyến nó dùng cho mạng con của chính nó. Hai lần tra cứu đó có thể cho kết quả khác nhau, và lần thứ hai mới là điều quan trọng ở đây. Phép dịch là thiết kế thay thế và nó thay đổi những gì máy chủ thấy. Nó có thể đơn giản hóa đường về, và cũng loại bỏ địa chỉ gốc của máy khách khỏi nhật ký máy chủ, điều này ảnh hưởng tới mọi quy tắc hay báo cáo dựng trên trường đó.

So sánh bản bắt gói trên máy chủ với bản bắt gói trên cổng

So sánh thứ rời khỏi máy chủ với thứ đến cổng. Bản bắt gói trên giao diện ra của máy chủ và bản bắt gói trên cổng đường hầm trả lời hai nửa khác nhau của câu hỏi, và khoảng trống giữa chúng chỉ ra nơi mất gói.

ip route get 10.90.0.14
tcpdump -ni any host 10.90.0.14 and port 443
ip route show table all | grep 10.90.0.0

Một yêu cầu do chính cổng tạo ra là vật thay thế kém cho phép thử từ máy khách, vì nó xuất phát từ địa chỉ khác và gặp quy tắc khác. Vì thế một ping thành công từ cổng và một yêu cầu thất bại từ máy khách có thể cùng đúng một lúc.

Khi trên đường có nhiều bộ định tuyến, hãy kiểm tra từng cái cần tuyến tới bể địa chỉ. Thiết kế site-to-site thường đòi hỏi tiền tố xa phải được biết trên nhiều hơn một thiết bị, và bản thân cổng phải chuyển tiếp giữa đường hầm và mạng cục bộ; ghi chú của strongSwan về chuyển tiếp bao quát phần sysctl và tường lửa của việc đó.

Ghi lại bể, tiền tố và người phụ trách

Bốn dữ kiện thuộc về ghi chú: bể mà máy khách nhận được, tiền tố riêng mà nó cần, bộ định tuyến chịu trách nhiệm về câu trả lời, và quy tắc dịch nếu có. Với chúng, một thay đổi cổng về sau là so sánh chứ không phải điều tra.

Sau đó thử lại với một máy khách thông thường và tài khoản thật của ứng dụng. Mở rộng quyền của ứng dụng không thể sửa đường về của gói tin, và việc đổi tài khoản trong lúc chẩn đoán này sẽ làm rối lần so sánh tiếp theo. Nếu thiết kế dựa vào phép dịch, hãy ghi lại nó ở nơi đọc nhật ký máy chủ. Người thấy một địa chỉ nguồn lạ trong dấu vết kiểm toán không nên phải khám phá lại ánh xạ từ một phiếu hỗ trợ.