Bạn đang ở giữa một thiết lập, tự động hóa đang chờ đợi, và một trường trống đang yêu cầu một số cổng mà bạn không có. Đó thường là lúc mọi người bắt đầu đoán, và đoán là cách nhanh nhất để lãng phí thời gian. Một số cổng là điểm cuối dịch vụ, trong khi địa chỉ IP là địa chỉ của máy, vì vậy công việc thực tế là tìm ra dịch vụ nào đang lắng nghe, kết nối nào là outbound, hoặc cài đặt proxy nào đã được gán cho bạn.
Tại sao bạn cần tìm số cổng
Một số cổng cho biết một hệ thống dịch vụ nào cần truy cập trên một thiết bị hoặc cổng. Một cổng là điểm cuối dịch vụ, và địa chỉ IP xác định máy, vì vậy cả hai phần phải khớp trước khi lưu lượng truy cập đến đúng đích. Trên một hệ thống máy tính để bàn, kiểm tra đầu tiên thường là bảng socket đang hoạt động, vì số cổng đến từ hệ điều hành, không phải từ việc đoán các hướng dẫn tiêu dùng và mạng đồng ý về quy trình này.
Khớp ngữ cảnh trước khi bạn chạm vào bàn phím
Phương pháp đúng phụ thuộc vào nơi số cổng nằm. Nếu bạn đang kiểm tra máy tính của riêng bạn, bạn cần số cổng mà một ứng dụng cục bộ đang lắng nghe. Nếu bạn đang làm việc ở rìa mạng của mình, bạn có thể cần quy tắc chuyển tiếp cổng của bộ định tuyến. Nếu bạn đang sử dụng một proxy, số cổng thường đến từ bảng điều khiển proxy, không phải từ thiết bị của bạn.
Quy tắc thực tiễn: nếu bạn không thể xác định xem cổng là cục bộ, được định tuyến, hay được gán bởi một dịch vụ, hãy dừng lại và xác định ngữ cảnh trước.
Sự phân biệt đó giúp tiết kiệm thời gian khắc phục sự cố. Một dịch vụ cục bộ có thể mở trên máy tính xách tay của bạn và vẫn không thể truy cập từ internet vì bộ định tuyến, tường lửa, hoặc lớp proxy thay đổi đường đi. TCP/IP sử dụng các cổng để phân tách các kết nối đồng thời và để cho biết liệu một dịch vụ đang mở, đóng, hay lắng nghe như đã giải thích trong các tài liệu tham khảo mạng.
Các quy trình làm việc nặng về proxy thêm một lớp kiểm soát khác. Các nhóm tự động hóa tiếp thị thường cần xác nhận cách các kết nối HTTP và SOCKS5 được hiển thị, cách các phiên dính được duy trì, và cổng nào ứng dụng nên nhắm đến. Nếu proxy của bạn là một proxy HTTP, ứng dụng thường gửi lưu lượng web qua một cổng cụ thể, và cổng được gán nên khớp với cấu hình dịch vụ thay vì một cài đặt mặc định mà bạn thấy ở nơi khác. Để tham khảo máy chủ proxy thực tiễn, hãy xem hướng dẫn nội bộ về các kiến thức cơ bản về máy chủ proxy HTTP.
Tìm số cổng cục bộ trên máy tính của bạn
Cách đáng tin cậy nhất để tìm một cổng cục bộ là kiểm tra các socket đang hoạt động với netstat. Trên Windows, chi tiết quan trọng là ánh xạ cổng với quy trình sở hữu. Trên các hệ thống giống Unix, mẹo hữu ích là lọc cho các socket đang lắng nghe, vì cổng hiển thị trong một kết nối đã thiết lập không phải lúc nào cũng là cổng dịch vụ mà bạn đang tìm kiếm như đã tóm tắt trong hướng dẫn tìm cổng cục bộ.
Đường dẫn Windows
Mở Command Prompt hoặc PowerShell và chạy:
netstat -aon | findstr <port>
Thay thế <port> bằng số mà bạn đang kiểm tra. Đầu ra sẽ cho bạn PID, hoặc ID quy trình, mà bạn có thể khớp trong Task Manager. Đó là cách rõ ràng nhất để xác định xem một trình duyệt, công cụ đồng bộ, trình thu thập dữ liệu, hoặc máy chủ thử nghiệm cục bộ có liên kết với cổng mà bạn quan tâm hay không.
Nếu bạn muốn tìm tất cả các cổng đang lắng nghe trước, hãy sử dụng:
netstat -aon
Rồi tìm các hàng được đánh dấu LISTENING. Đó là các dịch vụ đang chờ kết nối đến. Một số sau dấu hai chấm trong địa chỉ cục bộ là số cổng, và cột PID cho bạn biết ứng dụng nào sở hữu nó. Sự kết hợp đó giúp ngăn chặn sai lầm phổ biến khi đọc điểm cuối sai như là cổng dịch vụ.
macOS và các hệ thống giống Unix
Trên macOS hoặc một hệ thống giống Unix khác, chạy:
netstat -an
hoặc, nếu bạn muốn tập trung vào các listener:
netstat -a | grep -i "listen"
Một lần nữa, số sau dấu hai chấm trong địa chỉ cục bộ là cổng. Một socket LISTENING chỉ đến một dịch vụ được liên kết trên máy của bạn, trong khi một socket ESTABLISHED là một kết nối trực tiếp có thể đang sử dụng một cổng khách tạm thời thay thế.
Thói quen hữu ích: kiểm tra cả trạng thái và địa chỉ, không chỉ số cổng.
Thói quen đó quan trọng khi bạn đang gỡ lỗi các container cục bộ, các bộ nhận webhook, hoặc các bảng điều khiển thử nghiệm. Nếu một dịch vụ khởi động nhưng không chấp nhận lưu lượng, cổng có thể vẫn xuất hiện trong bảng socket, nhưng lớp ứng dụng có thể bị hỏng. Nếu trường hợp sử dụng của bạn là một phiên trình duyệt từ xa hoặc một luồng xác thực proxy, việc kiểm tra socket cục bộ cho bạn biết máy của bạn đang làm gì, không phải những gì máy chủ từ xa mong đợi, vì vậy đừng dừng lại ở đây nếu mục tiêu nằm ngoài máy chủ của bạn.
Kiểm tra các cổng mở trên bộ định tuyến và tường lửa của bạn
Một cổng có thể trông đúng trên máy nhưng vẫn không thể truy cập từ bên ngoài mạng. Lý do thông thường là NAT, hay Dịch vụ Địa chỉ Mạng. Bộ định tuyến của bạn ẩn các địa chỉ cục bộ riêng tư phía sau một cổng công cộng, vì vậy bộ định tuyến phải biết yêu cầu bên ngoài nào nên được gửi đến thiết bị bên trong nào.
Những gì cần kiểm tra trong bảng điều khiển quản trị
Mở bảng điều khiển quản trị bộ định tuyến và tìm Chuyển tiếp cổng, Máy chủ ảo, Quy tắc NAT, hoặc Quy tắc Tường lửa. Các nhà cung cấp gán nhãn menu khác nhau, nhưng nhiệm vụ là như nhau, ánh xạ một cổng bên ngoài đến một địa chỉ IP bên trong và một cổng dịch vụ cục bộ. Nếu mục tiêu là một máy chủ thử nghiệm, bộ nhận webhook, hoặc công cụ quản trị nội bộ, quy tắc đó là điều làm cho nó có thể truy cập từ một mạng khác.
Một cổng trả lời trên máy chủ vẫn có thể không trả lời từ internet. Tường lửa của máy chủ có thể cho phép dịch vụ, trong khi tường lửa của bộ định tuyến chặn nó trước khi lưu lượng đến máy. Kiểm tra trạng thái dịch vụ, sau đó xác nhận rằng các quy tắc tường lửa cục bộ và bộ định tuyến cho phép lưu lượng đến trước khi bạn coi cổng là có thể truy cập khi xác thực một dịch vụ từ xa.
Tại sao điều này vẫn quan trọng trong thực tế
Các cổng vẫn là cách cơ bản mà các hệ thống phân tách một dịch vụ khỏi dịch vụ khác trên cùng một máy. Một kiểm tra cổng nhanh cho bạn biết liệu một dịch vụ đang lắng nghe, đóng, hay bị chặn bởi tường lửa. Điều đó vẫn quan trọng ngay cả khi ứng dụng nằm sau tự động hóa, một hồ sơ trình duyệt, hoặc một đường dẫn proxy, vì đường dẫn mạng phải mở trước khi lớp ứng dụng có thể thực hiện công việc của mình như đã lưu ý trong tài liệu tham khảo mạng ở trên.
Nếu bạn đang mở một công cụ QA cục bộ, một bộ nhận webhook tạm thời, hoặc một ứng dụng nội bộ tự lưu trữ, cả bộ định tuyến và tường lửa của hệ điều hành đều cần cho phép kết nối. Một lớp bị chặn là đủ để làm cho dịch vụ trông như đã chết từ bên ngoài. Đối với các quy trình làm việc được quản lý bởi proxy, quy tắc tương tự cũng áp dụng ngược lại. Ứng dụng có thể truy cập thông qua một cổng proxy, nhưng bộ định tuyến vẫn quyết định xem máy đó có thể truy cập proxy một cách sạch sẽ hay không. Nếu bạn đang thiết lập điều đó trên một thiết bị di động, quy trình cài đặt proxy tại hướng dẫn cài đặt proxy iOS của Evoproxy cho thấy nơi số cổng được nhập và tại sao nó phải khớp với phần còn lại của hồ sơ kết nối.
Xác định số cổng proxy của bạn
Một cổng proxy thường được gán bởi nhà cung cấp. Bạn không tìm thấy một dịch vụ nào đang lắng nghe trên máy tính xách tay của bạn, bạn đang kiểm tra chi tiết kết nối mà dịch vụ proxy cung cấp cho bạn. Bắt đầu với bảng điều khiển dịch vụ, vì đó là nơi nhà cung cấp ánh xạ cổng đến HTTP, HTTPS, hoặc SOCKS5 truy cập.
Đọc bảng điều khiển như một hồ sơ kết nối
Một bảng điều khiển proxy thường hiển thị máy chủ, cổng, và đôi khi là phương thức xác thực. Khớp cổng với giao thức mà công cụ của bạn mong đợi. Lưu lượng HTTP và HTTPS thường theo một thiết lập hướng web, trong khi SOCKS5 phổ biến khi một khách hàng cần xử lý lưu lượng rộng hơn qua các ứng dụng, trình thu thập dữ liệu, hoặc hồ sơ trình duyệt.
Phiên liên tục và xoay vòng IP ảnh hưởng đến cách mà cổng đó hoạt động trong thực tế. Một phiên liên tục giữ IP thoát giống nhau trong một khoảng thời gian hoặc cho đến khi bạn chuyển đổi nó, trong khi xoay vòng thay đổi IP thoát theo lịch trình hoặc theo yêu cầu. Cổng có thể gắn liền với hành vi đó vì một số dịch vụ cung cấp các điểm cuối hoặc cài đặt riêng biệt cho các chế độ phiên khác nhau. Nếu bạn quản lý nhiều tài khoản mạng xã hội, xác minh quảng cáo, hoặc giám sát giá cả, cổng phải khớp với logic phiên mà quy trình làm việc của bạn phụ thuộc vào.
Các proxy di động 4G và 5G thường thấy trong những môi trường đó vì chúng sử dụng mạng của nhà mạng, điều này làm cho lưu lượng của chúng trông gần giống với việc sử dụng di động bình thường hơn là lưu lượng trung tâm dữ liệu chung. Điều đó có thể giúp khi một nền tảng nhạy cảm với các mẫu đăng nhập bất thường hoặc nguồn yêu cầu kỳ lạ. Các proxy dân cư cũng đến từ các mạng tiêu dùng, trong khi các proxy trung tâm dữ liệu thường nổi bật hơn vì chúng xuất phát từ cơ sở hạ tầng lưu trữ thay vì mạng của nhà mạng hoặc mạng gia đình.
Thực hành tốt: đừng giả định rằng một cổng phù hợp với mọi trường hợp sử dụng, đặc biệt nếu quy trình làm việc của bạn chuyển đổi giữa thu thập dữ liệu trên máy tính để bàn, tự động hóa trình duyệt, và các phiên giống như di động.
Khi một dịch vụ từ xa là mục tiêu, hãy xác nhận cổng thay vì đoán. Một kiểm tra kỹ thuật như nmap -p <port> <server_ip> có thể liệt kê các cổng mở, và công cụ phát triển trình duyệt có thể tiết lộ địa chỉ từ xa và cổng được sử dụng bởi một phiên web như đã mô tả trong hướng dẫn xác thực cổng máy chủ. Nếu cổng sai, phiên có thể thất bại ngay cả khi thông tin xác thực proxy là chính xác. Đối với các ví dụ thiết lập proxy cấp thiết bị, hướng dẫn nội bộ về cài đặt proxy iOS là loại tài liệu mà các nhóm thường giữ sẵn khi họ chuẩn hóa quy trình làm việc di động.
Khắc phục sự cố các vấn đề kết nối cổng phổ biến
Một cổng xuất hiện mở trong một lần quét vẫn có thể thất bại trong thực tế. Các nguyên nhân thông thường rất đơn giản, nhưng chúng quan trọng, tường lửa chặn lưu lượng, địa chỉ IP chỉ đến mục tiêu sai, hoặc dịch vụ không lắng nghe trên cổng mà bạn mong đợi. Trong các quy trình làm việc từ xa, ba lỗi đó giải thích nhiều sự nhầm lẫn hơn cả số cổng.
Bắt đầu với các kiểm tra đơn giản nhất
Xác nhận rằng ứng dụng đang lắng nghe trước. Nếu dịch vụ không hoạt động, mọi thử nghiệm khác sẽ mang lại cho bạn tiếng ồn thay vì một câu trả lời hữu ích. Sau đó xác minh rằng địa chỉ IP thuộc về máy hoặc điểm cuối proxy đúng. Sau đó, kiểm tra tường lửa cục bộ, quy tắc bộ định tuyến, và bất kỳ tường lửa lưu trữ nào có thể đang lọc đường đi.
Quy tắc khắc phục sự cố: đừng tin tưởng vào một kết quả “mở” duy nhất cho đến khi ứng dụng, tường lửa, và đường đi mạng đều đồng ý.
Đồ họa thông tin ở trên theo thứ tự hoạt động trong thực tế. Kiểm tra tường lửa cục bộ, sau đó cài đặt bộ định tuyến, sau đó khả năng hiển thị bên ngoài, sau đó trạng thái dịch vụ, sau đó số cổng chính xác. Bỏ qua một lớp thường khiến bạn theo đuổi vấn đề sai.
Đừng nhầm lẫn cổng tạm thời với cổng dịch vụ
Một vấn đề mà các nhà phát triển và kiểm thử QA gặp phải là sự khác biệt giữa cổng dịch vụ cố định và cổng khách hàng động. Microsoft tài liệu rằng Windows sử dụng một dải cổng khách hàng động bắt đầu từ 49152, điều này có nghĩa là nhiều cổng kết nối là tạm thời hơn là các định danh vĩnh viễn hướng dẫn yêu cầu cổng của Microsoft. Nếu bạn kiểm tra một phiên trình duyệt ra ngoài hoặc kết nối ứng dụng, cổng có thể thay đổi từ phiên này sang phiên khác.
Đó là lý do tại sao câu trả lời cho bạn tìm cổng của bạn như thế nào đôi khi là, “bạn không, vì số đó là tạm thời.” Trong tình huống đó, câu hỏi tốt hơn là dịch vụ lắng nghe trên cổng nào, hoặc cổng nào tường lửa nên cho phép. Sự phân biệt này càng quan trọng hơn khi có một proxy liên quan, vì các phiên liên tục, xoay vòng, và NAT nhà mạng đều có thể thay đổi những gì mà khách hàng dường như đang sử dụng.
Đối với các thiết lập proxy di động, NAT cấp nhà mạng, hoặc CGNAT, thêm một lớp dịch thuật khác giữa thiết bị và internet công cộng. Nó không phá vỡ mọi quy trình làm việc, nhưng nó có thể làm cho việc truy cập vào khó khăn hơn và khắc phục sự cố ít nhất quán hơn. Nếu nhiệm vụ của bạn là quản lý nhiều tài khoản, bảo vệ thương hiệu, hoặc QA nhạy cảm với địa lý, một thiết lập proxy sạch thường dễ lý luận hơn so với một đống quy tắc cục bộ và chuyển tiếp tạm thời.
Nếu điểm cuối proxy vẫn từ chối lưu lượng sau khi cổng đúng, hãy xem xét đường đi kết nối và luồng xác thực trong hướng dẫn này về một proxy từ chối kết nối. Kiểm tra đó hữu ích khi cổng tồn tại, nhưng dịch vụ vẫn từ chối phiên trước khi nó đến ứng dụng.
