Máy khách VPN trên máy chủ LAN: vì sao các phản hồi đi sai đường

Các triệu chứng theo một khuôn mẫu: một máy chủ chạy tốt, rồi nó kết nối VPN với vai trò máy khách, và giờ máy khách LAN vẫn đến được nó trong khi phản hồi của nó biến mất. Bắt gói trên máy chủ cho thấy các phản hồi đi ra qua thiết bị đường hầm thay vì giao diện LAN. Không có gì hỏng trong đường hầm, và cách sửa là một tuyến, không phải kết nối lại. Hãy làm bốn kiểm tra dưới đây theo thứ tự và dừng ở kiểm tra đầu tiên thất bại.

Phản hồi là một gói mới, không phải sự đảo ngược đường đi

Sẽ hữu ích nếu bỏ ý nghĩ rằng phản hồi quay lại theo đúng đường mà yêu cầu đã đi. Việc định tuyến được quyết định theo từng gói, từng hướng, trên máy chủ gửi. Một yêu cầu đến từ 10.64.0.23 bên trong đường hầm không tạo ra đường trả về nào; khi máy chủ trả lời, phản hồi đó được đối chiếu với bảng như một gói mới và đi ra theo tuyến thắng.

Đó là lý do một máy khách đường hầm đầy đủ trên máy cũng phục vụ một LAN tạo ra lỗi khó hiểu như vậy. Máy khách cài một tuyến mặc định, hoặc hai nửa tuyến mặc định mà một số máy khách ưa thích, và phản hồi cho máy khách LAN giờ khớp với đường hầm. Nó đi tới nhà cung cấp, bên không có lý do để chuyển tiếp, và máy khách LAN thấy hết thời gian dù máy chủ vẫn sống và trả lời cục bộ. Việc bắt gói làm điều đó rõ ràng, và bảng định tuyến giải thích.

Hãy giữ hai mạng con trong đầu khi đọc phần còn lại. Một là nhóm địa chỉ VPN nơi máy khách từ xa đến, trong ví dụ này 10.64.0.0/24. Hai là LAN phải tiếp tục hoạt động, 172.16.24.0/24 với bộ định tuyến ở 172.16.24.1. Lỗi là lưu lượng giữa hai mạng được quyết định bởi tuyến mặc định.

Chứng minh bằng bắt gói và tra cứu

Trước khi thay đổi bất cứ điều gì, hãy xác nhận phản hồi sẽ dùng thiết bị nào. Tra cứu nhanh hơn bắt gói và trả lời đúng câu hỏi mà nhân hệ điều hành sẽ trả lời khi gói được dựng.

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

Đọc phản hồi thành hai phần. Nếu nó nêu dev tun0, máy chủ sẽ đóng gói phản hồi và giao cho nhà cung cấp, và máy khách LAN sẽ không bao giờ thấy. Nếu nó nêu dev eth0 nhưng máy khách vẫn hết thời gian, tuyến đã đúng và gói bị bỏ sau đó, đó là vấn đề khác với cách sửa khác.

Việc bắt gói ở cùng bước giải quyết nghi ngờ mà ping không thể. Một phản hồi dội về đến máy khách LAN chứng minh có một đường hoạt động, không phải giao diện nào đã chở nó, vì vậy hãy bắt gói trên chính máy chủ và xem các khung hình đi ra từ đâu. Máy in trong cùng mạng con vẫn trả lời, vì tuyến trực tiếp của nó cụ thể hơn tuyến mặc định của đường hầm. Cổng được chuyển tiếp cũng thất bại như mọi luồng khác, vì bảng chọn giao diện chứ không phải kết nối.

Cài tuyến hẹp nhất vượt qua đường hầm

Độ dài tiền tố quyết định, không phải metric, nên tuyến cho nhóm máy khách qua bộ định tuyến LAN thắng mọi tuyến mặc định mà máy khách VPN cài. Không cần phẫu thuật metric, và tuyến mặc định có thể ở đúng nơi máy khách đặt.

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

Dùng replace thay vì add, vì máy khách kết nối lại sẽ đã cài mục của riêng nó và lệnh add thứ hai thất bại với lỗi tuyến đã tồn tại, đọc như một vấn đề quyền. Trên máy chủ Windows tương đương là route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, trong đó -p giữ mục qua các lần khởi động lại, vì máy khách có thể dựng lại bảng khi đường hầm trở lại. Trên máy chủ Windows hiện đại, tương đương được hỗ trợ là New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, còn lệnh route cũ được giữ như dạng cũ.

Một chi tiết quyết định điều này đúng hay chỉ có vẻ hợp lý: bước nhảy tiếp theo phải là bộ định tuyến thực sự sở hữu đường về phía máy khách. Chỉ tuyến tới một địa chỉ mà bản thân nó đạt được qua đường hầm sẽ tạo một vòng lặp xuất hiện như mất mát gián đoạn thay vì lỗi sạch. Xác nhận bước nhảy tiếp theo nằm trong mạng con LAN trước khi chốt dòng lệnh.

Giữ phản hồi sau khi kết nối lại

Một tuyến thêm bằng tay tồn tại tốt nhất đến lần kết nối lại tiếp theo. Nếu nhóm máy khách là động, hãy ghim nó trong cấu hình máy chủ để tiền tố bạn đã định tuyến vẫn là tiền tố máy khách nhận; nếu không mục sẽ trỏ tới một dải rỗng và triệu chứng quay lại sau nhiều tuần mà không có nguyên nhân rõ ràng. Ghi tuyến vào tập lệnh up của chính máy khách là lựa chọn đáng tin cậy khác, vì nó chạy sau khi máy khách đã viết lại bảng.

Một tường lửa có trạng thái vẫn có thể đánh bại một tuyến đúng. Nếu bắt gói giờ cho thấy phản hồi đi ra qua eth0 mà máy khách vẫn hết thời gian, hãy kiểm tra xem máy chủ có bỏ gói trước khi gửi. Lọc đường ngược nghiêm ngặt và net.ipv4.conf.all.rp_filter đặt thành 1 sẽ bỏ những gói có nguồn không được định tuyến ngược qua giao diện mà chúng đến, và đó chính là trường hợp bất đối xứng bạn vừa tạo rồi sửa, còn trạng thái conntrack kể cùng câu chuyện cho các cổng được chuyển tiếp.

Kiểm tra cuối cùng là cái người ta bỏ qua: lặp lại tra cứu sau khi đường hầm xuống rồi lên lại. Bốn giá trị phải khớp với những gì bạn đã ghi: đích, bước nhảy tiếp theo, thiết bị và nguồn được chọn. Nếu bất kỳ giá trị nào đã xê dịch, máy khách đã viết lại bảng và cách sửa nằm trong các hook của nó, không phải lịch sử shell.