네트워크 접속 이슈…

지금 시스템 접속이 안 되는데요? 오늘 PQ 진행해야하는데..

급하게 VPN을 켜고 접속을 시도했다. 내 PC에서는… 멀쩡하게 접속된다.

상황 파악

침착하게 상황을 정리해봤다.

문제 증상

고객사 사용자들만 데이터 조회 시 무한 로딩
내 PC에서 접속 시 정상
DB 직접 조회도 정상

시도해본 방법

브라우저 캐시 삭제
방화벽 포드 정상
WAS 로그 확인

소거법으로 범인 찾기

패킷은 출발지에서 생성될 때 이미 모든 계층의 정보를 감싸 이동
장애 상황에서는 하위 계층부터 순차적으로 점검하여 문제를 좁혀가는 것이 가장 효율적
하위 계층에 문제가 있다면 상위 계층은 동작할 수 없기 때문에 2계층 → 3계층 → 4계층 -> 7계층 순으로 확인

Ping 테스트 (2-3계층 확인)

ping 203.xxx.xxx.xxx

결과: 성공

네트워크 경로는 정상이다. IP까지는 도달한다는 뜻이니, 라우터나 경로 문제는 아니다.

2계층

3계층

클라이언트가 외부 서버에 접속할 때:

목적지 IP가 내부망(192.168.x.x)이 아니면 → 외부망으로 판단
게이트웨이의 MAC 주소를 ARP로 찾아서
패킷을 게이트웨이로 전송
NAT로 사설 IP를 공인 IP로 변환하여
여러 라우터를 거쳐 목적지 서버에 도달

Ping이 성공했다는 건 이 과정이 정상이라는 의미다.

Telnet 테스트 (4계층 확인)

4계층

Ping이 성공했으니 이제 포트까지 확인해보자.

telnet 203.xxx.xxx.xxx 8080

결과: 실패

‘어? 포트가 막혀있나?’

고객사 담당자에게 다시 확인했다. “서버 방화벽에서 8080 포트 열려있는 거 맞죠?” “네, 분명 열려있어요.”

그런데 telnet은 실패한다. 이건 뭔가 중간에 막고 있다는 뜻이다.

패킷에는 이런 정보가 들어있다:

출발지 IP / 목적지 IP (3계층)
출발지 MAC / 목적지 MAC (2계층)
포트 정보 (4계층)
실제 데이터

서버까지는 도달하는데(ping 성공), 포트 연결은 안 된다(telnet 실패). 그럼 서버와 클라이언트 사이 어딘가에 포트를 막는 무언가 있다는 거다.

범인 찾기

“지금 Ping은 성공하고 Telnet이 실패해서 그러는데 서버랑 클라이언트 사이에 다른 네트워크 장비 있는지 확인해 주실 수 있나요? “음… 잠시만요, 네트워크 담당자한테 물어볼게요.”

…

“아, L7 스위치가 있다는데요?”

범인을 찾았다.

고객사도 몰랐던 중간 네트워크 장비가 특정 URL 패턴을 차단하고 있었던 것이다. 주말 사이 보안팀에서 보안 정책을 업데이트했고, 그 과정에서 시스템 경로가 차단 규칙에 걸려버렸다.

L7 스위치

L7 스위치는 7계층(응용 계층)에서 동작하는 로드밸런서다.

L4 스위치 (4계층 - 전송 계층)

IP + Port로만 판단
빠르고 단순
Round Robin, Least Connection 방식

L7 스위치 (7계층 - 응용 계층)

URL, Cookie, Header까지 보고 판단
느리지만 똑똑함
URL 기반 라우팅: /api → API 서버, /admin → 관리 서버

우리 경우는 L7 스위치가 URL 패턴을 보고 차단한 케이스였다.

해결

네트워크 담당자와 협업하여:

L7 스위치의 ACL(Access Control List) 확인
프로젝트 관련 URL 패턴을 허용 규칙에 추가
설정 적용 후 정상 접속 확인

배운 것들

소거법

무작정 이것저것 시도하는 것보다, 체계적으로 하위 계층부터 확인하는 게 훨씬 효율적이다.

Ping (2-3계층) → 네트워크 경로 확인

성공: 경로 정상
실패: IP 오류, 경로 단절, 라우터 문제

Telnet (4계층) → 포트 연결 확인

성공: 포트 정상, 애플리케이션 문제 의심
실패: 방화벽/보안장비 포트 차단

WAS 로그 (7계층) → 애플리케이션 확인

Access Log: 누가, 언제, 어떤 요청
Application Log: 에러, 경고, 스택 트레이스
Error Log: WAS 자체 에러
Slow Query: 느린 쿼리 기록

근거 기반 커뮤니케이션

고객사에 확인을 요청하려면 근거가 필요하다. 우리는 ‘을’ 입장이다.

“뭔가 안 되는데 확인 좀 해주세요”

보다는

“Ping은 성공하는데 Telnet이 실패합니다. 서버 방화벽은 열려있다고 하셨으니, 혹시 중간에 다른 네트워크 장비가 있는지 확인 부탁드립니다.”

네트워크 흐름을 이해하고 있어야 정확하게 요청할 수 있다.

숨어있는 장비들

실제 운영 환경에는 생각보다 많은 장비들이 숨어있다:

IPS (침입방지시스템)
프록시 서버
L4/L7 스위치
WAF (웹 방화벽)

담당자도 모를 수 있으니, 네트워크 담당자와의 협업이 중요하다.

또 다른 장애 케이스

DB Connection Timeout

증상:
- ping 성공
- telnet 성공
- 서버 접속 500 Error
- WAS 로그에 아무것도 안 뜸

이 경우는 4계층까지는 정상이고, 애플리케이션 레벨 문제다.

원인

DB 연결 30초 타임아웃
사용자들이 못 기다리고 새로고침 반복
DB 커넥션 풀 고갈

해결

즉시: 애플리케이션 재시작, 슬로우 쿼리 킬
장기: 커넥션 풀 증가, 쿼리 최적화

마치며

네트워크 장애는 패킷이 어떻게 이동하는지 이해하고 하위 계층부터 체계적으로 확인하면 생각보다 빠르게 해결할 수 있다.

물데네전세표응을 외우는 것보다, 흐름을 이해하고 실전에 적용하는 게 중요하다.

다음 장애가 왔을 때는 조금 덜 당황할 수 있을 것 같다.

더 알아보기

CIDR: CIDR 개념 정리
서브넷 마스크: 네트워크 대역 구분
traceroute: 패킷 경로 추적
패킷이 WAS에 도착한 후: Spring 요청 처리 흐름

···

[Network] 네트워크 장애 대응기