Cổng bị chặn

Cổng bị chặn

Nhà cung cấp proxy có thể cấm kết nối đến những cổng mạng cụ thể. Họ có thể cho phép duyệt web nhưng từ chối kết nối đến cổng dùng để gửi email. Proxy vẫn nhận kết nối của khách hàng nhưng không thiết lập kết nối được yêu cầu đến máy chủ thư.

Hạn chế cổng là một trong những giới hạn sử dụng proxy quyết định dịch vụ xử lý được tác vụ nào. Để hiểu tác động, bạn cần phân biệt kết nối đến proxy với kết nối proxy tạo thay mặt bạn.

Cổng nào đang bị chặn?

Cổng mạng là con số dùng để phân biệt các dịch vụ tại một địa chỉ mạng. Cùng máy chủ có thể nhận kết nối web trên một cổng và kết nối đến ứng dụng khác trên cổng khác. Ứng dụng cần địa chỉ máy chủ, cổng phù hợp và giao thức vận chuyển được dùng: TCP hoặc UDP.

Kết nối proxy có hai đích riêng. Trước tiên, ứng dụng kết nối đến proxy tại địa chỉ và cổng nhà cung cấp đưa ra. Sau đó nó yêu cầu proxy truy cập máy chủ đích tại địa chỉ và cổng của máy chủ đó. Cổng trong thiết lập proxy thuộc bước đầu; hạn chế cổng đích áp dụng cho bước thứ hai.

Ví dụ, chương trình có thể kết nối đến proxy.example:1080 và yêu cầu portal.example:443. Cùng điểm vào proxy cũng có thể nhận yêu cầu đến mail.example:587. Nếu nhà cung cấp cho phép cổng đích thứ nhất và chặn cổng thứ hai, kết nối web có thể thành công còn kết nối thư bị từ chối.

Máy khách kết nối đến proxy trên cổng TCP 1080. Nhà cung cấp cho kết nối đến portal.example trên cổng TCP 443, nhưng chặn kết nối đến mail.example trên cổng TCP 587 trước khi nó rời mạng của nhà cung cấp.
Hình 1. Một cổng vào proxy, hai cổng đích: nhà cung cấp cho phép TCP 443 và chặn TCP 587. Yêu cầu bị chặn không đến được máy chủ thư. Ví dụ minh họa; quy tắc thực tế phụ thuộc nhà cung cấp.

Các hạn chế này liên quan kết nối đi ra từ proxy đến dịch vụ bên ngoài. Cho phép kết nối đó không cấp cho ứng dụng trên máy tính bạn một cổng nhận kết nối vào mà người dùng internet khác có thể truy cập. Chuyển tiếp cổng vào là một khả năng riêng.

Vì sao nhà cung cấp hạn chế cổng

Lý do rõ nhất là ngăn lạm dụng một dịch vụ cụ thể. Truy cập trực tiếp máy chủ thư có thể được dùng cho chiến dịch thư rác. Khiếu nại và danh sách chặn người gửi ảnh hưởng đến IP mang lưu lượng, nên hậu quả có thể vượt ra ngoài khách hàng gửi thư. Nhà cung cấp có thể giảm rủi ro bằng cách từ chối kết nối đến cổng gửi thư trước khi bất cứ thư nào được truyền.

Cân nhắc tương tự có thể áp dụng cho quản trị từ xa, chia sẻ tệp hoặc dịch vụ cơ sở dữ liệu. Nhà cung cấp có thể hạn chế cổng liên quan để giảm thử đăng nhập trái phép và các cuộc tấn công khác. Hạn chế áp dụng cho chính kết nối: quản trị viên hợp lệ cũng có thể không truy cập được máy chủ của mình qua sản phẩm đó.

Quy tắc không phải lúc nào cũng xuất phát từ người bán proxy. Công ty lưu trữ hoặc đơn vị vận hành mạng có thể lọc kết nối đi ra từ hạ tầng proxy sử dụng. Quyền cho phép trong phần mềm proxy không thể vượt qua hạn chế được áp đặt xa hơn trên tuyến đường.

