Cổng VPN tự lưu trữ trang quản trị của chính nó: địa chỉ bên trong hay công khai

Trang quản trị trả lời từ điện thoại trên dữ liệu di động và hết thời gian từ máy tính xách tay đã tham gia VPN. Không có gì hỏng trong đường hầm, vì yêu cầu không bao giờ đi vào đó. Tên máy chủ phân giải thành địa chỉ công khai của cổng, và địa chỉ đó chỉ chạm tới được từ bên ngoài đường hầm mà nó kết thúc. Sửa điều này nghĩa là cho dịch vụ một lối vào riêng tư, chứ không phải di chuyển điểm cuối bên ngoài.

Trang tải từ bên ngoài chứ không qua đường hầm

Hai yêu cầu khác nhau đang được so sánh. Từ dữ liệu di động, trình duyệt chạm thẳng tới địa chỉ công khai. Từ bên trong đường hầm, cùng tên đó phân giải thành cùng địa chỉ công khai, và gói tin giờ phải đi ra qua đường hầm để chạm tới một địa chỉ ở phía xa của chính đường hầm. Cùng tên, cùng địa chỉ, hai vị trí rất khác nhau.

Tuyến đích chọn một địa chỉ, không chọn cổng. Không có gì trong bảng định tuyến biết rằng cổng 443 dành cho quản trị và cổng 1194 là vận chuyển, nên cả hai được coi là cùng một đích.

Đó là lý do trang đôi khi hoạt động và đôi khi không, tùy thuộc tên và mạng mà máy khách đã dùng. Đây là vấn đề đường đi chứ không phải vấn đề xác thực. Cả hai máy khách đều xác thực tốt.

Giữ điểm cuối bên ngoài luôn chạm tới được

Hồ sơ đường hầm đầy đủ cần một tuyến ngoại lệ cho điểm cuối VPN, và tùy chọn redirect-gateway của OpenVPN ghi lại đúng điều đó: điểm cuối từ xa giữ một tuyến qua cổng đã tồn tại trước để đường hầm không định tuyến vào chính nó. Bỏ ngoại lệ đó đi và vận chuyển được mã hóa sẽ đi theo đường hầm, khiến phiên kết thúc trong một vòng lặp. Chính ngoại lệ đó là lý do địa chỉ điểm cuối vẫn chạm tới được từ bên trong đường hầm.

Hệ quả là địa chỉ công khai vẫn chạm tới được từ máy khách, và đó cũng là lý do một yêu cầu của trình duyệt tới địa chỉ đó có thể đi theo cùng ngoại lệ và ra ngoài mà không vào đường hầm. Ngoại lệ đang làm việc của nó, và cái tên mới là thứ gây hại.

Hãy đọc quyết định tuyến chứ không phải danh sách giao diện trước khi thay đổi bất cứ điều gì. Các lệnh bên dưới in ra quyết định chứ không phải bản kiểm kê. Chạy chúng từ máy khách đã thất bại.

ip -4 route get 203.0.113.77
ip -4 rule show
ip -4 route show table all

Nếu tra cứu cho thấy tuyến điểm cuối đi qua cổng vật lý, hành vi là đúng và trang quản trị chỉ đơn giản bị gửi sai đường. Đó là điểm mà việc phân giải tên trở thành cách sửa.

Cho dịch vụ một tên riêng tư

Dịch vụ cần một tên phân giải thành địa chỉ của cổng bên trong đường hầm, đồng thời giữ nguyên ngữ nghĩa chứng chỉ và tên máy chủ mà ứng dụng mong đợi. Một bản ghi vùng riêng tư cho tên quản trị là câu trả lời thông thường, và nó để tên vận chuyển không bị đụng tới.

Đừng trỏ lại tên vận chuyển vào địa chỉ bên trong, vì lần thiết lập đường hầm tiếp theo sẽ cố chạm tới một địa chỉ chỉ tồn tại bên trong đường hầm. Sai lầm đó tạo ra một VPN chỉ hoạt động đúng một lần.

Cũng hãy kiểm tra cả hai họ địa chỉ, vì một bản ghi AAAA bị bỏ lại có thể gửi trình duyệt tới nơi mà kế hoạch riêng tư chưa bao giờ phủ tới.

dig +short admin.hq.internal
dig +short -t AAAA admin.hq.internal
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://admin.hq.internal/

Khớp chính sách với nơi tiến trình chạy

Một tiến trình gốc lắng nghe trên cổng được chạm tới qua đường vào cục bộ, nên chuỗi đầu vào và việc gắn kết ổ cắm quyết định yêu cầu có được chấp nhận hay không. Các quy tắc chuyển tiếp và chuyển tiếp IP không làm một trình lắng nghe cục bộ trả lời. Cho phép các nguồn của đường hầm trong chính sách đầu vào và xác nhận tiến trình được gắn vào một địa chỉ mà đường hầm có thể chạm tới.

Một vùng chứa được công bố trên cổng của máy chủ đi theo đường khác, vì gói tin được dịch đích và chuyển tiếp. Yêu cầu đó gặp chính sách chuyển tiếp của máy chủ và các quy tắc riêng của Docker, nên một trình lắng nghe gốc đang hoạt động có thể cùng tồn tại với một vùng chứa từ chối cùng cổng.

Thứ tự khởi động quan trọng trong cả hai trường hợp, vì việc gắn vào một địa chỉ chỉ xuất hiện sau khi đường hầm lên sẽ thất bại âm thầm khi khởi động.

Kiểm tra truy cập riêng tư và một đường công khai bị từ chối

Thực hiện một yêu cầu có tên mới từ máy khách được ủy quyền với các kiểm tra danh tính của chính ứng dụng còn nguyên vẹn. Sau đó thử cùng dịch vụ từ bên ngoài đường hầm và xác nhận nó không trả lời. Một tên riêng tư là tiện lợi chứ không phải hạn chế, và một trình lắng nghe vẫn gắn vào địa chỉ công khai thì vẫn bị phơi bày. Chính lần kiểm tra cuối đó là thứ mà hầu hết các đánh giá bỏ qua.

Đọc các liên kết và trạng thái bộ lọc chứ không phải tên máy chủ mà người dùng nhận được. Phơi bày là thuộc tính của ổ cắm chứ không phải của tên. Sự phân biệt đó sống sót qua mọi thay đổi DNS.

ss -lntp | grep ':443'
nft list ruleset | grep -n 443
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://203.0.113.77/

Khi yêu cầu bên trong trả về trang và yêu cầu bên ngoài hết thời gian, dịch vụ có một đường riêng tư có chủ đích và vận chuyển vẫn chạm tới được. Khi yêu cầu bên ngoài vẫn trả lời, trình lắng nghe hoặc một mục vùng chứa đã công bố cần được thu hẹp trước khi ai đó mô tả dịch vụ là chỉ nội bộ.