Vì sao phản hồi UDP của OpenVPN đi ra từ địa chỉ sai

Một ứng dụng khách OpenVPN quay số tới một địa chỉ, máy chủ trả lời từ một địa chỉ khác, và đường hầm không bao giờ dựng lên. Nhật ký máy chủ cho thấy gói tin đến và bản ghi cho thấy phản hồi đi ra, nên lỗi bị quy cho ứng dụng khách. Trên một máy chủ có nhiều giao diện, hoặc nhiều địa chỉ trên một giao diện, hai bên đơn giản là không thống nhất được địa chỉ nào đang được dùng. Phản hồi hợp lệ ở tầng IP, nhưng nhiều ứng dụng khách vứt bỏ datagram có nguồn không phải là địa chỉ mà chúng đã liên hệ.

Ứng dụng khách thấy gì khi nguồn thay đổi

Một socket UDP không gắn với một địa chỉ cục bộ cụ thể thì không có nguồn cố định, nên nhân hệ điều hành chọn một địa chỉ lúc gửi. Lựa chọn đó đến từ việc tra cứu tuyến đường tới địa chỉ của ứng dụng khách, và nguồn trở thành địa chỉ của giao diện mà bước tra cứu chọn. Trên máy chỉ có một giao diện, lựa chọn này không nhìn thấy được; trên máy chủ có địa chỉ quản trị, địa chỉ công cộng và địa chỉ phụ trên cùng một card mạng, nó phụ thuộc vào số đo tuyến đường và chính sách. Định tuyến theo chính sách khiến sự không khớp dễ xảy ra hơn chứ không phải ít hơn, vì một quy tắc có thể chọn tuyến thượng nguồn mà ứng dụng khách chưa từng đến. Chỉ cần một tuyến mặc định học từ một nhà cung cấp cộng với một quy tắc nguồn trỏ tới nhà khác là đủ để tạo ra tình huống này.

Những ứng dụng khách lọc phản hồi, và việc theo dõi kết nối đòi hỏi đúng bộ bốn và nguồn, sẽ bỏ phản hồi mà không có thông báo hữu ích. Sau đó đường hầm hết thời gian như thể không có gì đến, và đó là lý do tình huống này bị nhầm thành vấn đề tường lửa ở phía ứng dụng khách. Một bản ghi chỉ chụp trên máy chủ xác nhận lỗi thay vì giải thích nó, vì phản hồi thật sự đi ra. Hãy so sánh nguồn của phản hồi với địa chỉ mà ứng dụng khách đã quay số trước khi thay đổi bất cứ điều gì khác.

Tùy chọn multihome thực sự làm gì

Chỉ thị này được viết là multihome trong tệp cấu hình và là --multihome trên dòng lệnh, và nó khiến máy chủ UDP trả lời từ địa chỉ mà gói tin của ứng dụng khách đã đến. Nhân hệ điều hành chuyển địa chỉ đích ban đầu như dữ liệu phụ khi nhận, và OpenVPN dùng giá trị đó làm nguồn của phản hồi. Nhờ vậy một máy chủ lắng nghe trên địa chỉ ký tự đại diện, local 0.0.0.0 cho IPv4 hoặc tương đương IPv6 của nó, hành xử như thể mỗi ứng dụng khách đã đến một bộ lắng nghe riêng. Những ứng dụng khách đi vào qua địa chỉ công cộng nhận phản hồi từ địa chỉ công cộng, và ứng dụng khách trên địa chỉ nội bộ nhận phản hồi từ địa chỉ đó. Không có gì khác trên đường đi của gói tin dịch chuyển: tuyến đường, các quy tắc lọc và cấu hình đường hầm giữ nguyên như cũ.

Chính đặc tính cuối cùng này khiến tùy chọn an toàn khi thêm vào một máy chủ vốn đang chạy tốt, và cũng là lý do nó không thể sửa một bộ lọc chỉ cho phép một địa chỉ. Gói tin vẫn phải được chấp nhận trên đường đi mà nó đi, nên việc sửa nguồn chỉ thay đổi xuất xứ của phản hồi mà thôi. Nó cũng chỉ dành cho UDP: một bộ lắng nghe TCP không gặp vấn đề này ở cùng dạng, vì kết nối được nhận diện bằng bộ bốn chứ không phải địa chỉ nguồn của phản hồi.

Khi nào một địa chỉ cục bộ cố định là mặc định sai

