Vì sao LAN của bạn không tới được dịch vụ trên một máy khách VPN

Đường hầm của bạn đang chạy, dịch vụ đang lắng nghe, và LAN của văn phòng vẫn không nhận lại được gì. Không ai làm hỏng VPN. Từ phía LAN, địa chỉ đường hầm của máy tính xách tay không tồn tại cho tới khi có thứ gì đó nói cho LAN biết cách tới đó, và câu trả lời phải quay về đúng con đường mà yêu cầu đã đi ra. Tôi đã thấy người ta dựng lại một đường hầm hoàn toàn khỏe mạnh ba lần trước khi có ai nhìn vào đường quay về.

Không phải đường hầm bị hỏng

Hai đầu đều nằm trên dải riêng, đây là trường hợp bình thường và không phải cấu hình sai. Một địa chỉ như 10.8.0.6 là thật bên trong đường hầm và không tồn tại ở bất kỳ đâu khác, nên LAN không có lý do gì để gửi gì tới đó. Trước khi chạm vào định tuyến, hãy xác nhận dịch vụ có thể truy cập được bên trong đường hầm: trên máy khách, ss -ltn cho biết trình lắng nghe gắn với 127.0.0.1, giao diện LAN hay địa chỉ đường hầm. Một daemon chỉ gắn với loopback không trả lời ai ngoài chính nó, và không tuyến, DNAT hay chuyển tiếp cổng nào thay đổi điều đó.

Proxy trên cổng 80 hoặc 443 là công cụ khác với tầm nhìn khác. Nó di chuyển yêu cầu chứ không phải gói tin, nên đây là tầng sai cho một kết nối cơ sở dữ liệu thô, và việc vươn tới nó chính là cách sự cố này lún sâu ba công cụ trước khi có ai đo được gì.

Hình dạng tuyến: nói cho LAN biết bể ở đâu

Một tuyến tĩnh trên cổng LAN là câu trả lời sạch nhất khi LAN và bể đường hầm không chồng lên nhau. Hướng bể về máy kết thúc đường hầm:

ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12   # Windows, persistent

Điều đó chỉ sửa một chiều, vì thế các phiên bản nửa vời của thay đổi này trông như tiến bộ. Phía đường hầm cần nửa còn lại tương ứng, nếu không câu trả lời rời máy khách theo tuyến mặc định của chính nó và chết dọc đường:

push "route 192.168.1.0 255.255.255.0"

Với một mạng con nằm sau một máy khách chứ không phải sau máy chủ, máy chủ cần cả tuyến hệ thống lẫn mục iroute trong tập tin của máy khách đó dưới client-config-dir. Không có iroute, OpenVPN biết tiền tố tồn tại và không biết máy khách nào sở hữu nó: gói tin đến và daemon không có gì để khớp chúng với.

Đây là huyền thoại đáng được gọi tên. Một tuyến làm cho địa chỉ tới được; nó không làm cho phía bên kia sẵn lòng trả lời. Các điểm ngang hàng site-to-site thêm một lớp nữa lên trên, vì cổng từ xa chỉ chấp nhận nguồn nằm trong các tiền tố thuộc chính sách của nó, và một máy tính xách tay đến từ bể tại nhà không nằm trong đó.

Hình dạng NAT: DNAT vào trong, và dòng SNAT mà mọi người bỏ qua

Khi không thể chạm vào cổng LAN, hoặc muốn xuất bản đúng một cổng, bản dịch trên máy chủ VPN hoạt động mà không cần bất kỳ tuyến nào trên LAN. Xuất bản cổng, chuyển tiếp nó, và dịch nguồn trên đường vào đường hầm:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1

Dòng thứ ba là dòng biến mất. Bỏ qua nó và máy khách thấy địa chỉ LAN gốc là nguồn, trả lời qua tuyến mặc định của chính nó, và câu trả lời đó đi vào đường hầm thay vì quay lại LAN. Kết nối có sống sót hay không khi đó phụ thuộc vào định tuyến mà bạn chưa bao giờ lên kế hoạch. Với SNAT máy khách thấy địa chỉ đường hầm của máy chủ, nên câu trả lời đi theo đường hầm về lại máy chủ duy nhất có thể hoàn tác bản dịch.

