ㅂ ㅂㄹㄱ
목록으로 돌아가기
Network
15분 읽기

네트워크 계층 기본기 — OSI 7계층 대신 TCP/IP 4계층으로 장애 원인을 좁히는 법

실무에서 쓰는 네트워크 계층은 OSI 7계층이 아니라 TCP/IP 4계층이다. 각 계층은 바로 앞 계층이 풀지 못한 한계를 메우려고 생겼고, 이 구조를 이해하면 nc·traceroute·dig·curl 네 개만으로 장애가 어느 계층에서 터졌는지 빠르게 좁힐 수 있다.

ㅂ

ㅂㄹㄱ

2026-07-15

네트워크 계층을 외우는 글이 아니다.
장애가 났을 때 어느 계층부터 의심할지 정하는 좌표계를 세우는 글이다.

들어가며

블로그를 Workers로 옮기기 전, 홈 서버를 오리진으로 쓰던 시절 이야기다. 홈 서버를 Cloudflare 뒤에 붙이고 나서 이런 상황을 만났다. 핑은 잘 간다. 그런데 페이지는 안 열린다.

$ ping -c 1 hyochan.site
64 bytes from 104.21.15.78: icmp_seq=0 ttl=53 time=132.686 ms   # 멀쩡하다 (당시 기록이 없어 현재 수치로 재현했다)

$ curl -I https://hyochan.site
HTTP/2 521                                                     # 그런데 안 된다

한참 헤맸다. 방화벽을 껐다 켜고, 오리진 서버를 재부팅하고, 설정을 원복했다. 그러다 뒤늦게 깨달았다. 내가 핑을 때린 대상은 내 서버가 아니었다. 104.21.15.78은 Cloudflare 엣지다. 엣지는 언제나 살아있다. 오리진이 죽어도 저 핑은 영원히 성공한다.

프록시 뒤의 도메인에 ping을 때리는 건 "Cloudflare가 살아있나?"를 묻는 것과 같다. 내가 알고 싶었던 건 그게 아니었다.

삽질의 본질은 도구를 몰라서가 아니었다. 핑이 어느 계층의 무엇을 검증하는지 몰랐던 것이다. 계층을 알았다면 저 핑 결과가 아무 의미도 없다는 걸 3초 만에 알았을 것이다.

계층은 시험 문제가 아니라 문제를 자르는 칼이다. 이 글은 그 칼을 쥐는 데 필요한 최소한만 다룬다.

계층은 왜 나뉘어 있나

계층이 나뉜 이유는 각 계층이 바로 앞 계층이 풀지 못한 한계를 메우려고 생겼기 때문이다.

네트워크를 처음 배울 때 "7계층이 있고 각각 이런 역할을 한다"는 식으로 외우면 머리에 남지 않는다. 순서가 반대다. 먼저 한계가 있었고, 그걸 넘으려고 새 계층이 붙었다.

이 흐름으로 보면 계층이 저절로 외워진다.

계층할 수 있게 된 것남은 한계
L2 (Ethernet)같은 링크 안에서 프레임 전달그 링크를 벗어나지 못한다
L3 (IP)전 세계 어디로든 경로 탐색도착을 보장하지 못한다
L4 (TCP)순서 보장, 재전송, 흐름 제어내용이 그대로 노출된다
TLS암호화, 신원 검증사람이 쓸 인터페이스가 없다
L7 (HTTP/DNS)이름으로 자원 요청—

각 행의 "남은 한계"가 다음 행이 존재하는 이유다.

그런데 왜 7계층이 아니라 4계층인가

실제 인터넷은 OSI 7계층이 아니라 TCP/IP 4계층으로 동작한다.

이걸 짚고 가는 이유가 있다. OSI 7계층 표를 아무리 외워도 실무와 안 맞아서 혼란만 커지기 때문이다. TCP/IP는 1970년대에 먼저 만들어져 실제로 구현됐고, OSI는 그 뒤에 나온 참조 모델이다. 현실이 모델을 따라간 게 아니라 모델이 현실을 뒤늦게 설명하려 한 쪽에 가깝다.

그 결과 OSI의 5~6계층(Session, Presentation)은 실제 프로토콜에 대응하는 게 거의 없다. TLS를 어디에 놓을지 물으면 답이 갈리는 것도 이 때문이다.

