Vì sao URL của bạn cần lối vào trên cổng 80 hoặc 443, không phải 45000

Gõ một tên máy chủ vào trình duyệt và lược đồ quyết định cổng đích: 80 cho http, 443 cho https. Không gì trong câu trả lời DNS ghi đè điều đó, và không quy tắc chuyển tiếp nào trên máy bạn có thể bịa ra một trình lắng nghe ở rìa nhà cung cấp. Khi nhà cung cấp VPN cấp cho bạn một cổng công khai cao như 45000, URL tường minh hoạt động còn URL sạch thì không. Khoảng trống nằm ở điểm vào, không nằm trong ứng dụng.

Đi qua đường từ trình duyệt đến tiến trình một lần, và ba lựa chọn công bố sẽ không còn bí ẩn.

Xem yêu cầu thực sự đi đâu

Trình duyệt phân giải tên thành địa chỉ, rồi kết nối đến địa chỉ đó trên cổng mặc định của lược đồ trừ khi URL nêu cổng khác. Rìa của nhà cung cấp quyết định điều gì xảy ra với kết nối đang đến. Nếu bảng chuyển tiếp của nó chỉ ánh xạ 45000 tới địa chỉ nội bộ của bạn, kết nối tới 80 không có nơi nào để đi và bị từ chối hoặc bị bỏ trước khi máy bạn tham gia.

Sự từ chối đó xảy ra ở rìa, vì vậy nhật ký ứng dụng của bạn không hiển thị gì cả. Việc thiếu nhật ký là bằng chứng về nơi gói tin dừng lại, không phải bằng chứng ứng dụng bị hỏng.

Vì sao một quy tắc cục bộ không thể sửa rìa

Một chuyển hướng hoặc quy tắc DNAT trên máy chủ ứng dụng tác động lên các gói tin đã đến. Các gói tin gửi tới cổng 80 tại nhà cung cấp không bao giờ đến, nên quy tắc không bao giờ được đánh giá. Đây là giờ bị lãng phí phổ biến nhất trong toàn bộ vấn đề.

DNS cũng không thể mang cổng. đặc tả HTTP định nghĩa các giá trị mặc định của lược đồ, và bản ghi A hoặc AAAA trả về một địa chỉ trong khi CNAME trả về một tên khác. Trình duyệt vẫn ghép cổng của lược đồ, nên chỉ một cổng tường minh trong URL mới thay đổi đích.

Lựa chọn một: giữ cổng tường minh

Thường thì câu trả lời đúng là câu trả lời kém hào nhoáng. Công bố URL đầy đủ kèm cổng, kết thúc TLS tại một lối vào hỗ trợ điều đó, và bảo đảm mọi liên kết được tạo giữ cùng nguồn gốc. Với một khán giả nhỏ, được kiểm soát, đây là đủ, và không tốn gì ngoài một số cổng hiển thị.

Kiểm tra chuyển hướng và phạm vi cookie khi bạn ở đó, vì một backend ghi tên máy chủ của chính nó vào tiêu đề Location sẽ phá hỏng cách sắp xếp này.

Lựa chọn hai: có một lối vào thực sự trên cổng mặc định

Một số nhà cung cấp và cách bố trí lưu trữ chuyển tiếp 80 và 443 trên một địa chỉ chia sẻ hoặc riêng như một dịch vụ được ghi nhận. Hãy hỏi điều gì thực sự được bao gồm thay vì giả định rằng một địa chỉ ra công khai hàm ý các cổng vào tùy ý. Một địa chỉ ra riêng không nói gì về chuyển tiếp vào.

Xác nhận quyền sở hữu và tính sẵn có bằng văn bản, kể cả điều gì xảy ra với lối vào khi đường hầm kết nối lại với một địa chỉ khác. Một lối vào di chuyển cùng đường hầm tạo ra gián đoạn trông như lỗi DNS.

Lựa chọn ba: đặt một frontend ở phía trước

Một proxy ngược trên một địa chỉ có thể truy cập được có thể lắng nghe trên 443 và kết thúc TLS và mở một kết nối riêng tới backend qua VPN. Khách truy cập thấy tên và cổng mặc định của frontend, trong khi frontend nói chuyện với cổng cao của backend thay bạn. Điều này hiệu quả vì nó thay đổi kiến trúc thay vì chiến đấu với điểm vào. Backend sau đó không cần bất kỳ cổng vào nào trên internet công cộng.

Nó cũng thay đổi những gì bạn vận hành. Frontend sở hữu TLS công khai, chính sách truy cập, nhật ký và tính sẵn có, và nó phải giới hạn việc chọn backend trong dịch vụ dự định. Nếu bước nhảy từ frontend đến backend dùng HTTPS, hãy giữ việc xác thực chứng chỉ trên bước nhảy đó.

Giữ một nguồn gốc

Tên máy chủ công khai, lược đồ và cổng của frontend tạo nên nguồn gốc mà khách truy cập dùng, nên hãy cấu hình URL bên ngoài của ứng dụng, các chuyển hướng và cookie cho nguồn gốc đó. Gửi máy chủ gốc và lược đồ được chuyển tiếp nếu ứng dụng dựng các liên kết tuyệt đối. Một phản hồi đẩy người dùng trở lại một tên riêng hoặc một cổng cao sẽ phá hỏng lối vào sạch mà bạn vừa xây.

Sau đó hãy quyết định với khán giả trong đầu. Một URL ngắn có thể biện minh cho một frontend được quản lý, và không đáng để vô tình biến một dịch vụ riêng chỉ dành cho VPN thành dịch vụ công khai.