Phần sụn tiêu dùng dùng tên chuỗi riêng và không tạo bản dịch đó cho bạn. Trên Tomato, một quy tắc vào rơi vào WANPREROUTING rồi vào một chuỗi lọc như wanin, và một bộ quy tắc trông đầy đủ vẫn cần một dòng POSTROUTING viết tay. Đó không phải lỗi sụn; đó là bộ quy tắc chỉ viết cho lưu lượng vào.

Vì sao một quy tắc trông đúng vẫn bỏ rơi gói tin

Phần lớn những thất bại này không nằm trong quy tắc bạn đang nhìn chằm chằm. Kiểm tra bốn điều theo thứ tự này, và dừng ở điều đầu tiên không đúng:

• Thứ tự chuỗi. iptables -I chèn lên đầu và -A thêm vào cuối, nên một quy tắc cho phép hoặc chặn trước đó quyết định trước.
• Sai chuỗi. Lưu lượng nhắm tới chính bộ định tuyến đi qua INPUT, còn lưu lượng được chuyển tiếp không bao giờ chạm vào nó. Xuất bản một dịch vụ có thể cần quy tắc ở cả hai.
• Cờ hướng. -i tun0 khớp với lưu lượng đến từ máy khách và -o tun0 khớp với lưu lượng đi về phía họ. Một REJECT với cờ sai sẽ chặn thứ bạn không định.
• Giới hạn nguồn. Một chuyển tiếp chấp nhận một địa chỉ máy khách hoạt động từ máy khách đó và bỏ rơi mọi nguồn khác mà không một lời.

Một quy tắc có bộ đếm gói tin bằng không thì hoàn toàn không nằm trên đường đi, và đọc các bộ đếm là cách nhanh nhất để tách vấn đề sai chuỗi khỏi vấn đề sai quy tắc.

Chuyển tiếp cục bộ, khi không gì trên LAN có thể thay đổi

Chuyển tiếp cục bộ SSH né toàn bộ câu hỏi. Nó không cần tuyến trên LAN, không cần tường lửa của máy khách hợp tác, và không cần cổng nào được xuất bản ở đâu:

ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host

Dịch vụ sau đó xuất hiện trên localhost:3000 của máy giữ đường hầm, và không ở đâu khác. Đó là ranh giới: một máy trạm, một cổng, và chuyển tiếp chết cùng phiên trừ khi có thứ gì khởi động lại nó. Với một quản trị viên đang kiểm tra cơ sở dữ liệu thử nghiệm thì đó là công cụ đúng. Với một camera hay máy quét mà người khác phải tới được thì không, vì mỗi người dùng sẽ cần chuyển tiếp của riêng mình.

Kiểm tra cả hai chiều trước khi thêm một quy tắc nữa

Bản dịch để lại dấu vết, và đọc chúng tốt hơn đoán. Trên máy chủ VPN, conntrack -L cho biết bản dịch có xảy ra không, iptables -t nat -L -n -v cho biết các bộ đếm có nhúc nhích không, và tcpdump -ni any port 3000 cho biết địa chỉ nguồn nào thực sự đến. Trên máy khách, ss -ltn xác nhận trình lắng nghe ở trên một địa chỉ mà đường hầm tới được.

Sau đó chọn hình dạng bạn giữ lại. Một cổng được xuất bản, một tuyến cho toàn bộ bể và một chuyển tiếp cho một quản trị viên là ba cam kết khác nhau, và trộn chúng là cách một thiết lập đang chạy biến thành thứ mà sáu tháng sau không ai giải thích được. Ghi lại địa chỉ nào tới được từ đâu, và người tiếp theo gỡ lỗi việc này sẽ bắt đầu từ câu trả lời thay vì từ đường hầm.