OSI 7계층              TCP/IP 4계층          실제 프로토콜
─────────────────────────────────────────────────────────
7. Application  ┐
6. Presentation ├───►  Application   ───►  HTTP, DNS, TLS
5. Session      ┘
4. Transport    ─────► Transport     ───►  TCP, UDP
3. Network      ─────► Internet      ───►  IP, ICMP
2. Data Link    ┐
1. Physical     ┴───►  Link          ───►  Ethernet, Wi-Fi

그럼 왜 다들 아직도 L2, L3, L7이라고 부를까. 호칭만 OSI 번호에서 빌려 쓰기 때문이다. L7 로드밸런서, L3 스위치 같은 말은 업계 표준 용어라 그대로 쓰되, 동작 모델은 TCP/IP 4계층으로 생각하면 된다.

L2 — MAC 주소에는 위치가 없다

L2는 MAC 주소로 같은 네트워크 안에서만 프레임을 전달한다.

MAC 주소는 네트워크 카드에 박힌 48비트 고유값이다. 같은 스위치에 꽂힌 장비끼리는 이 주소만으로 통신한다. 스위치는 어느 포트에 어떤 MAC이 붙었는지 학습해서 표를 만들고, 그 표를 보고 해당 포트로만 프레임을 내보낸다.

지금 이 장비가 어떤 이웃을 알고 있는지는 ip neigh로 바로 보인다. 출력은 이런 모양이다(실제 캡처가 아닌 설명용 예시다. MAC은 RFC 9542 문서용 대역을 썼다).

$ ip neigh
192.168.1.1 dev eth0 lladdr 00:00:5e:00:53:01 REACHABLE
192.168.1.42 dev eth0 lladdr 00:00:5e:00:53:2a STALE

한계는 이 출력에 그대로 드러난다. MAC 주소에는 위치 정보가 없다. 00:00:5e:00:53:01만 보고는 이게 어디 붙어 있는지 알 수 없고, IP처럼 접두사로 방향을 추릴 수도 없다. 그래서 이 표는 같은 링크에 있는 장비만 담는다. 전 세계 장비의 MAC을 여기 담는 건 불가능하다.

이 링크를 벗어나려면 다른 게 필요했다.

L2 스위칭과 서브넷 마스크의 실전 동작은 Cloudflare 딥다이브 EP.01에서 Vultr VPC 사례로 자세히 다뤘다.

L3(IP) — 링크를 벗어나지만 도착은 보장 못 한다

L3는 IP 주소에 계층 구조를 넣어서 전 세계 라우팅을 가능하게 만들었다.

MAC과 IP의 결정적 차이는 여기 있다. IP 주소는 위치를 담는다. 104.16.0.0/12처럼 앞부분이 같으면 같은 방향에 있다는 뜻이다. 덕분에 라우터는 전 세계 IP를 다 몰라도 된다. "이 접두사로 시작하면 저쪽으로" 정도의 표만 들고 있으면 된다.

traceroute를 찍으면 이 릴레이가 그대로 보인다.

$ traceroute hyochan.site
traceroute: Warning: hyochan.site has multiple addresses; using 104.21.15.78
traceroute to hyochan.site (104.21.15.78), 64 hops max, 40 byte packets
 1  192.168.137.1 (192.168.137.1)  0.615 ms *  0.883 ms
 2  * * *
 3  172.16.0.1 (172.16.0.1)  0.943 ms  0.779 ms  0.629 ms
 4  121.134.34.1 (121.134.34.1)  0.720 ms  1.237 ms  1.097 ms
 5  * * *
 6  * * *
 7  112.189.13.201 (112.189.13.201)  2.158 ms
    112.189.14.205 (112.189.14.205)  1.963 ms
    112.189.13.101 (112.189.13.101)  2.059 ms
 8  112.174.49.41 (112.174.49.41)  7.494 ms
    112.174.49.169 (112.174.49.169)  7.405 ms
    112.174.47.41 (112.174.47.41)  7.844 ms
 9  112.174.86.134 (112.174.86.134)  7.931 ms
    112.174.86.138 (112.174.86.138)  8.087 ms
    112.174.91.174 (112.174.91.174)  7.968 ms