Lọc cổng là biện pháp diện rộng. Nó có thể dừng lưu lượng không mong muốn mà không xem từng thông điệp hoặc xác định từng thao tác có hợp lệ không, nhưng cũng hạn chế ứng dụng hữu ích cần cùng cổng đó. Sự đánh đổi này giải thích vì sao nhà cung cấp có thể giữ cổng đóng ngay cả với khách hàng trả tiền có tác vụ hợp lý.

Quy tắc truy cập cổng hoạt động như thế nào

Có hai cách cơ bản. Danh sách chặn nêu những cổng khách hàng không được dùng; kết nối khác được xét theo các quy tắc còn lại. Danh sách cho phép làm ngược lại: nhà cung cấp cho một tập cổng xác định và từ chối phần còn lại. Trong mô hình thứ hai, ứng dụng web bình thường trên cổng không tiêu chuẩn có thể không truy cập được chỉ vì cổng nằm ngoài tập cho phép.

Quy tắc có thể bao phủ một cổng ở mọi địa chỉ bên ngoài hoặc kết hợp cổng với một đích cụ thể. Nhà cung cấp cũng có thể áp dụng quy tắc khác nhau cho sản phẩm hoặc mục đích đã phê duyệt khác nhau. Vì vậy, truy cập qua một mạng không chứng minh quyền của sản phẩm khác do cùng công ty bán.

Proxy không cần giải mã lưu lượng ứng dụng để thực thi quy tắc cổng đích. Trong yêu cầu HTTP CONNECT, máy khách cung cấp máy chủ và cổng đích. SOCKS5 cũng mang đích được yêu cầu trong thông điệp kết nối. Proxy có thể từ chối yêu cầu trước khi phiên được bảo vệ với máy chủ đích bắt đầu.

Lưu lượng TCP và UDP dùng cùng số cổng có thể được cho phép hoặc chặn riêng. Kết nối thành công đến cổng TCP 443 không chứng minh cổng UDP 443 khả dụng. Còn một khả năng: sản phẩm proxy đã chọn có thể hoàn toàn không truyền UDP. Khi đó, hạn chế liên quan giao thức vận chuyển chứ không phải một cổng UDP cụ thể.

Chỉ riêng số cổng cũng không chứng minh ứng dụng đang làm gì. Dịch vụ có thể chạy trên cổng không tiêu chuẩn, và một số cổng được phép không khiến mọi cách dùng nó đều được chấp nhận. Nhà cung cấp có thể kết hợp bộ lọc cổng với hạn chế đích và quy tắc về chính hoạt động.

Điều này thay đổi gì với ứng dụng

Ứng dụng dùng kết nối cho các chức năng cụ thể. Thử bằng trình duyệt chỉ kiểm tra kết nối web của nó, không thử mọi kết nối mà chương trình khác có thể cần. Các ví dụ sau cho thấy hạn chế cổng tác động thế nào đến một dịch vụ vốn hoạt động được.

Kết nốiCổng dùng trong ví dụTác động của hạn chế
Truy cập web qua TCP443Không lấy được trang qua kết nối này.
Gửi emailTCP 25 để chuyển thư giữa máy chủ; TCP 465 hoặc 587 để gửi từ ứng dụng thưKhông thể gửi thư trực tiếp qua kết nối bị ảnh hưởng.
FTP thụ độngTCP 21 cho lệnh và một cổng riêng do máy chủ thông báo để truyền dữ liệuĐăng nhập có thể thành công nhưng liệt kê thư mục hoặc truyền tệp thất bại.
Ứng dụng web trên cổng tùy chỉnhVí dụ, TCP 8443Ứng dụng có thể không truy cập được dù trang web trên TCP 443 vẫn hoạt động.

Email minh họa sự khác biệt này rất rõ. Ứng dụng thư gửi thông điệp đi đến máy chủ thư, thường trên cổng 587 hoặc 465. Cổng 465 bắt đầu bằng mã hóa TLS; cổng 587 thường dùng STARTTLS để thiết lập mã hóa. Hạn chế cổng có thể ngăn cả hai kết nối trước khi thư được gửi. Mã hóa bảo vệ quá trình trao đổi nhưng không loại bỏ quy tắc truy cập của nhà cung cấp.

