NETWORK FUNDAMENTALS기초 준비의 역할과 동작 원리
기초 준비는 명령어부터 외우는 과정이 아닙니다. 케이블과 광 모듈이 장비·거리·속도에 맞는지, 링크 양쪽의 속도와 Duplex가 일치하는지 확인한 뒤 VLAN, IP, 경로와 서비스를 순서대로 올려야 합니다.
물리 계층이 불안정하면 Ping이 간헐적으로 되고 CRC·drop이 증가하며 상위 장비의 정책 문제처럼 보일 수 있습니다. 그래서 링크 → VLAN·MTU → IP·Prefix → Gateway·Route → TCP·업무 응답 순서로 정상 기준선을 만듭니다.
→2. 링크 협상Speed · Duplex · Auto →3. VLAN·IPPrefix · MTU · Bonding →4. 경로·서비스Gateway · TCP · HTTP 그림 해설 · 케이블과 링크 조건을 먼저 맞춘 뒤 VLAN·IP, 라우팅, 실제 서비스 순서로 확인해야 최초 실패 지점을 찾을 수 있습니다.
01OSI 7계층을 장애 분석에 사용하는 법펼쳐보기
OSI 7계층은 통신 기능을 나누어 이해하기 위한 기준 모델입니다. 실제 인터넷은 TCP/IP 모델로 구현되며 장비 하나가 여러 계층을 함께 처리할 수 있으므로, 장비 이름을 억지로 한 계층에만 넣기보다 패킷의 어느 정보를 보고 어떤 동작을 하는지 판단해야 합니다.
- L1 물리: UTP·광케이블, 전기·광 신호, 커넥터, 링크·속도·Duplex를 확인합니다.
- L2 데이터링크: Ethernet Frame, MAC, VLAN, STP와 같은 망 전달을 확인하며 스위치가 대표적입니다.
- L3 네트워크: IP·Prefix, ICMP, Routing과 Gateway를 확인하며 라우터와 L3 방화벽이 이 정보를 사용합니다.
- L4 전송: TCP·UDP, 포트, 3-way handshake, 재전송과 세션을 확인하며 방화벽·로드밸런서 정책에 연결됩니다.
- L5 세션: 연결의 생성·유지·종료와 상태 관리를 봅니다. 실무에서는 TCP 세션이나 애플리케이션 세션과 함께 설명되는 경우가 많습니다.
- L6 표현: 문자 인코딩·직렬화·압축·암호화를 다룹니다. TLS 때문에 IPS가 payload를 볼 수 없는 상황도 이 관점으로 이해합니다.
- L7 응용: HTTP·DNS·SSH와 실제 로그인·조회 같은 사용자 기능을 확인하며 WAF·프록시·애플리케이션 로그가 관련됩니다.
- 장애 확인은 보통 L1 링크 → L2 VLAN·MAC → L3 IP·Route → L4 포트·세션 → L7 실제 업무 응답 순서로 올라갑니다.
02UTP와 광케이블은 언제 사용하는가펼쳐보기
UTP는 일반적인 RJ45 이더넷 구간에 사용하며 설치와 교체가 쉽지만 규격별 속도와 약 100m 거리 제한을 확인해야 합니다. 광케이블은 전자기 간섭에 강하고 장거리·고속 링크에 적합하지만 광 모듈, 파장, 커넥터와 광 감쇠 조건이 모두 맞아야 합니다.
- UTP는 Cat5e·Cat6·Cat6A 등 케이블 등급과 장비 포트가 지원하는 속도를 함께 확인합니다.
- 멀티모드 광(MMF)은 비교적 짧은 건물·전산실 구간에, 싱글모드 광(SMF)은 장거리와 캠퍼스·통신 구간에 주로 사용합니다.
- MMF와 SMF, 서로 다른 파장·속도의 SFP/SFP+ 모듈을 임의로 혼용하지 않습니다.
- LC·SC 같은 커넥터 형상, Tx/Rx 극성, 광 수신 세기와 오염 상태도 확인합니다.
03속도와 Duplex를 왜 양쪽에서 맞추는가펼쳐보기
Full Duplex는 송신과 수신을 동시에 수행하며 현대 스위치 연결의 기본입니다. Half Duplex는 한 번에 한 방향만 전송하고 충돌을 처리하는 오래된 방식입니다. 한쪽이 Full, 다른 쪽이 Half이면 링크가 UP이어도 충돌·재전송·CRC 오류와 심한 성능 저하가 발생할 수 있습니다.
- Auto Negotiation은 양쪽이 지원 능력을 교환해 속도와 Duplex를 정하므로 일반적으로 양쪽 모두 Auto가 권장됩니다.
- 운영상 고정 설정이 필요하면 한쪽만 고정하지 말고 양쪽 속도와 Full Duplex를 동일하게 설정합니다.
- ethtool 인터페이스명으로 Speed, Duplex, Auto-negotiation, Link detected와 오류 카운터를 확인합니다.
- 광 포트는 매체·모듈 특성상 협상 방식이 다를 수 있으므로 장비와 모듈 사양을 따릅니다.
04VLAN·Bonding·MTU와 인터페이스 역할펼쳐보기
링크가 정상이어도 access/trunk와 VLAN tagging이 양쪽에서 다르면 프레임이 원하는 망에 도달하지 않습니다. Bonding/LACP는 여러 링크를 하나로 묶지만 양쪽의 모드·멤버·해시 정책이 일치해야 합니다. MTU 불일치는 작은 패킷은 통과하고 큰 패킷만 실패하는 장애를 만듭니다.
- 서비스·관리(MGMT)·HA heartbeat/동기화 인터페이스를 구분합니다.
- ip link와 ethtool로 링크·MAC·MTU를, VLAN과 Bonding 설정으로 논리 구성을 확인합니다.
- 재부팅 후에도 주소·VLAN·Bonding 설정이 유지되는지 반드시 재검증합니다.
05MAC·ARP와 같은 망의 통신펼쳐보기
같은 서브넷의 장비끼리는 Gateway로 보내기 전에 ARP로 상대 IP의 MAC 주소를 찾습니다. 다른 서브넷이면 목적지 서버가 아니라 Gateway의 MAC 주소를 찾습니다. 그래서 IP와 라우팅이 맞아도 ARP가 실패하거나 오래된 VIP MAC이 남으면 통신이 되지 않을 수 있습니다.
- ip neigh 또는 arp -n으로 IP와 MAC의 대응 상태를 확인합니다.
- Gratuitous ARP는 HA 절체 후 VIP의 새 소유자 MAC을 주변 장비에 알리는 데 사용됩니다.
- ARP 요청만 반복되고 응답이 없다면 VLAN, 물리 경로, 상대 주소와 보안 기능을 먼저 확인합니다.
- IPv6에서는 ARP 대신 NDP와 Neighbor Advertisement를 사용합니다.
06서브넷과 Prefix를 알아야 하는 이유펼쳐보기
Prefix는 같은 네트워크로 직접 통신할 주소 범위를 결정합니다. /24와 /25를 혼동하면 일부 주소를 같은 망으로 잘못 판단하거나 Gateway로 보내야 할 트래픽을 로컬에서 ARP하게 됩니다. 방화벽 주소 객체에서도 잘못된 CIDR은 의도보다 넓은 대상을 허용할 수 있습니다.
- /24, /25, /27, /32와 기본 경로 /0의 의미를 구분합니다.
- 네트워크 주소, 브로드캐스트 주소와 실제 호스트 주소 범위를 계산합니다.
- ip route get 목적지IP로 실제 선택된 인터페이스와 Gateway를 확인합니다.
07IP·Prefix·Gateway와 명령어 실습이 필요한 이유펼쳐보기
호스트는 Prefix로 목적지가 같은 네트워크인지 판단하고 다른 네트워크이면 Gateway와 라우팅 테이블을 사용합니다. 따라서 IP와 경로 설정 실습은 필요합니다. 다만 명령어 입력 자체가 목적이 아니라 어느 계층에서 실패했는지 출력으로 증명하는 훈련이어야 합니다.
- ip link와 ethtool로 물리 링크, 속도와 Duplex를 확인합니다.
- ip addr로 IP·Prefix를 확인하고 ip route 또는 netstat -rn으로 기본 게이트웨이와 목적지 경로를 확인합니다.
- ping은 연속 실행 후 Ctrl+C로 손실률과 지연을 확인하고, ss -lnt 또는 netstat -lnt로 포트 상태를 확인합니다.
- curl과 실제 업무 요청으로 애플리케이션 응답을 확인하며 정방향뿐 아니라 리턴 경로도 검증합니다.
- 요청과 응답이 같은 장비 경로를 쓰면 대칭 라우팅, 서로 다른 경로를 쓰면 비대칭 라우팅입니다. Stateful 장비가 양방향을 같은 세션으로 볼 수 있는지 확인합니다.
08TCP·UDP·ICMP를 패킷으로 구분하기펼쳐보기
TCP는 SYN, SYN/ACK, ACK의 3-way handshake로 연결을 만들고 순서와 재전송을 관리합니다. UDP는 연결 과정 없이 datagram을 보내며, ICMP는 Echo뿐 아니라 도달 불가와 MTU 같은 네트워크 오류도 전달합니다.
- SYN만 반복되면 정방향은 갔지만 응답 경로·정책·서비스 LISTEN이 실패했을 수 있습니다.
- Ping 성공은 ICMP 경로가 열린 것이며 TCP 업무 포트의 성공을 의미하지 않습니다.
- UDP는 응답이 없다는 사실만으로 차단과 정상 무응답을 구분하기 어려우므로 서버 로그와 함께 봅니다.
09DNS·포트·실제 서비스 확인펼쳐보기
IP로는 접속되지만 도메인으로 실패하면 DNS 서버, 검색 도메인, 캐시와 UDP/TCP 53 경로를 확인합니다. 프로세스가 실행 중인 것과 포트가 LISTEN 중인 것, 외부 사용자가 실제 업무 요청에 성공하는 것은 서로 다른 검증 단계입니다.
- dig, nslookup, resolvectl로 질의 대상과 응답을 확인합니다.
- ss -lntup 또는 netstat -lntup로 LISTEN 주소와 포트를 확인합니다.
- nc와 curl로 TCP 연결과 HTTP 상태를 확인한 뒤 실제 업무 기능까지 시험합니다.
10Wireshark와 tcpdump로 흐름을 읽는 법펼쳐보기
패킷 캡처는 많이 수집하는 것보다 올바른 위치와 필터를 선택하는 것이 중요합니다. Wireshark에서는 한 통신의 요청과 응답을 시간순으로 따라가고, tcpdump에서는 서버에서 필요한 범위만 PCAP으로 저장해 분석합니다.
- Wireshark 표시 필터 예: arp, icmp, dns, tcp.port == 443, ip.addr == 10.10.10.20
- TCP 연결 분석은 tcp.flags.syn == 1, 재전송은 tcp.analysis.retransmission을 활용합니다.
- tcpdump -ni eth0 host 10.10.10.20 and port 443처럼 인터페이스·호스트·포트를 명시합니다.
- PCAP에는 캡처 위치, 인터페이스, 필터, 시작·종료 시각과 UTC/KST를 함께 기록합니다.
11시간 동기화가 증거 분석에 미치는 영향펼쳐보기
방화벽, IPS, 서버와 PCAP의 시간이 다르면 같은 세션을 서로 다른 사건으로 오해할 수 있습니다. 큰 시간 오차는 인증서 유효기간 오류와 인증 실패도 만들 수 있습니다.
- timedatectl과 chronyc sources로 타임존·동기화 상태·기준 서버를 확인합니다.
- 로그에는 UTC 또는 KST를 명시하고 모든 장비의 오차를 기록합니다.
- 시간을 보정한 뒤 기존 로그의 시간선도 보정값을 반영해 다시 작성합니다.
12관리망과 서비스망을 분리하는 이유펼쳐보기
MGMT 인터페이스는 관리자 접속과 모니터링에 사용하고 서비스 인터페이스는 사용자 트래픽을 전달합니다. 두 역할을 분리하면 서비스망 장애나 공격이 관리 접속까지 직접 확산되는 위험을 줄일 수 있습니다.
- 관리망은 허용된 운영 단말과 점프 서버에서만 접근하게 합니다.
- HA heartbeat·동기화 링크도 업무 트래픽과 분리해 장애 범위를 줄입니다.
- 인터페이스명·MAC·연결 상대·스위치 포트를 표로 남겨 실제 배선과 설정을 연결합니다.