네트워크심화 · 18분 읽기
GRE의 캡슐화·경로 의존성과 MTU
원본 본사·지사 터널을 따라 내부 패킷과 외부 패킷의 주소를 분리하고, 실제 경로 조회·GRE 헤더·재귀 라우팅·MTU 계산을 설명합니다.
개념부터 찾아보기
정의·역할·동작 원리를 독립 페이지에서 확인하세요. 본문의 밑줄 용어에도 설명이 있습니다.
이 노트에서 설명할 수 있게 되는 것
- 내부 패킷과 외부 패킷의 주소 및 경로 조회를 각각 설명한다.
- GRE 기본 헤더와 옵션, MTU 증가량을 계산한다.
- 재귀 라우팅·한 방향 전달·큰 패킷 실패를 서로 다른 근거로 조사한다.
01GRE가 만드는 것은 논리적인 링크다
- 캡슐화()는 원래의 네트워크 패킷을 다른 네트워크 패킷의 페이로드로 운반하는 캡슐화 방식이다. 중간 라우터는 바깥 IP 헤더를 보고 터널 종단까지 전달하고, 반대편 종단은 이를 벗겨 내부 패킷을 다시 처리한다.
- 새로운 물리 케이블을 만드는 것은 아니다.
- 보호하지 않는 기능는 표준 캡슐화 중 하나이며 IP-in-IP, , 다른 터널 방식 모두를 뜻하지 않는다. 자체에는 기밀성·상대 인증이 없다.
- 패킷을 한 번 더 감쌌다고 내용을 읽을 수 없게 되는 것은 아니다.
02구성에서 내부 주소와 외부 주소 나누기
- 실습의 내부·외부 주소원본의 R2-R4 Tunnel1 내부 주소는 10.1.1.0/24이며, tunnel source와 destination은 두 라우터의 외부 인터페이스 주소다. R2/R4의 바깥쪽은 를 통해 R1을 거쳐 통신하고, 양끝 내부망은 와 를 사용한다.
- 프로토콜 이름이 다르다는 사실보다 각 주소를 어떤 테이블 항목으로 도달하는지가 중요하다.
- 원래 패킷과 Outer 목적지PC1에서 PC2로 가는 원래 IP 목적지는 PC2다. R2는 그 목적지 경로가 Tunnel1임을 보고 로 감싼 뒤, 바깥 목적지를 R4 WAN 주소로 둔다.
- R1은 내부 PC2 주소에 대한 정보 없이도 바깥 패킷을 R4로 보낼 수 있다.
- R4는 역캡슐화 후 내부 PC2망 경로를 조회한다.
- 반환 방향은 별도 경로가 필요하다.
수업 원본 자료
외부 OSPF 경로 위에 만든 본사·지사 터널
원본 크기로 보기 ↗이 자료에서 읽어낼 것
- 실제 터널 종단은 R2와 R4다. 점선은 R1을 우회하는 새 물리선이 아니라, R1을 지나는 외부 IP 경로 위의 논리 연결이다.
- 터널 내부 주소는 10.1.1.0/24이다. tunnel source/destination은 이 내부 주소가 아니라 R2/R4의 외부 인터페이스 주소를 지정한다.
- PC1에서 PC2로 가는 원래 패킷과 이를 운반하는 외부 패킷은 다른 주소를 사용한다. 내부 목적지는 내부망 경로, 외부 목적지는 OSPF 경로로 해석한다.
- EIGRP 영역과 터널의 선을 그렸다는 사실만으로 경로 광고나 암호화가 완성되지는 않는다. 원문도 내부 라우터에 기본 경로를 추가하고 IPsec SA·카운터를 따로 확인했다.
03기본 GRE 헤더와 Protocol Type
- 기본 헤더 위의 기본 에서는 바깥 IP Protocol이 47이며, 기본 헤더는 4바이트다. 버전·플래그와 Protocol Type이 들어가고, Protocol Type은 안쪽이 인지 인지 등 페이로드 종류를 나타낸다.
- 는 0x0800, 는 0x86dd 같은 값으로 식별한다.
- 옵션·Protocol Type옵션을 사용하면 checksum, key, sequence와 관련된 필드가 붙어 길이가 늘 수 있다. 는 터널·흐름을 구분하는 식별값으로 쓰이며 암호화용 비밀키나 피어 인증을 대신하지 않는다.
- Sequence Number가 있다고 와 같은 신뢰성 있는 전송·재전송 기능을 보장하는 것도 아니다.
| 바깥에서 안쪽 순서 | 주요 의미 | 검사 지점 |
|---|---|---|
| 외부 IP 헤더 | 종단 주소, | 중간 라우터가 전달하는 기준 |
| 기본/옵션 헤더 | 안쪽 프로토콜 종류·선택 식별 정보 | 수신 터널의 역캡슐화 |
| 내부 IP 패킷 | 원래 호스트와 목적지 | 종단 이후 실제 목적망 경로 |
원리 심화
04GRE 선택 필드와 내부 프로토콜 식별
- 기본 헤더RFC 2784의 기본 헤더는 Flags/Version 2바이트와 Protocol Type 2바이트다. 바깥 의 Protocol=47은 를, Protocol Type은 안에 든 · 등의 종류를 구분한다.
- Checksum 선택Checksum Present 비트가 설정되면 Checksum과 Reserved1을 합친 4바이트가 추가된다. 헤더가 언제나 4바이트라는 가정은 선택 필드가 없는 경우에만 맞는다.
- Key 선택RFC 2890의 Key Present 비트가 있으면 4바이트 Key가 추가되어 터널 안의 논리 흐름 문맥을 식별할 수 있다. 이름이 Key여도 암호키나 송신자 인증값으로 취급하지 않는다.
- Sequence 선택Sequence Number Present 비트가 있으면 4바이트 순서 번호가 추가된다. 이 필드는 전달 순서 처리와 관련되며 같은 손실 복구·재전송 연결을 제공하는 것은 아니다.
- 수신 해석 순서수신자는 Flags에 따라 선택 필드의 존재를 먼저 판단한 뒤 내부 패킷 시작점을 계산한다. 옵션이 있는 를 고정 4바이트로 건너뛰면 내부 IP 헤더를 잘못 읽게 된다.
05외부 경로와 터널 경로를 따로 설정하기
- 경로 설정아래 예제에서 192.0.2.1과 198.51.100.2는 설명용 WAN 종단이다. 외부망에 상대 WAN 주소로 가는 정상 경로가 이미 있어야 한다.
- 터널 내부는 10.255.0.1/30과 .2/30이며, 상대 LAN 10.20.0.0/24를 터널로 보낸다.
- 실제 장비에서 그대로 인터넷에 연결할 주소는 아니다.
- 반대편 구성반대편은 source/destination을 뒤집고, 내부 주소 .2와 자기 쪽에서 바라본 원격 LAN의 경로를 설정한다. IP를 지정하는 줄에는 마스크가 필요하다.
- 실습 사례에서 ip address까지만 입력해 나온 Incomplete command는 터널 원리가 틀렸다는 뜻이 아니라 필수 인자가 빠진 것이다.
interface Tunnel1
ip address 10.255.0.1 255.255.255.252
tunnel source 192.0.2.1
tunnel destination 198.51.100.2
tunnel mode gre ip
no shutdown
ip route 10.20.0.0 255.255.255.0 10.255.0.2기본 point-to-point 구성 조각. 상대 WAN 도달성·실제 source 소유·반대편 LAN 반환 경로가 준비되어 있어야 한다.
06재귀 라우팅과 겉보기 up의 한계
- 재귀 경로상대 WAN 주소로 가는 경로가 다시 이 Tunnel1을 가리키면 “터널을 만들기 위해 터널을 먼저 지나야 하는” 순환 의존성이 된다. 터널 목적지는 외부망의 실제 경로로 도달하고, 보호하려는 내부망은 터널 경로로 도달하도록 구분해야 한다.
- 넓은 요약 경로나 터널 안의 동적 광고가 상대 WAN 주소까지 덮는지 확인한다.
- Tunnel up의 한계 인터페이스가 up으로 보인다고 원격 피어가 실제 응답했다는 뜻은 아닐 수 있다. 설정된 source의 상태와 목적지 경로 등 로컬 조건으로 line protocol을 판단하는 구현이 있기 때문이다.
- 왕복 ping, 이웃, 캡슐화/역캡슐화 카운터와 양쪽 캡처로 전달을 확인한다.
- Keepalive 지원·동작도 터널 종류와 플랫폼에 따라 다르다.
07MTU: 최소 24바이트도 추가된다
- 헤더 오버헤드 옵션이 없는 외부 헤더 20바이트와 기본 4바이트를 합하면 24바이트가 추가된다. IP 가 1500이고 다른 캡슐화가 없다면 1476바이트 내부 IP 패킷까지 같은 크기 안에 담을 수 있다는 단순 계산이 나온다.
- 옵션·· -T·외부 가 붙으면 다시 계산해야 한다.
- ·MSS큰 패킷을 보냈을 때 분할 가능 여부와 DF/ 처리, 필요한 오류의 도달 여부가 결과를 바꾼다. 작은 ping은 되는데 파일 전송이 멎는다면 문제를 의심할 수 있으나 그것만으로 확정하지 않는다.
- MSS 조정은 데이터 크기를 제한하는 보조 방법이며 ·를 포함한 모든 트래픽의 해결책은 아니다.
크기 계산
기본 가정: 외부 IPv4 20 B + GRE 4 B, underlay IP MTU 1500 B
내부 IP 패킷 한도 = 1500 - 20 - 4 = 1476 B
내부 IPv4 20 B + TCP 20 B만 가정한 MSS = 1436 B옵션과 추가 보안 헤더가 없는 계산 예제다. 1400/1360 같은 자주 쓰는 실습 값을 모든 환경의 고정 정답으로 사용하지 않는다.
LEARN THROUGH PRACTICE
GRE 패킷의 두 IP 헤더로 터널 경로와 오버헤드 확인하기
로 보낸 ping을 캡처하여 외부 운반 주소와 내부 통신 주소를 분리하고 실제 길이 차이를 계산한다.
실습 구성과 전제
- 터널 양 끝의 외부 주소는 기존 IP망으로 서로 도달 가능해야 한다. 터널 목적지로 가는 경로가 터널 자체를 다시 선택하지 않도록 한다.
- 캡처는 Tunnel14의 내부 주소 사이 ping이다. 아래 설정은 구조를 재현하기 위한 문서용 주소 예시이며 캡처의 숫자와 동일한 실행 결과라고 주장하지 않는다.
외부 주소와 내부 주소를 따로 설정한다
- tunnel source와 destination은 원래 IP망으로 운반할 외부 끝점이다. Tunnel 인터페이스의 ip address는 내부 논리 링크 주소이므로 서로 역할이 다르다.
- 예시 R1의 외부 주소는 192.0.2.1, 상대 외부 주소는 198.51.100.2다. 상대 장비는 source·destination을 반대로 지정하고 내부 주소 10.10.14.2/30을 사용한다.
textinterface Tunnel14 ip address 10.10.14.1 255.255.255.252 tunnel source 192.0.2.1 tunnel destination 198.51.100.2 tunnel mode gre ip end show interfaces Tunnel14구조를 재구성한 R1 설정. 192.0.2.1은 실제로 설정된 로컬 인터페이스 주소이고 상대 외부 경로가 이미 존재한다는 조건이다.
확인 기준외부 주소 사이 도달 가능성을 먼저 확인한다. Tunnel up 표시만으로 상대 수신이나 내부 성공이 증명되지는 않는다.
내부 ping을 발생시키고 바깥 링크에서 관찰한다
- 상대 터널 주소로 ping하면 내부 패킷을 로 감싸 외부 끝점으로 운반한다. 캡처는 터널 내부가 아닌 운반 링크에서 해야 외부 IP와 를 함께 볼 수 있다.
- 화면의 외부 IP Protocol은 47, 내부 IP Protocol은 1이다. 바깥 주소와 안쪽 주소가 모두 보이므로 만으로 원래 통신 정보를 감추거나 암호화하지 않는다.
textping 10.10.14.2 source 10.10.14.1 show interfaces Tunnel14문서용 주소로 재구성한 내부 링크 ping. 표시 필터는 를 사용한다.
원본 크기로 보기 ↗- 외부 IPv4 Total Length는 124, Protocol은 Generic Routing Encapsulation (47)이다.
- GRE 아래 내부 IPv4 Total Length는 100이고 Protocol ICMP (1) 및 서로 다른 내부 주소쌍이 보인다.
확인 기준표시 필터 로 선택한 뒤 두 트리를 모두 펼쳐 주소와 Protocol을 비교한다.
보이는 바이트 차이로 캡슐화 비용을 계산한다
- 이 프레임의 외부 IP 길이 124에서 내부 IP 길이 100을 빼면 24바이트다. 헤더 20바이트와 옵션 없는 기본 헤더 4바이트가 더해진 경우와 일치한다.
- 내부 TTL은 255, 외부 TTL은 254로 보인다. 서로 다른 헤더의 TTL이므로 둘의 차이를 터널 안의 라우터 수로 환산하지 않는다.
확인 기준옵션·외부 IP 옵션·추가 이 있으면 오버헤드가 달라진다. 이 한 캡처의 24바이트를 모든 터널의 상수로 쓰지 않는다.
원격 LAN 트래픽은 터널 경로를 추가로 요구한다
- 터널 끝점 사이 ping이 되어도 상대 LAN에 대한 경로가 없으면 그 LAN으로 전달되지 않는다. LAN 경로가 내부 next hop을 가리키는지와 상대편 반환 경로를 확인한다.
- 를 넘는 큰 패킷 문제는 작은 ping 성공으로 배제되지 않는다. 인터페이스 와 DF· 관련 관찰을 별도로 남긴다.
textshow ip route 198.51.100.2 show ip route show interfaces Tunnel14실습 흐름을 재구성한 명령 예시. 장치·인터페이스 이름은 구성에 맞춰 사용한다.
확인 기준외부 끝점 경로와 원격 LAN 경로를 같은 것으로 취급하지 않는다. 외부 끝점이 터널 안으로 재귀 선택되면 구성부터 수정한다.
실습에서 확인한 동작 원리
- 캡처에서 두 IP 헤더를 구별하면 운반 경로와 내부 통신을 따로 설명할 수 있다.
- 보안 기능과 캡슐화 기능은 별개이며 실제 계산은 관측한 헤더 조건을 따른다.
설정·출력 추가로 확인하기 4장
아래 화면을 펼쳐 위 실습의 설정값, 명령과 확인 기준을 비교해 보세요. 각 묶음은 별도 실습 기록입니다.
실습 화면 묶음 01 1장
원본 크기로 보기 ↗- 문서 문맥에 삽입된 원본 실습·개념 참고 화면이다. GRE의 캡슐화·경로 의존성과 MTU 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.
실습 화면 묶음 02 2장
원본 크기로 보기 ↗- 「GRE 실습」 문맥에 삽입된 원본 실습·개념 참고 화면이다. GRE의 캡슐화·경로 의존성과 MTU 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.
원본 크기로 보기 ↗- 「GRE 실습」 문맥에 삽입된 원본 실습·개념 참고 화면이다. GRE의 캡슐화·경로 의존성과 MTU 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.
실습 화면 묶음 03 1장
원본 크기로 보기 ↗- 수업 원본 자료 · 터널 양 끝과 전달 경로의 구성 관계.
동작·명령 참고 문서
예제로 추적
08GRE 옵션에 따른 내부 MTU와 MSS 계산
- 가상 링크 조건바깥 =1500, 옵션 없음, ·추가 터널 없음인 계산용 예다. 기본 4바이트와 바깥 20바이트가 최소 추가 크기다.
- 기본 한계내부 IP 패킷 한계는 1500−20−4=1476바이트다. 옵션 없는 내부 ·라면 데이터 한계는 1476−20−20=1436바이트다.
- Key와 Sequence 추가Key 4바이트와 Sequence 4바이트를 모두 사용하면 는 12바이트다. 내부 는 1500−20−12=1468바이트로 줄어든다.
- 내부 IP 버전 비교내부 1468에서 옵션 없는 데이터는 1428바이트, 확장 헤더 없는 데이터는 1408바이트다. 기본 헤더가 기본 헤더보다 20바이트 크기 때문이다.
- 다른 오버헤드 반영 Checksum을 추가하면 다시 4바이트가 줄고 을 적용하면 해당 변환의 헤더·IV·패딩·인증값까지 계산해야 한다. 이 예의 MSS를 모든 VPN의 고정 정답으로 사용하지 않는다.
09IPv6 운반과 GRE over IPsec
- 운반외부망이 여도 안에 패킷을 실을 수 있다. 바깥 주소 계열, 페이로드 종류, 터널 인터페이스의 내부 주소 계열은 서로 다른 선택이다.
- 모든 -over-를 6to4라고 부르지 않는다.
- 6to4는 별도의 지정된 메커니즘이며 일반 터널과 구분한다.
- over over 은 로 감싼 트래픽을 이 보호하는 구성이다. WAN 종단 사이의 패킷을 선택하는 Crypto 은 바깥 source/destination과 protocol 47에 맞아야 한다.
- transport를 쓰는 경우 바깥 IP는 남고 헤더와 내부 패킷이 보호 범위에 들어가며, tunnel 모드는 새 외부 IP를 추가할 수 있다.
- 실제 협상 모드를 확인해야 한다.
10내부 경로 선택부터 GRE 수신까지
- 두 경로 조회show ip route 상대 WAN은 터널을 운반할 경로, show ip route 상대 내부 호스트는 터널을 사용할 경로다. 한 방향만 되면 반대편 경로와 내부 단말의 default gateway도 본다.
- 설정·의 차이No matching route to delete는 삭제 조건과 실제 설정의 불일치다. 다음 홉 형식과 출구 인터페이스 형식을 구분하며 설정된 경로가 유효한 다음 홉으로 에 채택됐는지도 확인한다.
- 내부 목적지의 원래 IP 목적지에 대한 경로가 Tunnel을 가리키면 해당 패킷을 터널로 보낸다.
- ·Outer IP 추가로 원래 패킷을 감싸고 outer 목적지를 상대 WAN 주소로 둔다. 기본 over 에서 바깥 IP Protocol은 47이다.
- Outer 목적지 상대 WAN까지의 별도 경로로 캡슐화한 패킷을 운반한다. Tunnel 설정과 실제 외부 도달성을 구분한다.
- 수신·디캡슐화상대가 outer IP·를 처리해 내부 패킷을 꺼낸다. 양끝 캡처의 내부 주소·TTL·크기를 대조하고 내부 목적지로 전달한다.
show interfaces Tunnel1
show running-config interface Tunnel1
show ip route 198.51.100.2
show ip route 10.20.0.10
show ip interface Tunnel1이 문서의 주소 예제 기준이다. 을 함께 쓰면 · SA와 양방향 암복호화 카운터도 추가로 확인한다.
설명과 함께 보는 보조 도식
구조 살펴보기
GRE over IPv4의 안팎 구조
옵션이 없는 기본 캡슐화 예제.
앞쪽 · 바깥 링크의 Ethernet 헤더는 이 IP 캡슐화와 별도다.
뒤쪽 · 옵션 없는 예의 추가 IP·GRE 오버헤드는 24 B다.
바깥 IPv4 20 B
터널 종단 사이를 전달한다. Protocol=47
GRE 기본 4 B
flags/version과 안쪽 Protocol Type
안쪽 IP 가변
원래 단말 통신 패킷. 자체 헤더와 데이터를 포함한다.
각 필드를 누르면 역할과 예시를 확인할 수 있습니다. 칸의 너비는 실제 바이트 비율과 다릅니다.
검증·예외
11터널 재귀와 MTU 문제의 서로 다른 흔적
- 목적지 경로 분리터널 내부 원격망은 Tunnel로, 바깥 터널 목적지는 물리 로 해석돼야 한다. 후자의 조회가 다시 같은 Tunnel을 가리키면 캡슐화에 필요한 출구를 자신에게 재귀적으로 의존한다.
- 가상 재귀 분기기존 WAN 기본 경로가 사라지고 새 기본 경로가 Tunnel로만 남으면 바깥 목적지도 그 기본 경로에 맞을 수 있다. 내부 경로가 늘어난 시점과 경로 변화를 함께 본다.
- 작은 패킷만 성공작은 내부 패킷은 통과하지만 큰 패킷에서 반복 재전송이 발생하면 추가 헤더와 DF· 조건을 조사한다. 터널 down과 구분되는 데이터 크기 의존 장애다.
- 바깥 프로토콜 필터 ping은 이고 데이터는 이다. 외부 IP에 ping이 된다는 이유만으로 도 방화벽을 통과한다고 결론내리지 않는다.
- 상태 표시의 제한순수 에는 식 연결 설정이 없으므로 인터페이스 up만으로 원격 디캡슐레이션 성공이 증명되지 않는다. keepalive 사용 여부·양방향 카운터·내부 응답을 함께 읽는다.
학습 확인
이해했는지 확인하기
- 47을 IP 프로토콜 번호로 구분했는가?
- 터널 목적지의 바깥쪽 주소로 가는 경로가 터널 자신을 향하지 않는가?
- 작은 패킷과 큰 패킷의 결과가 다를 때 MTU와 ICMP를 확인했는가?