10  112.174.87.26 (112.174.87.26)  133.101 ms
    112.174.89.22 (112.174.89.22)  136.077 ms
    112.174.87.26 (112.174.87.26)  132.758 ms
11  121.189.3.14 (121.189.3.14)  131.799 ms *  132.148 ms
12  141.101.72.19 (141.101.72.19)  134.904 ms
    141.101.72.32 (141.101.72.32)  140.801 ms
    141.101.72.19 (141.101.72.19)  134.868 ms
13  104.21.15.78 (104.21.15.78)  135.369 ms  132.518 ms  132.778 ms

macOS 기준 출력이다. 리눅스는 30 hops max, 60 byte packets으로 뜬다. 맨 윗줄 경고는 A 레코드가 2개라서 나온다. 홉 1의 호스트명은 기기 이름이라 IP로 대체했다.

이 출력에 L3의 전부가 들어 있다. 네 가지만 짚는다.

9번과 10번 사이에서 RTT가 8ms에서 133ms로 뛴다. 여기가 태평양이다. 앞의 국내 구간은 전부 한 자릿수 ms인데 한 홉 만에 125ms가 붙는다. 거리는 이렇게 RTT로 드러난다. Anycast를 쓰는데 왜 굳이 태평양을 건너는지는 그 자체로 긴 이야기라 따로 다룬다.

7~10번과 12번 홉은 probe마다 다른 IP가 응답한다. 같은 홉 자리인데 112.174.49.41, 112.174.49.169, 112.174.47.41이 번갈아 나온다. 경로가 하나가 아니라 여러 개로 부하 분산되고 있다는 뜻이다.

2·5·6번 홉은 별표인데 3·4·7번은 응답한다. 이게 왜 장애가 아닌지는 다음 섹션에서 다룬다.

L3의 한계는 IP가 최선 노력(best effort)이라는 점이다. 패킷을 보낼 뿐 도착했는지 확인하지 않는다. 중간에 버려져도, 순서가 뒤바뀌어도 IP는 모른다.

ping과 traceroute를 믿으면 안 되는 순간

ping과 traceroute는 성공했을 때만 정보이고, 실패했을 때는 아무것도 알려주지 않는다.

둘 다 ICMP에 의존하는데, ICMP는 꺼두는 게 정상 취급을 받는 프로토콜이다. 클라우드 보안그룹 기본값, Windows 방화벽 기본값, 하드닝된 호스트 대부분이 ICMP echo를 막는다. 그래서 이 비대칭이 생긴다.

결과알 수 있는 것
ping 성공L3까지 정상이 확정된다
ping 실패아무것도 확정되지 않는다. L3 장애일 수도, 그냥 ICMP를 막아둔 것일 수도 있다

앞 섹션 traceroute의 2·5·6번 별표가 이걸 그대로 보여준다. 저 홉에서 패킷이 죽었다면 7번 홉이 응답할 수 없다. 그런데 7번은 2ms에 답하고, 결국 13번에서 목적지까지 도달한다. 별표는 그 라우터가 ICMP Time Exceeded를 안 보냈다는 뜻일 뿐이고 패킷은 멀쩡히 통과했다.

2번 홉의 이유는 -I로 찍으면 노골적으로 드러난다.

$ traceroute -I hyochan.site
traceroute: Warning: hyochan.site has multiple addresses; using 104.21.15.78
traceroute to hyochan.site (104.21.15.78), 64 hops max, 48 byte packets
 1  192.168.137.1 (192.168.137.1)  0.623 ms *  0.400 ms
 2  * 192.168.137.1 (192.168.137.1)  0.498 ms !X *
 3  172.16.0.1 (172.16.0.1)  0.866 ms  0.705 ms  0.567 ms
...

!X는 ICMP의 "administratively prohibited"(type 3 code 13)이다. 이 probe는 실제로 막혔다. 그 장비가 "정책상 안 된다"고 명시적으로 답한 것이다.

그런데 바로 다음 줄에서 3번 홉이 정상 응답한다. probe 하나가 막힌 것과 트래픽이 막히는 건 다르다는 뜻이다. 장애가 아니라 설정이다.

같은 호스트에 ping과 curl을 찍으면 이렇게 나온다.

