Một Pi, hai phiên bản OpenVPN: mỗi unit đọc gì
Hai daemon OpenVPN trên một Pi đọc các tệp cấu hình khác nhau và đi ra qua các hook khác nhau. Hãy lập bản đồ từng phiên bản, rồi kiểm tra riêng đường đi của payload.
Đếm các tiến trình OpenVPN trước khi chạm vào một hồ sơ. Một Pi vừa nhận người dùng chuyển vùng vừa quay số tới dịch vụ thượng nguồn sẽ chạy hai daemon, và mỗi daemon đọc tệp cấu hình do tên phiên bản bạn gõ chọn. Các mẫu của gói sau đó cấp cho mỗi daemon thư mục làm việc riêng, tệp trạng thái chạy riêng và thiết bị tunnel riêng. Nếu chia sai, bạn sẽ mất cả buổi tối sửa một thiết lập đúng trong tệp mà tiến trình đang chạy không bao giờ mở.
Mỗi tên phiên bản chọn tệp của riêng nó
Trong các tệp unit đi kèm OpenVPN 2.6, đối số khởi động mang một chỗ giữ chỗ phiên bản được điền từ văn bản sau dấu @. Mẫu máy chủ chạy từ thư mục cấu hình máy chủ và phân giải đối số của nó với %i.conf ở đó, còn mẫu máy khách làm điều tương tự từ thư mục máy khách. Vì vậy [email protected] đọc admits.conf trong thư mục máy chủ và [email protected] đọc uplink.conf trong thư mục máy khách, và không tên nào trong số đó có ý nghĩa gì trong thư mục kia.
Xác nhận ánh xạ ngay trên máy thay vì cho rằng gói đã giữ các giá trị mặc định thượng nguồn. Một drop-in của bản phân phối được phép thay thế hoàn toàn thư mục làm việc hoặc đối số cấu hình.
systemctl cat [email protected]
systemctl cat [email protected]Đọc dòng WorkingDirectory và đối số cấu hình trong đầu ra đó, vì chỉ unit được bật mới quyết định tệp nào được nạp. Một drop-in thêm --config vào ExecStart sẽ thắng mẫu ngay cả khi đường dẫn của mẫu trông đúng. Hãy hỏi đường dẫn của fragment và drop-in khi bạn muốn biết có ghi đè cục bộ hay không. Nếu cả hai vai trò phân giải về một tệp duy nhất, bạn có một tiến trình đang cố vừa là máy chủ vừa là máy khách, và tùy chọn sau trong tệp đó lặng lẽ thắng.
Vận chuyển cục bộ và payload chuyển tiếp gặp các hook khác nhau
Kết nối được mã hóa của máy chủ tới từng người dùng chuyển vùng được tạo ngay trên Pi, nên các trả lời bên ngoài của nó đi ra qua hook đầu ra cục bộ. Kết nối của máy khách tới đối tác thượng nguồn cũng là đầu ra được tạo cục bộ, dù nó tới một mạng từ xa. Payload được chuyển tiếp là loại thứ ba, và kernel chỉ khớp nó sau khi đã chọn thiết bị đi ra cho gói tin.
| Flow | Hook that sees it | What to inspect |
|---|---|---|
| Roaming user handshakes to the server | Local input and local output | Listener socket, bind address, rule admitting the UDP port |
| User payload leaving through the upstream tunnel | Forward | IPv4 forwarding switch, selected route, permission rule, any translation |
| Pi's own connection to the upstream peer | Local output | Underlay route to the provider endpoint, not the tunnel route |
Một quy tắc khớp giao diện đi ra bên trong chuỗi forward có thể cho phép hoặc bỏ một gói tin mà định tuyến đã gán cho giao diện đó, nhưng nó không bao giờ chọn giao diện. Khi một máy chủ kết thúc tunnel này và bắt đầu tunnel khác, chính sách đưa payload người dùng vào tunnel thượng nguồn và chính sách bảo vệ các trả lời được mã hóa của chính Pi là hai quyết định riêng. Chúng tình cờ nằm trên cùng một NIC vật lý, đó là lý do chúng bị nhầm lẫn.
Sự khác biệt đó giải thích một lỗi nửa vời phổ biến. Người dùng kết nối, bắt tay hoàn tất, và lưu lượng của họ vẫn đi ra sai đường, vì bắt tay là cục bộ còn payload là forward và chỉ một trong hai từng được kiểm tra.
Tuyến được nhập có thể nuốt trả lời gửi tới người dùng của bạn
Thiết lập bảo mật của hồ sơ máy khách quyết định thượng nguồn được đẩy gì vào bảng định tuyến của Pi, và chuyển hướng rộng là tùy chọn biến một máy chủ hai vai đang chạy tốt thành hỏng. Nếu tuyến được đẩy bao trùm địa chỉ công cộng của người dùng chuyển vùng, các trả lời mà máy chủ tạo cho họ có thể đi theo tuyến mới vào tunnel thượng nguồn thay vì đi ra qua underlay. Người ta thường xác nhận tunnel tới nhà cung cấp vẫn chạy rồi dừng ở đó, vì lưu lượng đó là vận chuyển của chính tunnel và vẫn tiếp tục chảy trong khi mọi thứ khác hành xử sai.
Chính sách dựa trên nguồn hoặc mark là cách giữ hai luồng tách nhau. Tùy chọn mark Linux của OpenVPN đánh dấu các gói tin được mã hóa của daemon bằng mark tường lửa, mà một quy tắc định tuyến sau đó có thể gửi vào bảng riêng. Địa chỉ nguồn cũng hiệu quả tương đương khi trả lời bên ngoài của máy chủ luôn đi ra từ một địa chỉ underlay duy nhất. Cả hai cách đều cần tuyến hợp lệ trong bảng mà nó chọn và một ngoại lệ cho endpoint của nhà cung cấp, nếu không chính tunnel sẽ không dựng lên.
Hỏi kernel xem một trả lời thực sự sẽ đi theo đường nào trước khi viết bất kỳ quy tắc nào. Các địa chỉ bên dưới là chỗ giữ chỗ cho địa chỉ underlay của Pi và địa chỉ công cộng của một người dùng chuyển vùng.
ip rule show
ip route get 198.51.100.7 from 192.0.2.10Xác minh việc tách, rồi dừng từng vai một
Kiểm tra ba luồng riêng rẽ, vì một bắt tay thành công không chứng minh gì về hai luồng còn lại. Chấp nhận một kết nối vào mới, gửi một ứng dụng được phép qua lối ra thượng nguồn và xác nhận rằng cả hai tiến trình vẫn tới đối tác của mình.
Sau đó dừng vai trò máy khách và xem vai trò máy chủ giữ lại gì. Đây là cách rẻ nhất để tìm một quy tắc tuyến hoặc mark vốn dành cho một phiên bản nhưng lại áp cho cả hai.
systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pagerĐiều bạn muốn thấy là listener vẫn được gắn, thiết bị tunnel vẫn hiện diện và nhật ký không có lỗi mới khi vai trò máy khách đã dừng. Nếu dừng máy khách cũng cắt các trả lời của máy chủ tới người dùng hiện có, hai vai trò đang chia sẻ thứ gì đó lẽ ra chỉ thuộc một trong hai. Ghi lại thay đổi nào đã chạm vào phiên bản nào, tệp cấu hình nào và chủ luồng nào, nếu không người tiếp theo gỡ lỗi máy chủ này sẽ lặp lại đúng phát hiện đó từ đầu.