Hai địa chỉ dịch vụ trên một máy khách OpenVPN: iroute và lo

Ứng dụng trả lời trên địa chỉ đường hầm của nó, còn địa chỉ bạn đã ghi lại cho nó thì không dẫn đến đâu cả. Không có gì trong nhật ký OpenVPN phàn nàn, peer hiện là đã kết nối, và hub liệt kê đúng một máy khách. Khoảng trống là địa chỉ thứ hai trên một máy khách là hai sự thật riêng biệt: máy chủ phải sở hữu nó, và hub phải biết peer nào sở hữu nó. Xử lý một mà không có cái kia thì lưu lượng hoặc chết tại hub hoặc đến mà không có tuyến về nhà.

Bí danh là cục bộ, quyền sở hữu là từ xa

Địa chỉ đường hầm được thương lượng, nên cả hai đầu học nó trong lúc bắt tay. Địa chỉ dịch vụ bổ sung hoàn toàn không được thương lượng, vì thế thêm nó không thay đổi gì ở hub tự nó. Máy khách có thể sở hữu địa chỉ ngay lập tức và máy chủ vẫn gửi lưu lượng đó theo tuyến mặc định hoặc bỏ nó. Phải tạo hai bản ghi, ở hai nơi khác nhau.

Trên máy khách, địa chỉ thuộc về máy chủ, và loopback là ngôi nhà tự nhiên cho một danh tính dịch vụ không bao giờ được xuất hiện trên một liên kết vật lý. Trên hub, ánh xạ peer-tới-tiền tố là một khai báo riêng mà chỉ máy chủ đọc. Không bản ghi nào hàm ý bản kia.

Cũng hãy giữ hai dải riêng biệt trong ghi chú của bạn. Địa chỉ trong ví dụ là giá trị tài liệu, và chồng chúng lên một LAN thật là cách nhanh nhất khiến một thiết lập đang chạy trông như hỏng.

Thêm địa chỉ trên máy khách một cách bền vững

Đặt địa chỉ dịch vụ trên loopback với tiền tố máy chủ, để máy chủ coi nó là đầu vào cục bộ chứ không phải một mạng con cần đến. ip address add 10.66.0.10/32 dev lo làm điều đó cho một địa chỉ, và lặp lại lệnh cho địa chỉ thứ hai mô hình hóa hai dịch vụ.

Chạy nó như một bài kiểm tra một lần, rồi chuyển vào thứ sở hữu cấu hình mạng của máy chủ, vì phần thêm lúc chạy biến mất khi khởi động lại và bản sao tích tụ giữa các lần kết nối lại. Một unit systemd được sắp xếp sau mạng là một lựa chọn, và trình quản lý mạng của bản phân phối là lựa chọn khác. Dù bạn chọn gì, địa chỉ phải tồn tại trước khi ứng dụng liên kết, nếu không dịch vụ khởi động trên socket sai. Xác minh bằng ip address show dev lo sau khi khởi động lại chứ không phải sau lệnh thủ công.

Liên kết là một quyết định tách khỏi việc đánh địa chỉ. Một ứng dụng lắng nghe trên mọi địa chỉ chấp nhận lưu lượng trên các giao diện bạn chưa bao giờ dự định, nên hãy trỏ nó vào địa chỉ dịch vụ cụ thể. Khi đó chính sách đầu vào cục bộ có thứ chính xác để khớp.

Yêu cầu nó trong tệp CCD mà hub thực sự đọc

Trên máy chủ, khai báo quyền sở hữu đi vào tệp cho từng máy khách được chọn bởi tên chung đã xác thực, bên trong thư mục được đặt tên bởi client-config-dir. Dòng là iroute 10.66.0.10 255.255.255.255, một dòng cho mỗi địa chỉ, và nó nói cho máy chủ biết peer nào sẽ nhận lưu lượng cho đích đó.

Hai chi tiết phá vỡ điều này một cách âm thầm. Tên tệp phải khớp với tên mà máy chủ thực sự dùng, tên này khác đi khi username-as-common-name đang được dùng. Và iroute chỉ có hiệu lực ở chế độ TUN với thư mục cấu hình máy khách được cấu hình, nên cùng dòng đó không làm gì trong triển khai cầu nối. Thêm dòng vào tệp hiện có thay vì thay thế nó, vì nó có thể đã mang một địa chỉ cố định hoặc tùy chọn push. Tài liệu tham chiếu OpenVPN 2.6 ghi lại cả thư mục và chỉ thị sở hữu.

Nhân của chính hub cũng cần một đường đến những đích đó để lưu lượng sinh ra cục bộ vào tiến trình đường hầm. route 10.66.0.10 255.255.255.255 trong cấu hình máy chủ bao phủ lưu lượng do chính máy chủ tạo ra, trong khi các máy khách khác cần push "route 10.66.0.10 255.255.255.255" để tự học đích.

Định tuyến và cấp quyền vẫn tách biệt. Một tuyến được đẩy nói cho máy khách biết gửi gói đi đâu và không cấp gì cả; dịch vụ vẫn phải chấp nhận bên gọi theo điều kiện của chính nó.

Kiểm tra chính sách đầu vào và đường phản hồi

Một gói được gửi đến bí danh đi đến máy chủ sở hữu như đầu vào cục bộ, nên câu hỏi là liệu tường lửa cục bộ có cho phép nguồn và cổng đó không. Cho phép cổng dịch vụ cụ thể từ dải nguồn VPN thay vì mở toàn bộ địa chỉ.

Các phản hồi cần một đường quay về bên gọi. Với bên gọi trong nhóm đường hầm bình thường, đường đó đã tồn tại vì thiết bị đường hầm mang nó. Bên gọi phía sau một mạng được định tuyến khác cũng cần tuyến quay về của mạng đó, và đây là nơi các thiết lập bất đối xứng làm mất gói.

Coi chừng một trình lắng nghe thứ hai trên cùng cổng được gắn với địa chỉ khác, vì nhân chuyển đến socket khớp và kết quả trông ngẫu nhiên. Kiểm tra bằng ss -lntp và xác nhận rằng địa chỉ được gắn là bí danh dịch vụ. NAT nguồn không cần thiết ở đây, và thêm nó sẽ giấu danh tính bên gọi mà nhật ký của bạn phụ thuộc vào.

Kiểm tra địa chỉ và quyền sở hữu riêng biệt

Kiểm tra theo hai bước. Đầu tiên xác nhận máy chủ sở hữu có thể đến dịch vụ trên bí danh của nó từ chính nó, điều này tách vấn đề liên kết và tường lửa khỏi định tuyến. Sau đó kiểm tra từ một bên gọi VPN thật dùng xác thực của chính ứng dụng. Khi bước đầu qua và bước hai thất bại, phần còn thiếu nằm ở phía hub.

Cũng kiểm tra các chế độ hỏng tồn tại sau kết nối: bí danh vẫn được gán khi đường hầm xuống, và hub giữ tuyến của nó khi peer vắng mặt. Không đối tượng nào một mình chứng minh dịch vụ có thể đến được, nên bài kiểm tra hai bước thắng một lần ping từ máy tính xách tay.