Vì sao không thể truy cập subnet phía sau một máy khách OpenVPN?

Ping tới địa chỉ tunnel của máy chủ thành công, bảng tuyến của máy khách trông đúng, và LAN phía sau máy khách đó vẫn không thể truy cập. Bảng định tuyến của máy khách trông đúng, máy chủ có tuyến trỏ tới tunnel, và các gói tin vẫn biến mất. Đây là triệu chứng kinh điển của một tunnel layer-3 không biết rằng một trong các máy khách của nó cũng là cổng nối.

Một giao diện tun không có bước nhảy tiếp theo cho từng máy khách. Nhân chỉ thấy một giao diện với nhiều peer, nên quyết định máy khách nào sẽ nhận gói tin cho một LAN từ xa phải được đưa ra bên trong tiến trình OpenVPN. Quyết định đó được cấu hình bằng iroute, và nếu không có nó thì gói tin không có nơi nào để đi.

Máy chủ định tuyến theo máy khách, không theo giao diện

Khi máy chủ cần gửi một gói tin tới địa chỉ tunnel của một máy khách, câu trả lời là rõ ràng: địa chỉ thuộc về phiên của máy khách đó. Khi đích là cả một subnet phía sau máy khách đó, địa chỉ không thuộc về ai mà máy chủ biết, và tuyến của nhân tới tunnel chỉ nói "qua giao diện này", không nói peer nào.

OpenVPN giải quyết điều này bằng một bảng định tuyến nội bộ ánh xạ tiền tố đích tới một máy khách cụ thể. Bảng đó được xây từ các mục iroute, vì vậy một tuyến thông thường trên máy chủ không đủ. Tuyến của nhân đưa gói tin tới giao diện tunnel; ánh xạ nội bộ quyết định phiên nào nhận nó. Đó cũng là lý do việc sửa chữa không bao giờ xuất hiện trong đầu ra tuyến của nhân.

Nếu thiếu ánh xạ, gói tin đến máy chủ, khớp với tuyến tunnel và bị loại bỏ vì không máy khách nào nhận đích đó. Không có gì ghi lại một lỗi rõ ràng, nên sự cố trông giống một hố đen im lặng hơn là một vòng lặp định tuyến.

Viết mục iroute nêu tên máy khách

iroute sống trong tệp cấu hình riêng cho máy khách, không phải trong cấu hình chính của máy chủ. Trỏ máy chủ tới một thư mục bằng tùy chọn client-config-dir, sau đó tạo một tệp có tên là tên chung của chứng chỉ máy khách và đặt tiền tố vào bên trong.

Với một chi nhánh có LAN là 10.20.0.0/24 và tên chung của chứng chỉ là branch-router, tệp tại đường dẫn đó chứa một dòng như iroute 10.20.0.0 255.255.255.0. Cấu hình chính chỉ cần tùy chọn thư mục; tiền tố sống với máy khách.

Tên chung là phần mong manh. Một chứng chỉ được cấp với subject khác, hoặc một triển khai xác thực người dùng bằng tên người dùng trong khi tệp được đặt tên theo chứng chỉ, tạo ra một tệp không bao giờ được đọc. Hãy kiểm tra tên mà máy chủ thực sự báo cho phiên, và cân nhắc tùy chọn khiến một máy khách không khớp bị lỗi thay vì kết nối âm thầm mà không có tuyến của nó. Đổi tên tệp cho khớp với chứng chỉ là một sửa chữa năm phút giúp tránh một buổi tối rất dài.

Một máy khách có thể sở hữu nhiều tiền tố. Thêm một dòng iroute cho mỗi mạng, và giữ danh sách bên cạnh phần còn lại của cài đặt máy khách đó để ánh xạ vẫn có thể kiểm toán.

Xây tuyến quay về ở cả hai chiều

Đưa gói tin tới LAN từ xa là một nửa công việc. Máy khách cũng phải gửi lưu lượng của LAN đó vào tunnel, việc này thường được làm bằng cách đẩy một tuyến tới máy khách: một dòng như push "route 10.8.0.0 255.255.255.0" cho mỗi máy khách biết cách tới mạng ở phía máy chủ. Với chi nhánh, tuyến tương đương trỏ tới tunnel cho mọi thứ nó cần tới ở phía máy chủ.

Chiều quay về cần một chủ sở hữu ở phía xa. Ở phía đó, ai đó phải biết đường về: một tuyến tĩnh trên router LAN trỏ nhóm VPN tới máy chủ, hoặc dịch địa chỉ trên máy chủ trước khi lưu lượng vào LAN. Tuyến tĩnh giữ các địa chỉ gốc hiển thị trong nhật ký và quy tắc truy cập nhưng cần sự hợp tác của chủ sở hữu LAN; dịch địa chỉ tự túc nhưng che giấu ai thực sự đã kết nối.

Chuyển tiếp phải được bật trên máy chủ. Không có nó, nhân chấp nhận gói tin từ tunnel và từ chối chuyển nó tới giao diện LAN, điều mà từ góc nhìn của máy khách trông giống hệt một iroute bị thiếu.

Kiểm tra khả năng truy cập bằng các đầu dò thích hợp

Kiểm tra theo lớp thay vì ping đầu xa và đoán. Từ máy chủ, kiểm tra rằng ánh xạ nội bộ cho tiền tố tồn tại và tuyến của nhân trỏ tới tunnel. Từ máy khách, xác nhận rằng tuyến được đẩy đã được cài đặt và đường mặc định của nó tới địa chỉ LAN là tunnel.

Sau đó quan sát các gói tin. Một bản bắt trên giao diện tunnel cho thấy máy chủ có đang truyền về phía máy khách hay không, và một bản bắt trên giao diện LAN cho thấy nó có đang chuyển tiếp hay không. Nếu bản đầu cho thấy gói tin còn bản sau không có gì, vấn đề là chuyển tiếp hoặc một bộ lọc; nếu cả hai đều không cho thấy gì, việc tra cứu đã thất bại sớm hơn.

Hai máy chủ nối với nhau bằng một tunnel lặp lại cùng quy tắc ở cả hai phía: mỗi bên cần một iroute cho nhóm của bên kia, và mỗi bên cần tuyến cùng việc chuyển tiếp để đường đi đối xứng. Định tuyến và chính sách là những vấn đề riêng ở đây. Định tuyến quyết định gói tin có thể đi đâu, trong khi một quy tắc FORWARD quyết định nó có được phép hay không, nên một máy khách có hai dòng iroute tới được cả hai tiền tố trừ khi một bộ lọc nói khác.