Máy khách VPN tới được máy chủ nhưng không tới LAN: cách khắc phục nào?

Máy khách ping địa chỉ đường hầm của máy chủ OpenVPN và nhận được trả lời, sau đó thử một máy trong LAN của máy chủ và không nhận được gì. Sự phân tách đó thu hẹp lỗi đáng kể: đường hầm đã lên, chuyển tiếp có lẽ đang chạy, và gói trả lời đi ra bằng một cánh cửa không dẫn về. Có ba cách khắc phục, và cách đúng phụ thuộc vào việc bạn kiểm soát được gì và sẵn sàng từ bỏ điều gì. Trả lời ba câu hỏi dưới đây theo thứ tự và lựa chọn sẽ không còn là chuyện khẩu vị.

Trước hết, xác nhận chiều nào bị hỏng

Yêu cầu đến giao diện đường hầm với địa chỉ nguồn từ bể VPN. Máy chủ chuyển tiếp nó tới máy trong LAN, và máy đó trả lời tới cổng mà bảng của chính nó chỉ ra, thường là bộ định tuyến của LAN. Nếu bộ định tuyến không có tuyến tới bể, gói trả lời chết ở đó hoặc lang thang về phía internet.

Hãy kiểm tra cả hai máy trước khi sửa bất kỳ máy nào. Hỏi bảng định tuyến trên máy chủ xem nó sẽ tới máy khách bằng đường nào; hỏi máy trong LAN xem nó sẽ tới cùng địa chỉ đó bằng cách nào. Tra cứu đầu tiên thường chỉ vào đường hầm và tra cứu thứ hai chỉ vào bộ định tuyến của LAN, và khác biệt đó chính là lỗi trong một dòng. Hai lần tra cứu rẻ hơn một cuộc kiểm toán tường lửa và chúng xác định chiều của vấn đề.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

Nếu máy trong LAN đã trỏ tới máy chủ VPN, vấn đề của bạn là một quy tắc tường lửa hoặc giới hạn MTU chứ không phải thiếu đường về. Đừng thêm tuyến để sửa một bộ lọc.

Câu hỏi một: bạn có thể sửa bộ định tuyến của LAN xa không?

Khi bộ định tuyến của LAN là của bạn, câu trả lời sạch sẽ là một tuyến tĩnh tới bể VPN với địa chỉ LAN của máy chủ VPN làm bước kế tiếp. Nó giữ nguyên địa chỉ nguồn của máy khách, điều quan trọng khi các máy trong LAN ghi log, lọc hoặc giới hạn tốc độ theo địa chỉ. Nó cũng không cần dịch địa chỉ trên máy chủ, nên đường hầm vẫn là một tuyến thuần. Nghĩa vụ mà nó tạo ra là tài liệu, vì bể, tuyến và cấu hình máy chủ phải khớp nhau.

Nó hỏng âm thầm vào ngày ai đó đổi bể. Hãy ghi giá trị một lần và coi việc sửa ở bất kỳ chỗ nào trong ba chỗ là sửa cả ba.

Một NAS hay switch lớp 3 lưu trữ dịch vụ cũng cần tuyến đó, trừ khi nó gửi mọi thứ qua một bộ định tuyến có tuyến ấy. Hãy kiểm tra thiết bị kết thúc mạng con, không chỉ thiết bị hướng ra internet. Mạng nhỏ thường có ba thiết bị có ý kiến riêng về định tuyến.

Câu hỏi hai: LAN có thể thôi nhìn thấy địa chỉ của máy khách không?

Khi bộ định tuyến thuộc về người khác, việc dịch trên máy chủ VPN không cần sự hợp tác. Máy trong LAN thấy địa chỉ LAN của máy chủ, trả lời nó, và máy chủ dịch ngược lại. Đó là lý do các thiết bị và vai trò truy cập từ xa dựa trên NAT hành xử như vậy.

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

Cái giá là khả năng quy trách nhiệm: địa chỉ theo từng máy khách biến mất khỏi log của LAN. Mọi danh sách cho phép trên máy trong LAN khi đó phải nêu tên máy chủ thay vì bể.

Hãy chọn phép dịch khi không có sự hợp tác, không phải khi nó chỉ bất tiện. Nó giấu máy khách khỏi mọi cuộc điều tra sau này, kể cả những lúc bạn cần biết máy tính xách tay nào đã mở kết nối. Nó cũng có thể phá các giao thức nhúng địa chỉ vào tải trọng, vì phép dịch nằm ở phần đầu gói. Không lựa chọn nào tiên tiến hơn; chúng trả lời hai câu hỏi khác nhau về quyền sở hữu.

Câu hỏi ba: máy chủ có phải là máy khách của một đường hầm khác không?

Hãy hình dung cấu trúc kia: máy chủ VPN cũng quay số tới một nhà cung cấp thương mại, nên nó có hai đường hầm và hai bộ địa chỉ. Lưu lượng nó chuyển tiếp cho máy khách của mình đi ra qua nhà cung cấp, và nhà cung cấp sẽ không định tuyến trả lời về địa chỉ của bể. Đó là lý do các trả lời biến mất dù cả hai đường hầm đều khỏe.

Cách khắc phục là masquerade cả đường hầm đi ra, để nhà cung cấp chỉ thấy địa chỉ đường hầm của máy chủ. Chiều ngược lại cần quy tắc riêng, vì máy chủ mở kết nối tới một trong những máy khách của chính nó là một luồng khác. Không có quy tắc đó, máy khách trả lời một địa chỉ mà nó không thể định tuyến. Hãy đặt quy tắc hẹp trước mọi masquerade rộng để phép dịch cụ thể thắng.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

Các máy có nhiều giao diện thêm một lỗi liên quan trông giống hệt từ phía máy khách. Gói trả lời đi ra qua giao diện có metric thấp hơn vì địa chỉ nguồn được chọn từ bảng khác. Hãy kiểm tra đường về bằng một lần tra cứu thay vì cho rằng đường đi đã bao hàm nó.

Sau đó kiểm tra cả hai chiều và cả hai kích thước

Sau khi thay đổi, ping từ máy khách tới một máy trong LAN rồi từ máy trong LAN trở lại máy khách. Chiều thứ hai là chiều người ta bỏ qua, và chính nó phơi ra một quy tắc dịch chưa đầy đủ. Ghi lại cả hai kết quả kèm dấu thời gian để một hồi quy sau này còn so sánh được.

Sau đó truyền dữ liệu thật, vì một ping nhỏ thành công trong khi một lần truyền lớn bị kẹt là triệu chứng MTU. Lỗi đó xuất hiện ngay sau khi bạn tự chúc mừng vì đã sửa được tuyến.

Cuối cùng, kiểm tra lại sau khi khởi động lại. Các lệnh tuyến và tường lửa lúc chạy không sống sót qua nó, và một bản sửa biến mất ở lần khởi động sau sẽ được ai đó ít ngữ cảnh hơn chẩn đoán lại. Hãy làm thay đổi bền vững theo cách hệ thống của bạn vốn làm, rồi khởi động lại một lần cho chắc.