차단된 포트

어느 포트가 차단되는가?

네트워크 포트는 하나의 네트워크 주소에서 서비스를 구분하는 번호입니다. 같은 서버가 한 포트에서 웹 연결을, 다른 포트에서 다른 애플리케이션 연결을 받을 수 있습니다. 애플리케이션에는 서버 주소, 적절한 포트, 사용하는 전송 방식인 TCP 또는 UDP가 필요합니다.

프록시 연결에는 별개의 목적지가 두 개 있습니다. 먼저 애플리케이션이 업체가 제공한 주소와 포트로 프록시에 연결합니다. 다음으로 대상 서버의 주소와 포트에 접속해 달라고 요청합니다. 프록시 설정의 포트는 첫 단계에 속하고 목적지 포트 제한은 두 번째 단계에 적용됩니다.

예를 들어 프로그램이 proxy.example:1080에 연결해 portal.example:443을 요청할 수 있습니다. 같은 진입점에서 mail.example:587 요청도 받을 수 있습니다. 업체가 첫 목적지 포트는 허용하고 두 번째는 막으면 웹 연결은 성공해도 메일 연결은 거부됩니다.

제한은 프록시에서 외부 서비스로 나가는 연결에 관한 것입니다. 이를 허용해도 인터넷의 다른 사용자가 내 컴퓨터의 애플리케이션으로 들어오는 포트가 생기지는 않습니다. 수신 포트 전달은 별도 기능입니다.

포트를 제한하는 이유

가장 분명한 이유는 특정 서비스의 악용 방지입니다. 메일 서버의 직접 접속을 스팸 발송에 사용할 수 있습니다. 신고와 발신자 차단 목록은 그 트래픽의 IP에 영향을 주므로 메시지를 보낸 고객 밖으로 피해가 이어질 수 있습니다. 업체는 전송 전에 이메일 포트 연결을 거부해 위험을 줄일 수 있습니다.

원격 관리, 파일 공유, 데이터베이스 서비스에도 비슷한 이유가 적용될 수 있습니다. 무단 로그인 시도와 공격을 줄이려고 관련 포트를 제한할 수 있습니다. 연결 자체에 적용되므로 정당한 관리자도 해당 상품으로 자신의 서버에 접속하지 못할 수 있습니다.

항상 프록시 판매자가 규칙을 정하는 것은 아닙니다. 호스팅 업체나 네트워크 운영자가 프록시 설비의 외부 연결을 필터링할 수 있습니다. 프록시 소프트웨어가 허용해도 경로의 뒤쪽에서 적용되는 제한을 무효화하지는 못합니다.

포트 필터는 넓게 적용되는 수단입니다. 메시지마다 검사하거나 개별 작업의 정당성을 판단하지 않고 트래픽을 막지만, 같은 포트가 필요한 유용한 앱도 제한합니다. 따라서 유료 고객의 합리적인 작업이라도 업체가 포트를 닫아 둘 수 있습니다.

포트 접속 규칙의 작동 방식

기본 방식은 두 가지입니다. 차단 목록은 사용할 수 없는 포트를 정하고 나머지는 다른 서비스 규칙으로 판단합니다. 허용 목록은 반대로 정해진 포트만 허용하고 나머지를 거부합니다. 두 번째 방식에서는 비표준 포트의 일반 웹 앱도 허용 목록 밖이라는 이유만으로 사용할 수 없습니다.

규칙은 모든 외부 주소의 특정 포트에 적용되거나 특정 목적지와 포트를 조합할 수 있습니다. 상품이나 승인된 용도마다 규칙이 다를 수도 있습니다. 따라서 한 네트워크의 접속으로 같은 회사의 다른 상품 권한까지 알 수는 없습니다.

목적지 포트 규칙 적용에 트래픽 복호화는 필요 없습니다. HTTP CONNECT에서는 클라이언트가 대상 호스트와 포트를 제공합니다. SOCKS5도 연결 요청에 목적지를 넣습니다. 프록시는 대상과의 보호 세션 시작 전에 요청을 거부할 수 있습니다.

같은 포트 번호의 TCP와 UDP는 별도로 허용하거나 막을 수 있습니다. TCP 443 연결 성공이 UDP 443 가능의 증거는 아닙니다. 선택한 프록시 상품이 UDP 자체를 전달하지 않을 수도 있습니다. 이 경우 특정 UDP 포트가 아니라 전송 방식의 제한입니다.

포트 번호만으로 애플리케이션의 활동을 증명할 수도 없습니다. 서비스는 비표준 포트에서 실행할 수 있고 허용된 번호라도 모든 사용이 허용되는 것은 아닙니다. 업체는 포트 필터에 대상 제한과 활동 자체의 규칙을 함께 적용할 수 있습니다.

