포트 열림 확인하는 법 (온라인 포트 스캔)

Problem

“내 포트가 열려 있나?”를 확인한다는 건 아주 구체적인 질문입니다: 인터넷 상의 낯선 사람이 이 주소의 이 포트로 패킷을 보내면, 무언가 응답하는가?

열림 확인이 실제로 묻는 것

이건 ‘내 서비스가 돌고 있는가’와 같은 질문이 아니고, 이 둘을 헷갈리면 몇 시간을 날립니다.

열린 포트는 초대장입니다. 어떤 프로그램이 거기서 듣고 있고, 접속하는 누구와도 대화를 시작하겠다는 뜻이죠. 공개돼야 할 서비스 — HTTPS의 443, 실제로 쓰는 SSH의 22 — 에는 정확히 원하는 상태이고, 나머지 전부에는 정확히 원치 않는 상태입니다. 열린 포트 하나하나가 내 머신으로 들어오는 문이고, 열린 포트 목록이 곧 바깥세상이 보는 나의 공격 표면입니다. 그래서 외부 포트 진단은 두 가지 일을 한 번에 합니다: 열어야 할 문이 열려 있는지 확인하고, 닫는 걸 깜빡한 문을 보여줍니다.

핵심 단어는 외부입니다. 서버는 자기가 무엇을 듣고 있는지 압니다 — 그건 로컬 사실입니다. 인터넷이 거기 닿을 수 있는지는 완전히 다른 사실이고, 리스너와 바깥 사이의 모든 방화벽·라우터가 결정합니다. 열림 확인은 두 번째 질문에 답하며, 무언가 안 닿을 때 정작 중요한 건 그쪽입니다.

세 가지 상태의 의미

TCP 포트 진단은 셋 중 한 상태로 돌아오고, 각각 다른 곳을 가리킵니다.

Open(열림). SYN을 보냈고 포트가 SYN-ACK로 답했고 핸드셰이크가 완료됐습니다. 프로그램이 듣고 있고 닿습니다. 끝.

Closed(닫힘). SYN을 보냈더니 즉시 RST(리셋)가 왔습니다. 호스트는 살아 있고 닿지만 그 포트에 아무것도 안 듣고 있어서, OS가 그 자리에서 접속을 거절한 것입니다. 빠르고 확정적인 ‘아니오’죠. 애플리케이션 관점에선 로그에서 보는 ECONNREFUSED / “Connection refused”입니다. 닫힘은 뜻밖에도 좋은 소식입니다 — 네트워크 경로가 살아 있고 머신도 살아 있다는 뜻이고, 그냥 빈 포트를 찾은 것뿐이니까요.

Filtered(필터링). SYN을 보냈는데 아무것도 안 왔습니다. SYN-ACK도, RST도 없이 — 시도가 타임아웃될 때까지 침묵. 무언가가 패킷을 바닥에 버린 것이고, 거의 항상 거절이 아니라 폐기하도록 설정된 방화벽입니다. 이게 “Connection timed out” 경우이고, 서버가 방화벽 뒤에서 멀쩡하더라도 “서버가 죽었다”와 똑같이 느껴집니다.

이 ‘거절 대 타임아웃’ 갈림이 외부 진단이 알려주는 가장 유용한 한 가지입니다. 누가 실패하는지를 말해주기 때문이죠. RST는 호스트 자신이 보낸 것이므로 패킷은 머신에 닿았고 — 문제는 서비스나 바인딩입니다. 침묵은 응답이 전혀 없었다는 뜻이므로 문제는 머신 앞단의 방화벽이나 막다른 라우팅입니다. 사용자에겐 같은 증상(“접속 안 됨”), 처방은 정반대.

(UDP는 더 모호하니 단서를 붙입니다: UDP는 핸드셰이크가 없어 침묵하는 UDP 포트가 ‘열려 있는데 응답을 안 하는’ 것인지 ‘필터링’인지 밖에서 구분하기 진짜 어렵습니다. 닫힌 UDP 포트는 보통 ICMP “port unreachable”를 유발하지만 방화벽이 그것마저 억누르는 일이 잦습니다. UDP 결과는 TCP보다 무르게 받아들이세요.)

Top 3 Causes

