OpenVPN sau stunnel: chuyển tiếp lớp bọc, không phải cổng 1194

Đặt một lớp bọc TLS trước OpenVPN và bản triển khai có thêm trình lắng nghe thứ hai, trong đó chỉ một cái nên hướng ra internet. Khi đường hầm chạy được từ cùng một máy mà thất bại từ bên ngoài, chuyển tiếp thường nhắm vào cái sai trong hai. Điều phải khớp là một chuỗi: quy tắc công khai tới được lớp bọc, và kết nối backend riêng của lớp bọc tới được ổ cắm VPN thật. Bốn bước nhảy mang chuỗi đó, và bất kỳ bước nào cũng có thể kết thúc cuộc điều tra sớm.

Hai ổ cắm, hai chủ sở hữu, một cái công khai

Lớp bọc kết thúc TLS cho kết nối bên ngoài và chuyển luồng byte đã giải mã cho một trình lắng nghe OpenVPN TCP thông thường. Đây là các ổ cắm riêng biệt với các tệp cấu hình riêng biệt, nên việc sửa cái này để cái kia không bị chạm tới và vẫn trông khỏe mạnh. Điều đó cũng có nghĩa là hai cái có thể trôi xa nhau mỗi khi một cái bị thay đổi mà không có cái kia.

Làm việc từ chính máy đó chứng minh rất ít về đường đi công khai. Kết nối trực tiếp tới cổng gốc bỏ qua lớp bọc, kết nối tới lớp bọc trên địa chỉ LAN của nó bỏ qua bản dịch, và chỉ cách bố trí đầy đủ phía máy khách mới thực hành điều người dùng bên ngoài làm. Tên cũng cần được đọc cẩn thận, vì localhost nghĩa là máy chủ đang chạy đúng thành phần đó chứ không phải máy chủ bạn tình cờ gõ trên đó. Hãy giữ sự phân biệt đó trong ghi chú của bạn, vì một bài kiểm tra được ghi lại mà không nêu bước nhảy nó bao phủ sẽ mời gọi so sánh hai thứ khác nhau.

Chuyển tiếp thực sự đáp ở đâu

Chuỗi dễ giữ như bốn bước nhảy hơn là ba số cổng, vì cùng một số có thể mang nghĩa khác nhau ở mỗi đầu. Đọc bảng theo từng hàng: mỗi hàng là một ổ cắm phải nhận một kết nối rồi mở cái tiếp theo. Khi một hàng nhắm vào đối tác sai, triệu chứng ở cột cuối chính là điều người dùng báo lại.

Một quy tắc nhắm vào cổng VPN gốc thay vì lớp bọc bỏ qua hoàn toàn việc kết thúc TLS, và đó là dạng phổ biến nhất của lỗi này: máy khách mở bắt tay với một trình lắng nghe đang chờ khung OpenVPN, nên kết nối có thể mở rồi đứng lại. Xác nhận cổng đã dịch với tệp cấu hình của lớp bọc chứ không phải với trí nhớ, vì người tiếp theo sửa tệp đó có thể đã chọn một số khác. Hai lệnh dưới đây cho thấy cả hai mặt của câu hỏi đó cùng lúc.

grep -nE '^[[:space:]]*(accept|connect)' /etc/stunnel/stunnel.conf
ss -lntp | grep -E ':443|:8443|:1194'

Địa chỉ ràng buộc từ chối bạn

Một dòng accept ràng buộc với 127.0.0.1 chỉ trả lời chính máy chủ, nên chuyển tiếp đến địa chỉ LAN không kết nối được và máy khách thấy một sự từ chối nghe như vấn đề bộ lọc gói. Hãy xem ổ cắm trước khi chạm vào tường lửa, vì ổ cắm là câu trả lời rẻ hơn. Hoặc ràng buộc lớp bọc với giao diện mà chuyển tiếp nhắm tới, hoặc giữ nó trên loopback và làm cho chuyển tiếp tới được loopback qua một thứ thực sự hoạt động. Đó là hai thiết kế, và mỗi cái cần quy tắc riêng.