애플리케이션에 생기는 변화

애플리케이션은 특정 기능을 위해 연결합니다. 브라우저 테스트는 자신이 만드는 웹 연결만 확인하고 다른 프로그램에 필요한 모든 연결을 시험하지는 않습니다. 다음 예는 나머지는 정상인 서비스에 포트 제한이 주는 영향을 보여 줍니다.

이메일에서 이 구분이 특히 잘 드러납니다. 메일 앱은 보통 587이나 465 포트로 발신 메시지를 서버에 제출합니다. 465는 TLS 암호화로 시작하고 587은 보통 STARTTLS로 암호화를 설정합니다. 포트 제한은 메시지 전송 전에 둘 중 어느 연결도 막을 수 있습니다. 암호화가 교환을 보호해도 업체의 접속 규칙은 없어지지 않습니다.

웹메일에서는 브라우저가 HTTPS로 웹사이트와 통신하고 메일 서비스가 전달을 처리합니다. 브라우저는 프록시에 같은 SMTP 연결을 요청하지 않습니다. 따라서 SMTP가 막혀도 웹메일은 사용할 수 있습니다. 별도 앱의 메일 수신은 다시 다른 연결이며 IMAP·POP 접속은 전송과 별도로 고려해야 합니다.

FTP는 로그인만 확인하면 문제를 놓칠 수 있음을 보여 줍니다. 수동 모드에서 클라이언트는 먼저 연결 하나로 명령을 보내고 데이터 전송을 위해 서버가 정한 포트에 연결합니다. 두 번째가 제한되면 인증은 성공해도 파일 목록이나 다운로드가 실패할 수 있습니다. 로그인, 음성, 파일 교환에 별도 연결을 쓰는 앱도 일부만 실패할 수 있습니다.

프록시 설정을 바꿔도 도움이 안 될 수 있는 이유

프록시 설정의 진입 포트를 바꾸면 애플리케이션이 프록시에 접속하는 위치가 바뀝니다. 외부 서비스에 요청하는 목적지 포트는 바뀌지 않습니다. 포트 443 진입점을 제공하더라도 그곳에 연결한 뒤 메일 서버의 587을 요청하면 메일 포트 제한은 그대로 적용됩니다.

HTTP 프록시에서 SOCKS5로 바꾸면 새 연결 방식이 지원하는 기능이 필요한 앱의 호환성 문제를 해결할 수 있습니다. 하지만 업체 규칙을 자동 취소하지는 않습니다. SOCKS5는 TCP 연결과 UDP 전달을 요청하는 방식을 정의하고 서비스가 어떤 요청을 받을지 정합니다.

출구 IP를 교체해도 상품 전체 제한은 남습니다. 특정 외부 네트워크가 원인일 때 다른 경로에서 결과가 다를 수는 있지만 순환이 상품 전체 규칙을 없애는 방법은 아닙니다. IP나 트래픽 허용량을 늘려도 권한은 바뀌지 않습니다.

포트 제한을 식별하는 방법

가장 유용한 증거는 요청 목적지 포트가 허용되지 않는다는 명시적 업체 응답입니다. 일반 접속 거부 메시지는 덜 정확합니다. 예를 들어 SOCKS5의 규칙 집합 거부 응답은 정책 거부를 뜻하지만 어느 규칙 때문인지는 알려 주지 않습니다. 시간 초과나 연결 초기화만 있다면 증거는 더 약합니다.

대상 포트에서 서비스가 실행되지 않거나 특정 출발 주소만 허용하거나 일시 장애가 있을 수 있습니다. 앱이 틀린 프로토콜을 쓰거나 일부 트래픽을 프록시 밖으로 보낼 수도 있습니다. 웹 요청 하나의 성공만으로 다른 연결의 원인을 제한과 구분할 수는 없습니다.

지원 요청에는 프록시 상품, 대상 호스트 이름 또는 IP, 포트, TCP·UDP, 애플리케이션, 시도 시간과 정확한 오류를 제시하세요. 그러면 온라인 여부 확인에 그치지 않고 해당 연결을 조사할 수 있습니다. 구매 전에도 같은 정보로 작업 지원 여부를 확인할 수 있습니다.

예외를 허용한다면 승인에 필요한 대상과 용도를 명시해야 합니다. 일부 제한은 영구적이거나 업체가 제어하지 않는 설비에서 옵니다. 중요한 질문은 서비스 규칙에서 특정 연결을 지원할 수 있는지입니다. “모든 포트를 열어 달라”는 요청은 요구와 한도 모두 불명확하게 만듭니다.