Trước khi dùng tới tùy chọn, hãy kiểm tra xem máy chủ có gắn với một địa chỉ cục bộ cụ thể hay không, vì một bộ lắng nghe đã gắn luôn trả lời từ địa chỉ đó. Điều đó đúng với triển khai một giao diện và sai ngay khi ứng dụng khách sử dụng hợp pháp nhiều hơn một địa chỉ. Nếu việc gắn là có chủ ý, hãy quyết định xem máy chủ có nên nhận lưu lượng trên các địa chỉ bổ sung hay không. Bỏ việc gắn sẽ tăng mức phơi bày, nên các giao diện và mạng nguồn được phép phải do dịch vụ và bộ lọc thực thi, chứ không chỉ do địa chỉ gắn.

Tài liệu tham chiếu OpenVPN giới hạn tùy chọn này ở máy chủ UDP, ghi chú việc xử lý thêm trên đường đi của gói tin và ghi lại nền tảng nào hỗ trợ nó. Hãy xác nhận điều đó trên bản phát hành đã cài trước khi lập kế hoạch dựa vào nó. Ở nơi không được hỗ trợ, giải pháp thay thế là gắn địa chỉ cụ thể hoặc sửa tuyến hồi về, và cả hai đều là thay đổi hẹp hơn vẻ ngoài ban đầu. Lắng nghe trên địa chỉ ký tự đại diện còn có hệ quả ngoài phản hồi: một máy chủ trên mọi địa chỉ có thể truy cập từ mọi mạng mà máy chủ đó gắn vào, và đó có thể không phải mức phơi bày mà ai đó định trước.

Chứng minh nguồn của phản hồi từ bên ngoài

Hãy thử từ bên ngoài máy chủ, và ghi lại địa chỉ cùng phương thức vận chuyển chính xác mà ứng dụng khách đã dùng trước khi bắt bất cứ thứ gì. Ba phép kiểm tra dưới đây trả lời ba câu hỏi khác nhau, và thứ tự rất quan trọng.

tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20

Bản ghi cho thấy địa chỉ nguồn trên phản hồi, và đây là sự thật mà toàn bộ bài viết dựa vào. Danh sách socket cho thấy máy chủ thực sự đã gắn vào đâu, vì bộ lắng nghe ký tự đại diện và bộ lắng nghe cụ thể trông giống hệt nhau trong tệp cấu hình nhưng hành xử khác nhau trên mạng. Việc tra cứu tuyến đường cho thấy nguồn mà nhân hệ điều hành sẽ chọn cho luồng đó, và điều này giải thích bản ghi trước khi bạn thay đổi bất cứ thứ gì. Hãy lặp lại cả ba cho IPv4 và IPv6 riêng rẽ, vì chúng là những bộ lắng nghe riêng và những lần tra cứu riêng, và một mục ký tự đại diện cho một họ địa chỉ không nói gì về họ kia.

Định tuyến, khám phá và lọc vẫn tách biệt

Giữ nguyên nguồn của phản hồi không cài đặt tuyến đi ra, không cập nhật DNS động và không khiến một họ địa chỉ chấp nhận họ kia. Trên máy chủ có nhiều tuyến thượng nguồn, đường hồi về cho mỗi nguồn phải được thống nhất một cách có chủ ý, nếu không phản hồi sẽ đi ra qua một giao diện mà bộ lọc của ứng dụng khách chưa từng cho phép. Tương tự, địa chỉ mới sau khi đổi tiền tố phải đến được ứng dụng khách qua cơ chế khám phá và luồng kết nối lại được hỗ trợ, chứ không qua bản ghi cũ.

Hãy để các bước kiểm tra danh tính máy chủ và xác minh chứng chỉ y nguyên như cũ, vì một địa chỉ đã thay đổi không biện minh cho việc chấp nhận một đối tác chưa được xác minh. Nếu phản hồi nay đã đi ra từ nguồn dự kiến mà đường hầm vẫn thất bại, hãy coi vấn đề nguồn đã được giải quyết và đi tiếp. Lỗi quan sát được kế tiếp thuộc về định tuyến, lọc hoặc xác thực, và việc đổi bộ lắng nghe thêm lần nữa sẽ không chạm tới nó. Hãy ghi nguồn của phản hồi vào phiếu hỗ trợ bên cạnh địa chỉ mà ứng dụng khách đã quay số, để người tiếp theo có thể kiểm tra cùng sự thật đó bằng một lệnh.