Trộn chúng với nhau là cách một lớp bọc đang chạy trở nên không thể tới từ bên ngoài trong khi mọi tệp trông đúng. Phép kiểm tra dưới đây là một lệnh duy nhất, và nó trả lời một câu hỏi mà việc xem lại các quy tắc tường lửa không thể. Nếu đầu ra cho thấy địa chỉ loopback trong khi chuyển tiếp nhắm vào địa chỉ LAN, thì bản sửa thuộc về dòng accept chứ không phải bộ lọc gói.

ss -lntp '( sport = :8443 )'

Bài kiểm tra cục bộ thực sự đã chứng minh điều gì

Một thành công được ghi lại mà không nêu bước nhảy mà nó đã bao phủ không phải là bằng chứng về các bước nhảy khác. Ghi lại bài kiểm tra đã dùng địa chỉ nào và tiến trình nào đã trả lời. Sau đó lặp lại từ bên ngoài mạng chứ không phải từ điện thoại trên cùng Wi-Fi, vì hành vi kẹp tóc khác nhau giữa các router và một kết nối chưa bao giờ rời LAN vẫn có thể làm hài lòng máy khách mà chuyển tiếp hoàn toàn không tham gia. Chỉ lần thử thứ hai đó mới luyện tập con đường mà người lạ đi.

Khi lần thử thất bại, hãy theo một kết nối duy nhất qua cả hai nhật ký: các dòng chấp nhận và đã kết nối của lớp bọc, rồi nhật ký phiên của daemon VPN. Ranh giới đầu tiên không ghi lại gì chính là nơi thay đổi tiếp theo thuộc về. Khi OpenVPN bắt đầu so sánh các tùy chọn đối tác, hãy đánh giá những thông điệp đó theo quy tắc của bản triển khai đó. Cảnh báo không nhất quán link-mtu không tự động gây chết, ghim link-mtu ở 1500 không chứng minh rằng phân mảnh đã dừng, và việc thương lượng mật mã thuộc cấu hình bên trong OpenVPN chứ không phải chuyển tiếp của router.

nc -vz 127.0.0.1 1194
journalctl -u stunnel -n 50 --no-pager

Các phép dò đó bao phủ ổ cắm backend và nhật ký lớp bọc, điều này tách một backend bị từ chối khỏi một bắt tay bị từ chối. Hãy chạy chúng trong khi một lần thử đang diễn ra chứ không phải sau đó. Dấu thời gian của một lần thử là thứ khiến so sánh đáng tin cậy.

Hai danh tính, hai thứ tự thất bại

Chứng chỉ bên ngoài thuộc về lớp bọc và danh tính bên trong thuộc về OpenVPN, và chúng có thể đến từ các cơ quan khác nhau. Tắt một trong hai phép kiểm tra để một con đường trông khỏe mạnh là đánh đổi sự bảo vệ thật lấy một kết quả bề ngoài. Giữ cả hai phép xác minh và gỡ lỗi theo thứ tự, vì trình tự thông điệp gọi tên lớp: sự cố chứng chỉ của lớp bọc xuất hiện trước khi bất kỳ tùy chọn VPN nào được thương lượng, còn thất bại danh tính bên trong chỉ xuất hiện sau khi luồng được thiết lập.

hướng dẫn stunnel định nghĩa chính xác accept, connect và chế độ máy khách, và những mục đó trả lời câu hỏi về ổ cắm nhanh hơn đoán. Khi bạn vẫn chưa thể nói lớp nào đã trả lời, hãy đọc chứng chỉ mà cổng công khai trình bày bằng lệnh dưới đây. Có chứng chỉ của lớp bọc trong đầu ra nghĩa là chuyển tiếp đã tới lớp bọc, còn im lặng hoặc lỗi giao thức nghĩa là chưa tới. Khác biệt duy nhất đó tiết kiệm nhiều thời gian hơn bất kỳ phép kiểm tra nào khác ở đây.

openssl s_client -connect vpn.example:443 -servername vpn.example </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer