Tiền tố công cộng qua OpenVPN: sửa đường trở về

Hãy xem đường hầm đi lên và máy khách ping phía bên kia, rồi một địa chỉ công cộng thuộc phía sau VPN trả lời từ nơi khác, hoặc không trả lời chút nào. Triệu chứng đó thường không liên quan gì đến mật mã hay chứng chỉ. Tiền tố do nhà cung cấp định tuyến được giao như một tuyến IP, và mang nó qua OpenVPN nghĩa là tái tạo tuyến đó ở hai tầng và giữ nguyên địa chỉ nguồn trên đường trở về. Không cần bắc cầu WAN, và việc thêm địa chỉ vào một giao diện không tạo ra tuyến thượng nguồn.

Tiền tố trước tiên phải được định tuyến đến bạn

Hỏi nhà cung cấp cách khối được giao. Một tiền tố được định tuyến đến địa chỉ chính của máy chủ bạn là chuyện khác với các địa chỉ mà nhà cung cấp mong đạt trực tiếp trên một phân đoạn WAN. Chỉ mô hình đầu tiên phù hợp với thiết kế ở đây.

Nếu nhà cung cấp định tuyến 198.51.100.64/28 đến máy chủ vào của bạn, các gói của dải đó đến máy chủ và dừng ở đó trừ khi bạn chuyển tiếp chúng. Nếu nhà cung cấp thay vào đó bắc cầu dải đó lên đường lên của bạn, máy chủ phải trả lời ARP cho nó, đây là vấn đề khác.

Kiểm tra mô hình giao nhận trước khi chạm vào OpenVPN: từ bên ngoài, ping một địa chỉ trong khối và xem giao diện nào nhận nó. Nếu không có gì đến, không cấu hình đường hầm nào giúp được. Nếu địa chỉ trả lời trực tiếp trên WAN, nhà cung cấp đang bắc cầu thay vì định tuyến, và thiết kế bên dưới không áp dụng.

Hai tầng định tuyến: tuyến nhân và iroute

OpenVPN cần tiền tố ở hai chỗ. Nhân phải biết rằng tiền tố thuộc thiết bị đường hầm, để các gói được chuyển tiếp đi vào OpenVPN thay vì tuyến mặc định. OpenVPN cũng phải biết máy khách đã xác thực nào sở hữu tiền tố, và đó là mục iroute trong thư mục riêng của máy khách.

Tuyến phía máy chủ trông như sau, với tiền tố và mặt nạ phải khớp với phân bổ:

ip route add 198.51.100.64/28 dev tun0

Cấu hình riêng của máy khách gán quyền sở hữu. Đặt nó trong tệp CCD được đặt tên theo tên chung của chứng chỉ máy khách, và xác nhận rằng chính thư mục đó là thứ máy chủ thực sự đọc:

iroute 198.51.100.64 255.255.255.240

Tài liệu của OpenVPN về mạng đã định tuyến mô tả cả hai tầng và lý do chúng tách biệt. Tuyến nhân không có iroute gửi gói vào đường hầm mà không có chủ, và OpenVPN loại bỏ chúng. iroute không có tuyến nhân để các gói trên đường mặc định của máy chủ. Cả hai lỗi đều trông giống một đường hầm hỏng từ phía máy khách.

Địa chỉ dịch vụ sống ở đâu

Tiền tố được ủy thác không giống địa chỉ của chính đường hầm. Đánh số liên kết từ không gian riêng nếu muốn, và đặt địa chỉ dịch vụ công cộng ở nơi dịch vụ thực sự chạy.

Trên một máy khách Linux kết thúc dịch vụ cục bộ, một địa chỉ máy chủ là đủ:

ip address add 198.51.100.70/32 dev lo

Nếu tiền tố được định tuyến tiếp đến một máy chủ VM hoặc LAN khác, hãy cấu hình thay vào đó đường xuống đó và tuyến trở về của nó. Không cần gán mọi địa chỉ trong khối cho máy khách VPN, và việc đó tạo xung đột về sau.

Giữ nguồn công cộng trên đường trở về

Phản hồi từ tiền tố được ủy thác phải ra khỏi đường hầm và đến tuyến của nhà cung cấp. Nếu máy chủ từ xa gửi nó qua ISP của chính nó, địa chỉ nguồn trông như bị giả mạo, và nhà cung cấp hoặc đích đến loại bỏ nó. Giải pháp là một quy tắc dựa trên nguồn hoặc một bảng định tuyến riêng, không phải một NAT rộng hơn. Không có nó, dịch vụ hoạt động từ đối tác đường hầm và thất bại từ mọi nơi khác.

Tại máy chủ vào, một quy tắc masquerade rộng là thủ phạm thường gặp. Nó ghi lại nguồn công cộng thành địa chỉ chính của máy chủ, và máy khách không bao giờ thấy địa chỉ thật:

iptables -t nat -S POSTROUTING

Giới hạn NAT cho những máy khách VPN riêng cần nó và để tiền tố được ủy thác không bị dịch. Sau đó xác nhận rằng máy chủ có chuyển tiếp tiền tố hay không, vì chuỗi chuyển tiếp từ chối mặc định sẽ âm thầm loại bỏ nó.

Xác minh cả hai chiều trước khi tin cậy

Xác minh là bốn quan sát, không phải một. Xác nhận rằng tuyến của nhà cung cấp đến, nhân gửi tiền tố vào đường hầm, OpenVPN gán nó cho đúng máy khách, và phản hồi quay về với nguồn công cộng còn nguyên. Mỗi quan sát có lệnh riêng, nên một lỗi chỉ ra một tầng chứ không phải toàn bộ thiết kế. Chạy chúng theo thứ tự đó sau mỗi thay đổi cấu hình.

Hỏi nhân xem một địa chỉ được ủy thác đi theo đường nào, và quan sát đường hầm trong khi một yêu cầu chạy:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Lọc đường ngược có thể vô hiệu một tuyến đúng. Kiểm tra cài đặt hiệu lực trên đường hầm và trên đường lên, và nhớ rằng chế độ nghiêm ngặt từ chối lưu lượng có nguồn không khớp với giao diện mà nó đi vào:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

Cuối cùng, kiểm tra trường hợp lỗi. Dừng đường hầm và xác nhận rằng tiền tố công cộng không rò rỉ qua đường lên thông thường. Khôi phục VPN sẽ đưa dịch vụ trở lại mà không mở rộng những cổng máy chủ phơi bày.