$ ping -c 2 hyochan.site
PING hyochan.site (104.21.15.78): 56 data bytes
64 bytes from 104.21.15.78: icmp_seq=0 ttl=53 time=132.686 ms
64 bytes from 104.21.15.78: icmp_seq=1 ttl=53 time=132.527 ms

--- hyochan.site ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss   # 살아있다
round-trip min/avg/max/stddev = 132.527/132.607/132.686/0.080 ms

$ curl -s -o /dev/null -w '%{http_code}\n' https://hyochan.site
200                                                            # 서비스도 정상이다

호스트도 경로도 정상이다. 별표 3개는 중간 라우터 3대가 자기 존재를 안 밝힌 것뿐이다. 이걸 장애로 읽었다면 멀쩡한 경로를 몇 시간씩 팠을 것이다.

중간 홉 별표는 probe 프로토콜을 바꿔도 못 고친다. 중간 홉 표시는 본질적으로 각 라우터의 ICMP 반환에 의존하기 때문이다. 바꿀 수 있는 건 최종 목적지 도달 판정이고, 이건 모드에 따라 갈린다.

모드도달 판정 근거목적지가 그 응답을 막으면
기본 (UDP probe)목적지의 ICMP Port Unreachable영영 별표
-I (ICMP probe)목적지의 Echo Reply영영 별표
TCP probe (-T / -P TCP)목적지의 SYN-ACK 또는 RST도달 판정 가능

위 예시의 목적지는 UDP probe에도 ICMP에도 다 응답해서 기본 모드로 그냥 도달했다. 표의 "영영 별표"는 그 응답을 막아둔 목적지에만 해당한다. 클라우드 VM 기본 설정처럼 ICMP와 UDP를 다 잠근 호스트가 여기 걸린다.

그때 TCP probe를 쓴다. 443 포트로 SYN을 보내면 서비스가 살아있는 한 SYN-ACK가 돌아오므로, ICMP 정책과 무관하게 도달을 확인할 수 있다. 플래그가 OS마다 다르고 둘 다 root 권한이 필요하다.

sudo traceroute -T -p 443 hyochan.site

sudo traceroute -T -p 443 hyochan.site

sudo traceroute -P TCP -p 443 hyochan.site

리눅스에서 -P TCP를 쓰면 Cannot handle `protocol' keyword with arg `TCP' (argc 1)로 실패한다. 소문자 -P tcp도 똑같이 실패한다. 리눅스 traceroute의 -P는 IP 프로토콜 번호를 받는 옵션이라 TCP probe 스위치가 아니다. -T가 그 역할을 한다.

그래서 도달성 확인의 1차 도구는 ping이 아니라 nc -vz여야 한다. TCP는 서비스가 실제로 응답해야만 연결이 열리므로 ICMP 차단 정책에 오염되지 않는다. ping은 보조 수단으로 쓰고, 실패했을 때는 판단 근거로 삼지 않는다.

L4(TCP/UDP) — 도착은 보장하지만 내용은 다 보인다

L4는 포트로 프로세스를 구분하고, TCP는 여기에 신뢰성을 얹는다.

IP는 "어느 컴퓨터"까지만 안내한다. 그 컴퓨터에서 도는 수십 개 프로세스 중 누구에게 줄지는 모른다. 포트 번호가 그걸 해결한다. 443번은 웹 서버, 22번은 SSH다.

TCP와 UDP의 차이는 신뢰성을 누가 책임지느냐다.

TCPUDP
연결3-way handshake로 수립없음
순서 보장OX
재전송OX
속도상대적으로 느림빠름
쓰는 곳HTTP, SSH, DBDNS, 화상통화, 게임

TCP는 보내기 전에 악수부터 한다.

sequenceDiagram
    participant C as Client
    participant S as Server
    C->>S: SYN (연결하자)
    S->>C: SYN-ACK (그래, 나도 하자)
    C->>S: ACK (좋다)
    Note over C,S: 연결 수립, 이제 데이터 전송
Diagram: sequenceDiagram participant C as Client participant S as Server C->>S: SYN (연결하자) S->>C: SYN-ACK (그래, 나도 하자) C->>S: ACK (좋다) Note over C,S: 연결 수립, 이제 데이터 전송