Trong giao diện webmail, trình duyệt liên lạc với trang web qua HTTPS, còn dịch vụ thư xử lý việc chuyển thư. Trình duyệt không yêu cầu proxy thiết lập chính kết nối SMTP đó. Vì vậy, hộp thư web có thể vẫn dùng được trong khi SMTP bị chặn. Nhận thư trong ứng dụng riêng lại là một kết nối khác: truy cập IMAP hoặc POP phải được xét riêng với gửi thư.

FTP cho thấy vì sao chỉ thử đăng nhập có thể bỏ sót vấn đề. Ở chế độ thụ động, trước hết máy khách gửi lệnh qua một kết nối, rồi kết nối đến cổng máy chủ chỉ định để truyền dữ liệu. Nếu kết nối thứ hai bị hạn chế, xác thực có thể hoạt động nhưng danh sách tệp hoặc lượt tải thất bại. Ứng dụng dùng kết nối riêng cho đăng nhập, thoại hoặc trao đổi tệp có thể gặp lỗi từng phần tương tự.

Vì sao đổi thiết lập proxy có thể không giúp ích

Đổi cổng vào trong thiết lập proxy làm thay đổi nơi ứng dụng liên hệ proxy. Nó không đổi cổng đích được yêu cầu cho dịch vụ bên ngoài. Nếu nhà cung cấp có điểm vào ở cổng 443, kết nối đến đó vẫn khiến yêu cầu cổng 587 của máy chủ thư chịu hạn chế cổng thư.

Chuyển từ proxy HTTP sang SOCKS5 có thể giải quyết vấn đề tương thích khi ứng dụng cần khả năng mà phương thức mới hỗ trợ. Việc chuyển đổi tự nó không hủy quy tắc nhà cung cấp. SOCKS5 định nghĩa cách yêu cầu kết nối TCP và chuyển tiếp UDP; dịch vụ quyết định chấp nhận yêu cầu nào.

Đổi IP đầu ra cũng không loại bỏ hạn chế toàn sản phẩm. Tuyến khác có thể hoạt động khác khi một mạng bên ngoài cụ thể gây lỗi, nhưng xoay IP không phải cách xóa quy tắc áp dụng cho toàn sản phẩm. Thêm IP hoặc tăng hạn mức dữ liệu truyền cũng không thay đổi quyền đó.

Cách nhận biết hạn chế cổng

Bằng chứng hữu ích nhất là phản hồi rõ từ nhà cung cấp cho biết cổng đích yêu cầu không được phép. Thông báo từ chối truy cập chung kém chính xác hơn. Ví dụ, phản hồi SOCKS5 cho yêu cầu bị bộ quy tắc từ chối xác định có sự từ chối theo chính sách nhưng không cho biết quy tắc nào gây ra. Chỉ riêng hết thời gian chờ hoặc đặt lại kết nối còn là bằng chứng yếu hơn.

Máy chủ đích có thể không có dịch vụ lắng nghe trên cổng đó, chỉ nhận một số địa chỉ nguồn hoặc tạm thời không khả dụng. Ứng dụng cũng có thể dùng sai giao thức hoặc gửi một phần lưu lượng ngoài proxy đã cấu hình. Kiểm tra một yêu cầu web thành công không phân biệt được các nguyên nhân này với hạn chế tác động đến kết nối khác.

Để yêu cầu hỗ trợ hữu ích, hãy cung cấp sản phẩm proxy, tên máy chủ hoặc IP đích, cổng, TCP hay UDP, ứng dụng và lỗi chính xác kèm thời điểm thử. Những chi tiết đó giúp hỗ trợ kiểm tra đúng kết nối thay vì chỉ xác nhận proxy đang hoạt động. Với kế hoạch mua, thông tin tương tự giúp xác định sản phẩm có hỗ trợ tác vụ không.

Khi nhà cung cấp có ngoại lệ, phê duyệt nên xác định rõ đích và cách sử dụng cần thiết. Một số hạn chế vẫn vĩnh viễn hoặc đến từ hạ tầng nhà cung cấp không kiểm soát. Câu hỏi hữu ích là kết nối cụ thể có thể được hỗ trợ theo quy tắc dịch vụ hay không; yêu cầu “mở mọi cổng” để lại cả nhu cầu lẫn giới hạn chưa rõ.

Quay lại cơ sở kiến thức