-
Notifications
You must be signed in to change notification settings - Fork 0
KR_Net_OSI_Routing
somaz edited this page Mar 30, 2026
·
1 revision
데이터 송신 시 캡슐화 (Encapsulation):
Application Layer (L7): "Hello"
↓
Presentation Layer (L6): [Encoding] "Hello"
↓
Session Layer (L5): [Session ID] + Data
↓
Transport Layer (L4): [TCP Header (Port)] + Segment
↓
Network Layer (L3): [IP Header (Src/Dst IP)] + Packet
↓
Data Link Layer (L2): [Ethernet Header + MAC] + Frame + [FCS]
↓
Physical Layer (L1): Bits (전기 신호)
각 계층별 PDU (Protocol Data Unit):
- L7-L5 (Application/Presentation/Session): Data
- L4 (Transport): Segment (TCP) / Datagram (UDP)
- L3 (Network): Packet
- L2 (Data Link): Frame
- L1 (Physical): Bits
TCP/IP 4계층 매핑:
OSI 7계층 TCP/IP 4계층
─────────────────────────────────────────
Application (7) ┐
Presentation (6) ├──→ Application Layer
Session (5) ┘
Transport (4) ───→ Transport Layer (TCP/UDP)
Network (3) ───→ Internet Layer (IP, ICMP, ARP)
Data Link (2) ┐
Physical (1) ┘──→ Network Interface Layer
실제 HTTP 요청 예시:
1. Application: HTTP GET /index.html
2. Transport: TCP Header (Src Port: 54321, Dst Port: 80, SEQ, ACK)
3. Network: IP Header (Src: 192.168.1.10, Dst: 93.184.216.34)
4. Data Link: Ethernet Header (Src MAC: aa:bb:cc:dd:ee:ff, Dst MAC: Gateway MAC)
5. Physical: 전기 신호로 전송
디캡슐화 (Decapsulation):
- 수신 측은 역순으로 각 계층의 헤더를 제거하며 데이터 추출
TCP 3-Way Handshake (연결 수립):
Client (CLOSED) Server (LISTEN)
| |
|--------- SYN (SEQ=100) -------------->| (SYN_SENT)
| | (SYN_RECEIVED)
|<-- SYN-ACK (SEQ=200, ACK=101) --------|
| (ESTABLISHED) |
|--------- ACK (ACK=201) -------------->| (ESTABLISHED)
| |
|========= Data Transfer ===============|
상태 변화:
- Client:
CLOSED → SYN_SENT → ESTABLISHED - Server:
LISTEN → SYN_RECEIVED → ESTABLISHED
TCP 4-Way Handshake (연결 종료):
Client Server
| |
|--------- FIN (SEQ=300) -------------->| (FIN_WAIT_1)
| | (CLOSE_WAIT)
|<-------- ACK (ACK=301) ---------------|
| (FIN_WAIT_2) |
| |
|<-------- FIN (SEQ=400) ---------------| (LAST_ACK)
| (TIME_WAIT) |
|--------- ACK (ACK=401) -------------->| (CLOSED)
| |
| (2*MSL 대기 후 CLOSED) |
TIME_WAIT 상태 (2MSL):
- 목적: 지연된 패킷 처리, 마지막 ACK 재전송 대비
- MSL (Maximum Segment Lifetime): 보통 30초~2분
- 문제: 많은 연결 생성/종료 시 소켓 고갈
-
해결:
SO_REUSEADDR, Connection Pooling
Half-Close:
Client: shutdown(SHUT_WR) → 송신 종료, 수신 가능
Server: 데이터 계속 전송 가능
→ 양방향 독립적 종료 가능
비정상 종료 (RST):
RST 플래그: 즉시 연결 종료 (4-Way 없음)
사용 경우:
- 존재하지 않는 포트 접속
- 타임아웃
- 애플리케이션 강제 종료
BGP Path Selection Process (13단계):
1. Weight (Cisco 전용, 높을수록 우선)
2. Local Preference (AS 내부, 높을수록 우선)
3. Locally Originated (자체 생성 경로 우선)
4. AS-PATH Length (짧을수록 우선)
5. Origin Type (IGP > EGP > Incomplete)
6. MED (Multi-Exit Discriminator, 낮을수록 우선)
7. eBGP > iBGP
8. IGP Metric (낮을수록 우선)
9. Oldest Route (가장 오래된 경로)
10. Router ID (낮을수록 우선)
11. Cluster List Length (짧을수록 우선)
12. Neighbor IP (낮을수록 우선)
AS-PATH 속성:
AS-PATH: 65001 65002 65003
→ 패킷이 거쳐온 AS 번호 순서
목적:
1. 루프 방지 (자신의 AS 번호가 있으면 거부)
2. 경로 길이 계산
3. 라우팅 정책 적용 (특정 AS 경유 방지)
AS-PATH Prepending (트래픽 제어):
Normal: AS-PATH: 65001
Prepended: AS-PATH: 65001 65001 65001 (인위적으로 길게)
→ 다른 경로 선호하도록 유도
BGP Communities:
- NO_EXPORT (65535:65281): 다른 AS로 광고 금지
- NO_ADVERTISE (65535:65282): 다른 BGP 피어에 광고 금지
- Custom: 예) 100:10 (백업 경로)
실무 예시 (AWS Direct Connect):
AS-PATH Prepending으로 Primary/Secondary 링크 제어
Primary: AS-PATH 64512
Secondary: AS-PATH 64512 64512 64512
→ Primary 장애 시 자동 Secondary 전환
BGP Hijacking 방지:
- RPKI (Resource Public Key Infrastructure): AS와 IP 매핑 검증
- Route Origin Validation (ROV): 유효한 AS만 prefix 광고 가능
OSPF Area 계층 구조:
Area 0 (Backbone)
[ABR]─────[ABR]
/ \
/ \
Area 1 Area 2
(Regular) (Stub/NSSA)
Area 타입:
- Backbone Area (Area 0): 모든 Area가 연결되는 중심
- Regular Area: 모든 LSA 타입 허용
- Stub Area: Type 4, 5 LSA 차단 (기본 경로로 대체)
- Totally Stub Area: Type 3, 4, 5 LSA 차단
- NSSA (Not-So-Stubby Area): Type 5 대신 Type 7 사용 (재분배 허용)
LSA (Link State Advertisement) 타입:
Type 1 (Router LSA):
- 각 라우터가 자신의 링크 상태 광고
- 같은 Area 내에만 전파
Type 2 (Network LSA):
- DR (Designated Router)이 멀티액세스 네트워크 정보 광고
- Ethernet, Frame Relay 등
Type 3 (Summary LSA):
- ABR이 다른 Area의 네트워크 정보를 요약하여 광고
- Inter-Area 라우팅
Type 4 (ASBR Summary LSA):
- ABR이 ASBR (AS Boundary Router) 위치 광고
- Type 5 LSA 도달 경로
Type 5 (External LSA):
- ASBR이 외부 AS의 라우트 광고 (재분배)
- 전체 OSPF 도메인에 전파
Type 7 (NSSA External LSA):
- NSSA에서 사용하는 External LSA
- ABR이 Type 5로 변환하여 Backbone으로 전파
OSPF 동작 흐름:
1. Hello 패킷 교환 → Neighbor 발견
2. DR/BDR 선출 (멀티액세스 네트워크)
3. DBD (Database Description) 교환 → LSDB 동기화
4. LSR/LSU 교환 → 누락된 LSA 요청/전송
5. SPF (Dijkstra) 알고리즘 실행 → 최단 경로 계산
6. 라우팅 테이블 업데이트
Area 설계 모범 사례:
- Area당 라우터 50개 이하 권장
- ABR은 최대 3개 Area에만 연결
- Stub Area로 LSA 수 감소
NAT (Network Address Translation) 타입:
Static NAT (1:1):
Private IP Public IP
192.168.1.10 ←→ 203.0.113.5 (고정 매핑)
→ 서버 운영 시 사용 (웹서버, 메일서버)
Dynamic NAT (N:M):
Private Pool: 192.168.1.10~192.168.1.20
Public Pool: 203.0.113.5~203.0.113.10
→ 요청 시 동적 할당
PAT (Port Address Translation, NAPT):
Private Public
192.168.1.10:54321 ←→ 203.0.113.5:10001
192.168.1.11:54322 ←→ 203.0.113.5:10002
192.168.1.12:54323 ←→ 203.0.113.5:10003
→ 하나의 Public IP로 수천 개의 내부 호스트 지원
NAT Translation Table:
| Inside Local | Inside Global | Outside Global | Outside Local |
|----------------|----------------|----------------|----------------|
| 192.168.1.10:54321 | 203.0.113.5:10001 | 8.8.8.8:53 | 8.8.8.8:53 |
NAT Traversal 문제:
- P2P 애플리케이션 (VoIP, 게임, 화상회의) 연결 실패
- 내부 → 외부는 가능하지만 외부 → 내부 연결 불가
NAT Traversal 기법:
1. STUN (Session Traversal Utilities for NAT):
Client → STUN Server
STUN Server: "당신의 Public IP는 203.0.113.5:10001입니다"
→ Symmetric NAT에서는 실패
2. TURN (Traversal Using Relays around NAT):
Client A ← → TURN Server ← → Client B
→ 모든 트래픽이 중계 서버 경유 (대역폭 소모)
3. ICE (Interactive Connectivity Establishment):
1. STUN으로 Public IP 획득 시도
2. 실패 시 TURN으로 Fallback
3. 여러 Candidate 중 최적 경로 선택
→ WebRTC에서 사용
4. UPnP (Universal Plug and Play):
애플리케이션이 라우터에 포트 포워딩 자동 설정 요청
→ 보안 위험 (악성코드 악용 가능)
5. Port Forwarding (Static):
Router: 외부 80 → 192.168.1.10:80
외부 443 → 192.168.1.10:443
→ 서버 운영 시 수동 설정
NAT 한계:
- End-to-End 원칙 위배
- IPsec ESP 모드 문제 (NAT-T로 해결)
- FTP Active 모드 실패 (ALG로 해결)
ARP (Address Resolution Protocol) 동작:
1. Host A: "192.168.1.1의 MAC 주소가 뭐지?" (Broadcast)
2. Gateway: "192.168.1.1은 00:11:22:33:44:55입니다" (Unicast)
3. Host A: ARP Cache에 저장
ARP Cache Table:
$ arp -a
192.168.1.1 00:11:22:33:44:55 dynamic
192.168.1.10 aa:bb:cc:dd:ee:ff dynamic
ARP Spoofing 공격 (중간자 공격):
Normal:
Client ← → Gateway ← → Internet
Attack:
Client ← → Attacker ← → Gateway ← → Internet
(트래픽 가로채기)
공격자가 위조된 ARP Reply 전송:
"192.168.1.1(Gateway)의 MAC은 [Attacker MAC]입니다"
→ Client의 ARP Cache 오염
→ 모든 트래픽이 공격자를 경유
방어 방법:
1. Static ARP Entry:
# Linux
arp -s 192.168.1.1 00:11:22:33:44:55
# Windows
arp -s 192.168.1.1 00-11-22-33-44-55- 장점: ARP Spoofing 완전 차단
- 단점: 수동 관리 필요, MAC 변경 시 업데이트
2. DAI (Dynamic ARP Inspection):
Switch에서 ARP 패킷 검증:
- DHCP Snooping Database와 비교
- 유효한 ARP만 전달
- 신뢰할 수 있는 포트는 검증 생략
3. ARP 모니터링 도구:
# arpwatch (Linux)
arpwatch -i eth0
→ ARP 변경 감지 시 알림
# XArp (Windows)
→ GUI 기반 ARP 모니터링4. 네트워크 세그멘테이션:
VLAN으로 브로드캐스트 도메인 분리
→ ARP Spoofing 영향 범위 축소
5. Port Security (MAC 주소 제한):
switchport port-security maximum 2
switchport port-security violation restrict
switchport port-security mac-address sticky
6. IPsec/VPN:
- 암호화로 ARP Spoofing 무력화
- 공격자가 트래픽을 가로채도 복호화 불가
기존 Hub & Spoke (VPN):
┌─────────┐
│ Hub DC │ (Central VPN Gateway)
└────┬────┘
┌──────┼──────┐
│ │ │
┌──▼──┐┌──▼──┐┌──▼──┐
│Spoke││Spoke││Spoke│
│ 1 ││ 2 ││ 3 │
└─────┘└─────┘└─────┘
장점:
- 중앙 집중식 보안 정책
- 관리 단순화
단점:
- Hub 장애 시 전체 통신 불가 (SPOF)
- Hub 병목 현상
- Spoke 간 통신은 Hub 경유 (2배 홉)
AWS Transit Gateway 아키텍처:
┌─────────────────┐
│ Transit Gateway │ (Managed Service)
└────────┬────────┘
┌───────────┼───────────┐
│ │ │
┌──▼──┐ ┌──▼──┐ ┌──▼──┐
│ VPC │ │ VPC │ │ VPC │
│ A │ │ B │ │ C │
└─────┘ └─────┘ └─────┘
│ │ │
┌──▼──┐ ┌──▼──┐ ┌──▼──┐
│ DX │ │ VPN │ │ VPC │
└─────┘ └─────┘ │ D │
└─────┘
Transit Gateway 장점:
1. 고가용성:
- Multi-AZ 자동 배포
- 리전 내 99.95% SLA
2. 확장성:
- VPC당 최대 5,000개 연결
- 50 Gbps 처리량
3. 라우팅 테이블 분리:
Route Table 1 (Production):
VPC-Prod-A ↔ VPC-Prod-B
Route Table 2 (Development):
VPC-Dev-A ↔ VPC-Dev-B
→ Isolation between environments
4. Transit Gateway Peering:
Region A TGW ← → Region B TGW
→ Cross-Region VPC 통신
5. Centralized Egress:
All VPCs → Transit Gateway → Egress VPC (NAT Gateway, Firewall)
→ 중앙 집중식 인터넷 출구
비용 비교:
Hub & Spoke (VPN):
- VPN 연결당 $0.05/hour * N개
- 데이터 전송 비용
Transit Gateway:
- Attachment당 $0.05/hour * N개
- 데이터 처리 $0.02/GB
→ 10개 이상 VPC 연결 시 Transit Gateway가 경제적
마이그레이션 전략:
1. Transit Gateway 생성
2. VPC Attachment 추가 (기존 VPN 유지)
3. 라우팅 테이블 점진적 전환
4. 검증 후 기존 VPN 제거
💡 용어 설명:
- OSI 7계층 및 라우팅 관련 질문들(Q6-Q12)에서 사용된 용어들(TCP Handshake, BGP AS-PATH, OSPF LSA, NAT/PAT, ARP Spoofing, Transit Gateway 등)에 대한
- 상세한 설명은 문서 상단의 주요 용어 통합 정리 > OSI 7계층 & TCP/IP 4계층 및 라우팅 & 네트워크 아키텍처 섹션을 참고하세요.