여기서 중요한 실전 포인트가 하나 있다. 핑이 간다고 포트가 열린 게 아니다. ping은 ICMP라서 L3만 검증한다. 포트 확인은 따로 해야 한다.

$ nc -vz hyochan.site 443
Connection to hyochan.site port 443 [tcp/https] succeeded!

TCP의 한계는 내용이 평문으로 흐른다는 것이다. 중간 라우터가 마음만 먹으면 다 읽는다.

TLS — 표준에 없는 계층

TLS는 표준 계층 모델에 자리가 없지만, 실무에서는 독립된 단계로 다루는 게 맞다.

TCP/IP 4계층 기준으로 TLS는 Application에 속한다. 하지만 이렇게 분류하면 디버깅할 때 손해다. TLS는 HTTP와 명백히 다른 단계에서 실패하고, 실패 원인도 완전히 다르기 때문이다. 인증서 만료, 체인 불완전, SNI 불일치, 프로토콜 버전 미스매치는 HTTP와 아무 상관이 없다.

실제로 TLS만 따로 떼어 검증할 수 있다.

$ openssl s_client -connect hyochan.site:443 -servername hyochan.site </dev/null
...
Verify return code: 0 (ok)

</dev/null을 빼면 stdin을 계속 물고 있어서 프롬프트가 안 돌아온다.

Verify return code: 0이면 TLS까지는 정상이다. 여기서 실패하면 HTTP는 볼 필요도 없다.

참고로 이 글의 참고자료에 걸어둔 Explained from First Principles의 저자도 같은 이유로 TLS를 별도 "security layer"로 두면서, 이건 표준이 아니라 편의상 자신이 추가한 것이라고 명시한다. 정직한 태도이고 실무 감각과도 맞는다.

L7(HTTP/DNS) — 사람이 쓰는 이름

L7은 사람이 다루는 이름과 의미를 실제 주소·요청으로 바꾼다.

여기서 DNS의 위치를 짚고 갈 필요가 있다. DNS도 L7이지만, 목적지로 가는 L3·L4를 정하기 위해 먼저 돈다. DNS 질의 자체는 리졸버로 향하는 별도의 L3·L4를 탄다. DNS가 L3 아래에 있다는 뜻이 아니다.

항상 도는 것도 아니다. OS·브라우저 캐시에 있거나 /etc/hosts에 박혀 있거나 IP를 직접 찍으면 DNS는 아예 생략된다.

그래도 이 순서 때문에 아주 흔한 증상이 하나 나온다. IP로는 접속되는데 도메인으로는 안 되는 경우다. L3, L4, TLS 전부 정상이고 이름 해석만 실패한 것이다.

$ dig hyochan.site +short
104.21.15.78
172.67.161.243

$ dig @1.1.1.1 hyochan.site +short   # 리졸버를 바꿔서 교차 검증
104.21.15.78
172.67.161.243

A 레코드가 여러 개인 건 정상이다. Cloudflare처럼 Anycast를 쓰는 곳은 보통 2개 이상을 내려주고, 클라이언트가 그중 하나를 골라 붙는다.

두 결과가 다르거나 한쪽만 응답하면 리졸버 캐시나 로컬 DNS 설정을 의심한다.

DNS의 Anycast, CNAME flattening, DoH 동작은 DNS 딥다이브에서 따로 다뤘다.

curl 한 번에 벌어지는 일

curl https://hyochan.site 한 줄에 지금까지의 모든 계층이 순서대로 동원된다.

sequenceDiagram
    participant U as curl
    participant D as DNS resolver
    participant S as Server

    U->>D: hyochan.site 주소가 뭐야? (L7/UDP)
    D->>U: 104.21.15.78
    Note over U: 이제야 L3 목적지가 정해짐
    U->>S: SYN / SYN-ACK / ACK (L4)
    U->>S: TLS ClientHello → 인증서 검증 (TLS)
    U->>S: GET / HTTP/2 (L7)
    S->>U: 200 OK
