문제 상황

1. Rocky OS 설치 후 eth0에 IP(예: 192.168.1.10)가 할당되었음. (ip ad sh eth0 확인)
2. 인터페이스도 UP 상태
3. 게이트웨이(예: 192.168.1.1)의 MAC 주소도 arp -an 명령어로 정상 확인되었음.
4. 하지만! eth0와 동일 대역에 있는 검수 서버로 curl 요청이 날라가지 않는 문제가 발생함.

뭐가 문제였는가?

가장 유력한 원인은 OS 설치 시 적용된 방화벽 정책(iptables) 때문인 것 같다.

arp -an 명령어로 게이트웨이의 MAC 주소를 성공적으로 가져왔다는 것은,

최소한 L2(Data link) 수준에서는 eth0 인터페이스가 게이트웨이와 통신이 가능하다는 애기가 된다.

즉, 스위치나 케이블, 드라이버 등 하위 레벨의 문제는 아니었던 것이다.

하지만 curl이 실패했다는 것은 L4 또는 L7 레벨의 트래픽이 어딘가에서 차단되었다는 뜻이 된다.

여기서 iptables를 원인으로 지목하는 이유는 다음과 같다.

• OUTPUT 체인 차단: 가장 가능성이 높은 이유 중 하나인데, iptables의 OUTPUT 체인(서버에서 나가는 트래픽을 제어)에 기본 DROP 또는 REJECT 정책이 걸려있었거나, 허용된 특정 트래픽 외에는 모두 차단하는 룰이 있었을 것이다.
• curl은 HTTP/HTTPS를 사용한다. 만약 OUTPUT 체인에서 이 포트들로 나가는 트래픽을 명시적으로 허용(ACCEPT)하지 않았다면, curl은 목적지에 닿기도 전에 로컬 서버의 방화벽에 의해 차단된다.

결국 L2, L3는 되는데 L7이 안되는 이 기묘한 현상은 로컬 서버 자체가 자신에게서 나가는 트래픽을 막고 있었기 때문 으로 유추된다.

해결 방법

결론부터 말하면 iptables -F 명령어를 사용하여 현재 서버에 적용된 iptables 정책을 모두 날려 해결하였다.

이것이 어떻게 문제를 해결했는지 이해하려면 iptables의 ‘룰(Rule)’ 과 ‘정책(Policy)’ 의 차이를 알아야 한다.

• 룰 (Rule): “소스 IP 1.2.3.4에서 오는 22번 포트 트래픽은 허용(ACCEPT)한다”와 같은 개별 규칙
• 정책 (Policy): “룰에 명시되지 않은 모든 트래픽은 기본적으로 차단(DROP)한다”와 같은 기본 방침

문제를 일으킨 시나리오는 아마도 OUTPUT 체인의 기본 정책(Policy) 이 ACCEPT (모두 허용)로 되어 있었지만,

OS 설치 스크립트가 추가한 특정 룰(Rule) 이 curl 트래픽을 DROP 시키고 있었을 것!

혹은, 기본 정책이 DROP이었지만, iptables -F를 실행한 터미널의 SSH 연결(TCP 22) 등은 이미 ESTABLISHED 상태라 세션이 유지된 상태에서(stateful 방화벽) 룰만 삭제되었을 수도 있다.

가장 일반적인 시나리오는 이것이다.

1. [문제 상태] OUTPUT 체인의 기본 정책 은 ACCEPT (허용) 상태.
2. 하지만 설치 스크립트가 “모든 트래픽을 차단하라”는 DROP 룰 을 OUTPUT 체인 맨 마지막에 추가함. (혹은 특정 포트만 허용하고 나머진 차단)
3. curl 트래픽이 이 DROP 룰에 걸려 차단됨.
4. [해결] iptables -F 실행!
5. OUTPUT 체인의 모든 룰 (DROP 룰 포함)이 삭제됨.
6. 이제 남은 것은 기본 정책 뿐. 기본 정책은 ACCEPT (허용)이므로, curl 트래픽이 방해 없이 나갈 수 있게 됨.

⚠️ 경고: iptables -F는 만병통치약이 아님!!!

iptables -F는 모든 방화벽 룰을 날려버리기 때문에, 서버를 무방비 상태로 만들 수 있음.

이번 경우는 OS 설치 중이었고 검수 서버로의 통신이 급했기 때문에 임시방편으로 사용한 것이며, 실제 운영 환경에서는 절대 함부로 사용해서는 안 된다는 것을 잊지 말자.

향후 문제 발생 시 점검 방법

OSI 7계층을 기반으로 차근차근 접근하는 것이 가장 효율적이다.

1. L1 (Physical) - 선(cable)이 정상적인가?

물리 계층이다. 가장 기본이지만 가장 놓치기도 쉽다.

• 명령어
  • ip link show eth0: 인터페이스가 상태가 UP 상태인가?, LOWER_UP 상태가 맞는가? (물리적으로 케이블 연결 및 링크 활성화가 되었는지)
  • ethtool -p eth0: 케이블이 서버의 eth0 포트에 정상적으로 연결되어 있는가?
  • ethtool -i eth0: 네트워크 드라이버가 올바른가?

2. L2 (data link) - 게이트웨이와 통신은 되는가?

동일 네트워크 대역(L2) 내의 통신을 확인해야 한다.

• 명령어: arp -an
• 확인 사항
  • 게이트웨이 IP 의 MAC 주소가 정상적으로 등록되었는가?
  • (incomplete) 상태로 남아있지 않은가?

3. L3 (Network) - 라우팅 주소가 올바른가?

IP 주소 설정과 라우팅 경로를 점검해야 한다.

• 명령어 1: ip addr show eth0
  • 확인 사항: 할당된 IP 주소와 서브넷 마스크(CIDR)가 정확한가?
• 명령어 2: ip route show (또는 netstat -nr / route -n)
  • 확인 사항: default (기본 게이트웨이) 경로가 올바르게 설정되어 있는가?

4. L4 (Transport) - 포트가 막힌 건 아닌가?

실제 통신(TCP/UDP)이 가능한지, 특히 방화벽을 중점적으로 확인해야 한다.

이번 문제의 핵심 단게였다.

• 명령어 1 (로컬 방화벽): iptables -L -v -n
  • 확인 사항
    • INPUT, OUTPUT, FORWARD 각 체인의 기본 정책이 ACCEPT인가, DROP인가?
    • OUTPUT 체인에 DROP 또는 REJECT 룰이 있는가? (특히 curl이 사용하려는 dpt:80 또는 dpt:443 관련 룰)
• 명령어 2 (포트 연결 테스트): nc -zv <Destination_IP> <Port> (예: nc -zv 192.168.1.1 80)
  • 확인 사항: succeeded! 메시지가 뜨는가? Connection refused (서버는 살아있으나 포트가 닫힘)나 No route to host (네트워크/방화벽 문제)가 뜨는가?
• 명령어 3 (경로 추적): traceroute <Destination_IP>
  • 확인 사항: 트래픽이 어디까지 도달하고 어디서 멈추는가? (중간 방화벽에서 추가적으로 막히는지 파악 가능)