Máy khách OpenVPN đến được máy chủ nhưng không đến các máy chủ LAN: danh mục kiểm tra

Máy khách báo đã kết nối, địa chỉ đường hầm trả lời ping, và không gì trên LAN của văn phòng phản hồi. Tôi thấy điều này sau gần như mỗi lần nâng cấp máy khách, và phản xạ đầu tiên là mở tường lửa, việc thường là bước sai: đường hầm vẫn tốt, và chỗ đứt nằm ở một trong ba chặng mà gói tin phải đi qua. Hãy đi theo tuyến đúng thứ tự gói tin đi, trước hết là tuyến của máy khách, sau đó là việc chuyển tiếp trên máy chủ, cuối cùng là chặng quay về, và bạn sẽ tìm ra thủ phạm trong vài phút.

Bước một: quan sát quyết định định tuyến của máy khách

Trước khi chạm vào máy chủ, hãy chứng minh máy khách gửi gói tin vào đường hầm. Hỏi nhân hệ điều hành xem nó sẽ dùng giao diện nào cho một máy chủ LAN cụ thể, thay vì đọc toàn bộ bảng:

ip route get 192.168.50.10

Nếu câu trả lời nêu tên bộ điều hợp vật lý và cổng của văn phòng, thì không thay đổi nào phía máy chủ có thể giúp. OpenVPN chỉ phát tuyến khi máy chủ đẩy chúng xuống, nên hãy tìm push "route 192.168.50.0 255.255.255.0" trong cấu hình máy chủ, rồi kết nối lại máy khách sau đó. Hầu hết máy khách áp dụng các tuyến được đẩy khi kết nối, không phải khi bạn tải lại hồ sơ.

Trên Windows câu hỏi tương tự có lệnh khác. Find-NetRoute -RemoteIPAddress 192.168.50.10 in ra giao diện và chặng kế tiếp mà ngăn xếp sẽ chọn, và route print -4 cho biết tiền tố được đẩy có tồn tại hay không.

Bước hai: xác nhận máy chủ sẽ chuyển tiếp gói tin

Nếu tuyến của máy khách đúng, gói tin đến được máy chủ và máy chủ phải đồng ý chuyển tiếp nó. Công tắc của nhân là cổng đầu tiên, và sysctl net.ipv4.ip_forward phải trả về 1. Đặt nó bằng echo 1 > /proc/sys/net/ipv4/ip_forward chỉ có tác dụng đến lần khởi động lại kế tiếp, và đó chính là lý do khiếu nại cũ quay lại sau vài tuần.

Hãy ghi lại ở nơi sống sót qua lần khởi động lại:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

Cổng thứ hai là bảng lọc. Một máy chủ đã cài Docker thường mang chính sách FORWARD là DROP, và đường hầm thừa hưởng quyết định đó. iptables -L FORWARD -v -n hiển thị cả chính sách lẫn bộ đếm gói tin; nếu chính sách là DROP, việc chuyển tiếp cần một sự cho phép rõ ràng cho hướng từ đường hầm sang LAN và một cho phản hồi.

Bước ba: theo gói tin ra LAN và tìm phản hồi

Theo dõi cả hai phía của máy chủ cùng lúc. Bắt gói trên đường hầm và trên giao diện LAN, lọc theo một máy khách và một máy chủ để đầu ra vẫn dễ đọc:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

Những yêu cầu xuất hiện trên tun0 rồi lại trên eth0 với nguồn 10.8.0.x, sau đó là im lặng, nghĩa là gói tin đã đến và phản hồi đã đi nơi khác. Máy chủ LAN trả lời cổng mặc định của nó, cổng đó không có tuyến cho nhóm VPN, và phản hồi chết trên bộ định tuyến LAN. Ping máy chủ LAN từ máy chủ không chứng minh được gì về đường đi này, vì lưu lượng đó không bao giờ đi qua đường hầm.

Bước bốn: chọn giữa dịch địa chỉ và một tuyến quay về

Hai cách sửa đóng lỗ hổng, và lựa chọn này có hệ quả vượt ra ngoài việc ping có chạy hay không. Dịch địa chỉ nguồn khiến máy chủ thành người gửi bề ngoài:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Giới hạn quy tắc cho nhóm và giao diện LAN, rồi làm cho nó vĩnh viễn, nếu không lần tải lại tường lửa kế tiếp sẽ âm thầm gỡ bản sửa của bạn. Cái giá là danh tính: mọi máy khách trông giống máy chủ VPN trong nhật ký LAN và các quy tắc truy cập, và per-client policy becomes guesswork.

Một tuyến tĩnh cho 10.8.0.0/24 trên bộ định tuyến LAN, trỏ tới máy chủ VPN, giữ địa chỉ của máy khách hiển thị và là câu trả lời dài hạn tốt hơn khi bộ định tuyến đó là của bạn. Nhiều nơi chạy cả hai trong một thời gian, NAT cho việc sửa ngay và tuyến sau khi chính sách tường lửa được viết. Nếu máy chủ là một điểm ngang hàng site-to-site chứ không phải nhóm, phía máy chủ cũng cần iroute cho mạng con ở xa, nếu không tuyến ngang hàng tồn tại nhưng lưu lượng của máy khách không bao giờ được gắn với nó.

Bước năm: xác minh từ máy khách và ghi lại điều gì đã thay đổi

Khép vòng lặp từ máy khách, không phải từ máy chủ. Kết nối tới một dịch vụ thật trên máy chủ LAN, rồi xác nhận bộ đếm dịch địa chỉ đã nhích bằng iptables -t nat -L POSTROUTING -v -n, vì một quy tắc không có gói tin nào là quy tắc chưa từng khớp. conntrack -L -s 10.8.0.5 hiển thị luồng và trạng thái của nó khi bạn cần bằng chứng rằng chiều quay về đang được theo dõi.

Hãy để lại một ghi chú trong cấu hình máy chủ: mạng con nào, giao diện nào, quy tắc nào, và bộ định tuyến LAN có tuyến quay về hay không. Lần tới khi một bản nâng cấp máy khách xóa mất một tuyến được đẩy, ghi chú đó biến một phiên chữa cháy thành bản sửa một dòng.