1. 서비스가 localhost에만 바인딩됨. 가장 흔한 자책골. 127.0.0.1:5432에 바인딩된 서비스는 그 머신에선 완벽히 동작하고 다른 어디에서도 보이지 않습니다 — 프로세스가 떠 있어도 외부 진단엔 닫힘으로 나옵니다. 해결은 localhost가 아니라 0.0.0.0(또는 특정 공인 인터페이스)에 바인딩하는 것. 방화벽 문제와 똑같아 보이지만 아니니, 이걸 먼저 확인하세요.
2. 방화벽이 트래픽을 버림. 호스트 방화벽(ufw, firewalld, Windows Defender 방화벽)과 클라우드 통제(AWS 보안 그룹, GCP 방화벽 규칙, 네트워크 ACL)가 리스너 앞에 앉아 있습니다. 그중 하나라도 해당 포트 인바운드를 허용하지 않으면 조용한 필터링 타임아웃이 납니다. 클라우드가 대표적 함정 — OS 방화벽은 열려 있고 서비스도 듣고 있는데, 아무도 기억 못 하는 보안 그룹이 모든 패킷을 조용히 버리는 상황.
3. 라우터가 포트를 포워딩한 적 없음(또는 못 함). 가정·소규모 사무실 회선에선 공인 IP가 머신이 아니라 라우터에 있습니다. 포워딩 규칙이 없으면 라우터는 어느 내부 호스트로 보낼지 몰라 접속을 버립니다. 그리고 때로는 포워딩 자체가 불가능합니다 — ISP가 CGNAT를 쓰면 포워딩할 공인 IP가 없고, 일부 ISP는 설정과 무관하게 25번 같은 인바운드 포트를 막습니다.

Diagnose with DechoNet

• Port Check — 도메인이나 공인 IP에 실행해 포트별 상태를 읽으세요. Open이면 닿는 것, Closed면 호스트는 답했으나 아무것도 안 듣는 것(서비스와 바인딩을 보세요), Filtered/타임아웃이면 앞단의 무언가가 패킷을 버리는 것(방화벽과 포워딩을 보세요). 자기 netstat으로는 못 얻는 ‘밖에서 안으로’의 시야입니다.
• DNS Lookup — 포트 결과를 믿기 전에, 그 이름이 당신이 생각하는 IP로 풀리는지 확인하세요. 옛 서버나 CDN 엣지를 가리키는 호스트명에 겨눈 포트 진단은 엉뚱한 머신을 시험하는 것입니다.
• HTTP Check — 80이나 443이 열림인데도 사이트가 실패하면, 포트는 멀쩡하고 문제는 애플리케이션으로 올라간 것입니다. 거기서 실제 응답을 확인하세요.

Resolution Checklist

• 어느 상태인지 판정: Closed(RST/거절)는 서비스를, Filtered(타임아웃/침묵)는 방화벽이나 라우터를 가리킵니다.
• 서비스가 돌고 있으며 127.0.0.1이 아니라 0.0.0.0이나 공인 인터페이스에 바인딩됐는지 확인. ss -tlnp가 바인드 주소를 보여줍니다.
• 경로상의 모든 방화벽 점검: 호스트 방화벽과, 클라우드라면 보안 그룹/네트워크 ACL. 전부 해당 포트 인바운드를 허용해야 합니다.
• 가정·사무실 네트워크라면 라우터 포워딩 규칙 확인: 외부 포트, 내부 IP(DHCP 예약으로 안 바뀌게), 프로토콜.
• 변경할 때마다 Port Check를 밖에서 다시 실행 — 로컬 netstat이 아니라 실제 도달성을 시험하는 것입니다.
• 노출할 생각 없던 걸 닫으세요. DB나 관리 포트가 인터넷에 열려 보이면, 그건 연결 성공이 아니라 하나의 발견(finding)입니다.

When to Escalate

• 서비스·호스트 방화벽·라우터를 다 확인했는데도 포트가 필터링 상태로 남으면 ISP를 의심하세요. 회선이 CGNAT 뒤인지(포워딩 가능한 공인 IP 없음), 해당 포트가 상단에서 막혔는지 문의합니다. 둘 다 내 쪽에서 못 고칩니다.
• 관리형 로드밸런서, 클라우드 인그레스, 회사 방화벽이 네트워크 경로를 소유하면 도달성 결정권은 그 계층을 통제하는 쪽에 있습니다 — 호스트를 또 만지지 말고 거기로 에스컬레이션하세요.