Router LAN và máy khách VPN: hai thiết bị, hai bảng định tuyến

Hai thiết bị chuyển tiếp gói tin và mỗi thiết bị giữ bảng riêng của mình. Router LAN biết rằng tiền tố từ xa thuộc về máy khách VPN, và máy khách VPN biết cách đến tiền tố đó qua đường hầm của nó. Chỉ cấu hình bảng thứ nhất và gói tin đến một máy không có tuyến phù hợp, nên nó lại đi ra theo tuyến mặc định. Đó là toàn bộ lỗi, và từ phía LAN nó trông như một vòng lặp định tuyến, vì gần như đúng là vậy.

Vẽ hai bước nhảy trước khi chạm vào một tuyến

Lấy một bố cục minh họa: các máy chủ LAN trên 192.168.50.0/24, router thông thường trên 192.168.50.1, một máy khách chuyên dụng trên 192.168.50.15 và một LAN từ xa trên 10.60.0.0/24 chỉ tiếp cận được qua đường hầm mà máy khách đó giữ. Không dải riêng nào trong hai dải chồng lên dải kia, và đường hầm có kế hoạch địa chỉ riêng.

Cả hai dải riêng đều quan trọng vì chúng quyết định thiết bị nào có thể trả lời. Phía từ xa sẽ thấy gói tin đến từ địa chỉ đường hầm của máy khách, và câu trả lời phải tìm được đường quay về 192.168.50.0/24. Nếu chỉ cấu hình hướng đi ra, yêu cầu có thể hoạt động trong khi câu trả lời biến mất.

Bước 1: hướng router về phía máy khách, không phải về phía đường hầm

Trên router LAN, thêm một tuyến đích có bước nhảy tiếp theo là địa chỉ LAN của máy khách:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

Bản ghi đó nói “hãy giao nó cho máy có thể tạo đường hầm”. Nó không nói gì về cách đường hầm được xây dựng, và nó không thay thế tuyến riêng của máy khách. Trên router được quản lý, tương đương nằm ở trang tuyến tĩnh của thiết bị; trên router Linux, nó thuộc cấu hình giao diện sở hữu LAN, không phải một shell mà bạn sẽ đóng.

Kiểm tra câu trả lời của lệnh thứ hai. Nếu nó báo máy khách là gateway và giao diện LAN là device, bước nhảy đầu tiên là đúng và phần việc còn lại nằm ở máy kia.

Bước 2: cho máy khách một tuyến riêng ở phía đường hầm

Máy khách giờ nhận một gói tin cho 10.60.0.0/24 và tra bảng riêng của nó. Nếu cấu hình đường hầm đã cài một tuyến cho tiền tố đó, gói tin tiếp tục được mã hóa. Nếu không, gói tin khớp với tuyến mặc định thông thường và quay về 192.168.50.1, nơi gửi nó lại cho máy khách.

Hãy xem trước khi thêm bất cứ thứ gì:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

Thiếu tuyến tiền tố trong mọi bảng chính là phát hiện mà bạn đang tìm. Hãy thêm nó qua cấu hình riêng của đường hầm, để lần kết nối lại tiếp theo cài đặt lại nó; một ip route add thủ công biến mất cùng phiên và khiến lỗi quay lại vào lúc bất tiện nhất. Bước nhảy tiếp theo là giao diện đường hầm hoặc địa chỉ mà VPN gán làm đối tác của nó, tùy máy khách, và địa chỉ đối tác nên lấy từ hồ sơ hiện tại chứ không phải từ ghi chú cũ.

Vòng lặp, khi xảy ra, trên thực tế không vô hạn: TTL giảm sau mỗi lượt và gói tin chết với thông báo quá thời gian. Đó là lý do một traceroute lặp lại có thể gợi ý một chu trình trong khi một máy khách chỉ đơn giản không chuyển tiếp lại âm thầm bỏ gói tin đó.

Bước 3: cho phép chuyển tiếp và chọn đường quay về

Nhận và chuyển tiếp là những quyền khác nhau. net.ipv4.ip_forward=1 trên máy khách cho phép đi qua ở mức nhân, và một quy tắc tường lửa vẫn phải cho phép nó giữa giao diện LAN và đường hầm. Một quy tắc cho phép truy cập trang quản trị của chính máy khách sẽ không cho phép đi qua tới LAN từ xa, và sự khác biệt này dễ bị bỏ qua khi cùng một máy chủ trả lời ping tại chỗ.

Phía từ xa có vấn đề như hình phản chiếu. Nó phải biết rằng 192.168.50.0/24 tiếp cận được qua máy khách đã xác thực này. Với OpenVPN điều đó thường có nghĩa là một tuyến cho từng máy khách do cấu hình máy chủ đẩy xuống, hoặc một tệp riêng cho máy khách trên máy chủ khai báo LAN phía sau máy khách. Không có nó, LAN từ xa hoặc bỏ câu trả lời hoặc gửi nó tới cổng mặc định của chính nó, tức là internet.

Dịch địa chỉ nguồn là phương án thay thế khi không thể quảng bá tiền tố LAN. Một quy tắc masquerade có phạm vi trên máy khách ghi lại nguồn thành địa chỉ đường hầm, và các câu trả lời khi đó quay về một cách tự nhiên. Nó cũng che đi máy chủ LAN nào đã gửi yêu cầu, và tự nó không cho phép phía từ xa khởi tạo kết nối vào trong. Hãy chọn sự đánh đổi đó một cách có chủ đích thay vì thêm một masquerade toàn bộ rồi phát hiện tác dụng phụ sau.

Bước 4: biến cả hai quyết định thành lâu dài, rồi kiểm tra đường thật

Mỗi tuyến có một chủ sở hữu, và chủ sở hữu là cấu hình được tạo lại khi khởi động hoặc khi kết nối lại. Trên router đó có thể là một mục tuyến tĩnh; trên máy khách đó có thể là hồ sơ VPN, NetworkManager hoặc systemd-networkd. Hãy xác minh bằng cách kết nối lại đường hầm và khởi động lại máy khách, rồi đọc lại bảng thay vì tin vào chỉnh sửa.

Giữ nguyên tuyến mặc định mang kết nối bên ngoài của đường hầm. Thay thế nó để “đơn giản hóa” thiết lập sẽ phá vỡ đường được mã hóa trước khi bất kỳ lưu lượng bên trong nào dùng được nó, và triệu chứng là một đường hầm không bao giờ thiết lập lại sau thay đổi.

Hãy kiểm tra từ một máy chủ LAN thông thường, không phải từ máy khách, vì một yêu cầu phát sinh trên máy khách không bao giờ dùng bước nhảy đầu tiên của router. Lấy một dịch vụ chỉ tồn tại trên LAN từ xa và xác nhận nội dung trả lời, rồi xem bộ đếm hoặc nhật ký của máy khách để thấy việc đi qua diễn ra. Một traceroute bên trong hiển thị các bước nhảy riêng chứng minh việc chuyển tiếp, không phải mã hóa: đường bên ngoài là một quan sát riêng, và chỉ bộ đếm giao diện của chính đường hầm mới cho thấy những gì đã ra qua nó.