Diagram: sequenceDiagram participant U as curl participant D as DNS resolver participant S as Server U->>D: hyochan.site 주소가 뭐야? (L7/UDP) D->>U: 104.21.15.78 Note over U: 이제야 L3 목적지가 정해짐 U->>S: SYN / SYN-ACK / ACK (L4) U->>S: TLS ClientHello → 인증서 검증 (TLS) U->>S: GET / HTTP/2 (L7) S->>U: 200 OK

이 순서를 외워두면 디버깅 순서가 자동으로 정해진다. 위에서부터 하나씩 끊어보면 된다.

삽질 기록 — 증상으로 계층 좁히기

증상을 계층에 매핑해두면 검색보다 빠르다. 기준 도구는 ping이 아니라 nc -vz다.

증상의심 계층확인 명령
링크가 아예 안 잡힘L1/L2ip link
같은 서브넷인데 연결이 안 됨L2ip neigh
다른 서브넷으로 연결이 안 됨L3ip route, traceroute (도달 확인은 -T / macOS -P TCP)
특정 포트만 안 열림L4nc -vz host 443, 서버에서 sudo ss -tlnp
연결은 되는데 인증서 오류TLSopenssl s_client -connect host:443 </dev/null
IP는 되는데 도메인만 안 됨L7 (DNS)dig +short, dig @1.1.1.1
다 되는데 502 / 504L7 (HTTP)curl -v

표에서 ping이 빠진 게 핵심이다. ping 실패는 진단 근거가 될 수 없다. 앞 섹션에서 본 대로 ICMP를 막아둔 정상 호스트와 진짜 죽은 호스트가 똑같이 보이기 때문이다.

리눅스는 도구가 없으면 설치한다. macOS는 설치할 게 없다.

sudo apt install -y iproute2 dnsutils traceroute netcat-openbsd

sudo dnf install -y iproute bind-utils traceroute nmap-ncat

# nc, dig, traceroute, arp 모두 기본 탑재라 설치할 게 없다.
# 단 ip와 ss는 존재하지 않으므로 대체 명령을 쓴다.
# traceroute TCP probe도 -T가 아니라 -P TCP다.
ifconfig          # ip link 대신
arp -an           # ip neigh 대신
netstat -an       # ss -tln 대신

그런데 도입부의 521은 이 표만으로는 안 풀린다. 함정이 하나 더 있다.

프록시 뒤에서는 ping도 nc -vz도 엣지까지만 검증한다. 도메인으로 뭘 찍든 Cloudflare가 대신 대답하기 때문이다. 표의 명령을 아무리 순서대로 돌려도 전부 초록불이 뜬다. 정작 오리진은 죽어 있는데도 그렇다.

그래서 프록시를 쓰는 순간 검증 대상을 도메인이 아니라 오리진 IP로 바꿔야 한다.

$ nc -vz 203.0.113.10 443        # 도메인이 아니라 오리진 IP를 직접 (IP는 예시다)
nc: connect to 203.0.113.10 port 443 (tcp) failed: Connection refused

여기서 처음으로 진짜 정보가 나온다. 사실 Cloudflare는 이미 답을 주고 있었다. 521은 "엣지는 살아있는데 오리진이 안 받는다"는 뜻이다. 어느 계층에서 끊겼는지 에러 코드가 알려주고 있었는데, 계층을 모르니 그걸 못 읽었던 것이다.

계층을 모르면 도구가 있어도 못 읽는다. 그래서 계층이 기본기다.

정리

핵심은 다음과 같다.

계층식별자대표 프로토콜검증 도구
Link (L2)MAC 주소Ethernet, Wi-Fiip link, ip neigh
Internet (L3)IP 주소IP, ICMPip route, traceroute (도달 확인은 -T / macOS -P TCP)
Transport (L4)포트 번호TCP, UDPnc -vz, sudo ss -tlnp
(TLS)인증서TLS 1.3openssl s_client
Application (L7)도메인, URLHTTP, DNSdig, curl -v

기억할 것은 네 가지다.

  1. 실무 모델은 TCP/IP 4계층이다. OSI 7계층은 호칭만 빌려 쓴다.
  2. 각 계층은 앞 계층의 한계 때문에 생겼다. 이 순서로 보면 외울 게 없다.
  3. 계층은 디버깅 좌표계다. 증상이 어느 계층인지 정하면 후보가 절반씩 줄어든다.
  4. ping 실패는 근거가 아니다. ICMP는 막혀 있는 게 정상인 경우가 더 많다. 도달성은 TCP로 확인한다.

