Máy khách VPN định tuyến đến được máy chủ nhưng không tới các máy trong LAN

Đường hầm được dựng lên, máy khách ping máy chủ VPN, và một thư mục chia sẻ trên máy cách một bước nhảy không bao giờ trả lời. Không có gì trong cấu hình máy khách giải thích điều này, vì yêu cầu thực sự đã rời máy khách và thực sự đã đến. Thứ thất bại là chuyến đi trở về, và thiết bị thất bại thường là cổng LAN chứ không phải máy chủ VPN. Theo dõi gói phản hồi giải thích toàn bộ lớp triệu chứng này.

Theo phản hồi, không theo yêu cầu

Máy chủ VPN giải mã gói của máy khách và chuyển tiếp nó vào LAN với địa chỉ máy khách vẫn còn trong trường nguồn. Máy đích trả lời địa chỉ đó, và giờ bảng định tuyến của chính nó quyết định mọi thứ. Cổng mặc định của nó không biết gì về nhóm đường hầm, nên phản hồi đi về phía nhà cung cấp internet và bị bỏ ở đâu đó trên đường đó.

Trên máy khách, triệu chứng là hết thời gian im lặng: không từ chối, không đặt lại, chỉ là không có gì. Duyệt thư mục chia sẻ bị treo, ping báo không có phản hồi, và nhật ký máy chủ trông khỏe mạnh vì máy chủ đã làm xong việc của nó.

Đặt tuyến trả về ở nơi các máy nhìn vào

Mọi máy trong LAN đều hỏi cổng mặc định của mình, nên cổng là thiết bị duy nhất cần biết nhóm đường hầm nằm ở đâu. Hãy thêm một tuyến tĩnh ở đó và mọi máy sẽ thừa hưởng đường đi đúng mà không bị động vào.

Nếu cổng phát địa chỉ của chính nó như một tùy chọn DHCP, hãy phân phối tuyến theo cách đó để máy mới tự động nhận. Nếu không, tuyến chỉ sống trong một tệp cấu hình và biến mất ở lần dựng lại tiếp theo.

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

Vì sao NAT nguồn có vẻ khắc phục được

Che nhóm máy khách sau địa chỉ máy chủ VPN loại bỏ vấn đề bằng cách loại bỏ địa chỉ máy khách khỏi gói. Phản hồi sau đó quay về máy chủ, nơi đã biết cách đến đường hầm, và mọi thứ hoạt động. Cái giá là các máy bên trong không còn thấy máy khách là ai, và mọi kết nối trông như đến từ một máy duy nhất.

Sự đánh đổi đó đôi khi đúng, chẳng hạn khi không thể gán tuyến tĩnh cho thiết bị của nhà cung cấp. Đừng làm quy tắc rộng hơn nhóm hiện tại, vì quy tắc viết cho /24 sẽ ngừng khớp vào ngày nhóm được đánh số lại thành /16, và dấu hiệu đầu tiên là một loạt máy khách mới kết nối được mà không đến được đâu.

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

Đường đi trên đám mây cần ba thiết lập

Trong VPC, khoảng trống tương tự trở lại dưới dạng khác, vì mạng con hoàn toàn không có tuyến cho dải máy khách. Bảng định tuyến cần một mục cho nhóm đường hầm trỏ tới giao diện mạng của phiên bản, và giao diện phải tắt kiểm tra nguồn và đích để nền tảng chấp nhận các gói mà nguồn không phải địa chỉ của chính nó. Nhóm bảo mật và ACL mạng cũng phải cho phép nhóm theo cả hai chiều.

Mỗi thiếu sót tạo ra một kiểu hỏng một phần riêng. Bỏ mục trong bảng định tuyến thì các phiên bản riêng trả lời vào một mạng con không thể mang phản hồi về nhóm. Khi kiểm tra vẫn bật, nền tảng bỏ phản hồi sau khi phiên bản đã gửi nó. Không có quy tắc nhóm bảo mật, bản thân yêu cầu không bao giờ đến, và máy khách thấy hết thời gian sớm hơn một lớp.

Chạy các kiểm tra theo thứ tự này

Xác nhận chuyển tiếp và chính sách lọc trước khi đổ lỗi cho định tuyến, vì máy không chịu chuyển tiếp cũng hỏng theo cách im lặng như vậy. Sau đó đọc thiết lập đường ngược hiệu lực trên giao diện mang đường hầm, vì bộ lọc nghiêm ngặt có thể bỏ các phản hồi đến từ hướng không ngờ.

Kết thúc bằng một bản bắt gói trên máy LAN trong khi máy khách ping nó. Yêu cầu đến mà không có phản hồi khớp chứng minh đường trở về, và yêu cầu không bao giờ đến đẩy lỗi về máy chủ hoặc đường hầm.

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

Việc kiểm tra nguồn và đích được ghi lại trong hướng dẫn giao diện mạng đàn hồi. Hãy đặt nó trên giao diện thực sự mang lưu lượng đường hầm, không phải trên một bộ điều hợp không liên quan gắn vào cùng phiên bản.