네트워크 기본기라는 건 결국 이거다. 프로토콜 헤더 필드를 외우는 게 아니라, 문제가 났을 때 어디를 안 봐도 되는지 아는 것이다.

참고자료

관련 태그

#dns#http#infra#l2#l3#networking#osi-model#packet#routing#tcp#tcp-ip#tls#troubleshooting#udp

자주 묻는 질문

OSI 7계층과 TCP/IP 4계층 중 뭘 알아야 하나?
실무에서는 TCP/IP 4계층이다. 실제 인터넷 프로토콜은 TCP/IP 모델로 설계됐고 OSI 7계층은 그 이후에 나온 참조 모델이라 현실과 어긋난다. 다만 L2, L3, L7 같은 호칭 자체가 OSI 번호에서 왔기 때문에 용어로는 계속 쓰인다.
TLS는 몇 계층인가?
표준 모델에는 TLS를 위한 계층이 없다. TCP/IP 4계층 기준으로는 Application 계층에 속하지만, 실무에서는 Transport와 Application 사이의 독립된 단계로 다루는 편이 디버깅에 유리하다. 실제로 openssl s_client로 TLS만 따로 떼어 검증할 수 있다.
ping은 가는데 웹페이지가 안 열리면 어디를 봐야 하나?
L4 이상을 봐야 한다. ping은 ICMP라서 L3까지만 검증하고 포트는 확인하지 않는다. nc -vz로 포트가 열렸는지 보고, 열렸다면 openssl s_client로 TLS를, 그다음 curl -v로 HTTP를 순서대로 확인한다.
Cloudflare를 쓰는데 ping은 되고 사이트는 521 에러가 난다. 왜 그런가?
ping이 응답한 대상이 오리진 서버가 아니라 Cloudflare 엣지이기 때문이다. 프록시가 켜진 도메인은 DNS가 Cloudflare IP를 내려주므로 ping도 nc도 엣지까지만 검증하고, 엣지는 오리진이 죽어도 항상 살아있다. 521은 엣지는 정상이고 오리진이 연결을 받지 않는다는 뜻이므로, 오리진 IP로 직접 nc -vz를 찍어서 확인해야 한다.
도메인은 안 되는데 IP로는 접속되면 무슨 문제인가?
DNS 문제다. L3와 L4는 정상이고 이름을 IP로 바꾸는 단계만 실패한 것이다. dig 도메인 +short로 응답이 오는지 확인하고, 응답이 없으면 dig @1.1.1.1 도메인으로 리졸버를 바꿔 테스트해서 리졸버 문제인지 권한 네임서버 문제인지 가른다.
traceroute 중간에 별표(*)가 뜨면 장애인가?
대부분 장애가 아니다. 중간 라우터가 ICMP Time Exceeded 응답을 보내지 않도록 설정된 경우가 흔하고, 이 경우 별표가 떠도 패킷 자체는 정상적으로 통과한다. 별표 다음 홉이 응답한다면 그 구간을 정상 통과했다는 증거다.
ping이 안 되면 서버가 죽은 건가?
아니다. ping 실패는 아무것도 증명하지 못한다. ICMP echo는 클라우드 보안그룹 기본값, Windows 방화벽 기본값, 하드닝된 호스트에서 일상적으로 차단되기 때문에 멀쩡한 서버도 ping에 응답하지 않는다. 도달성은 nc -vz host 443처럼 실제 서비스 포트에 TCP로 확인해야 한다.
목적지가 ICMP를 막아도 traceroute를 쓸 수 있나?
TCP 모드를 쓰면 된다. 플래그가 OS마다 다른데 리눅스는 sudo traceroute -T -p 443 host이고 macOS는 sudo traceroute -P TCP -p 443 host다. 리눅스의 -P는 IP 프로토콜 번호를 받는 옵션이라 -P TCP로 쓰면 실패한다. 목적지가 SYN-ACK나 RST로 답하므로 ICMP 차단과 무관하게 도달 판정이 가능하지만, 중간 홉 표시는 여전히 각 라우터의 ICMP Time Exceeded에 의존하므로 별표는 그대로 남는다.