[Network/VPN] VPN, GRE tunneling, GRE over IPSec
1. VPN 이란?
VPN이란 Vertual Private Network의 약자로, 가상 사설 네트워크를 뜻합니다.
그림과 같이 사설망 A와 사설망 B가 있을 때 A에서 B로 데이터를 전송하고 싶다면 어떻게 연결할 수 있을까요?
간단하게 해결할 수 있는 방법은 둘 사이를 다이렉트로 연결하는 것입니다.
이렇게 둘을 다이렉트로 연결하면 물리적으로 선에 접근하지 않는 이상, 둘 사이에 오가는 데이터를 탈취하는 것은 불가능하겠죠. 이렇게 전용선을 사용하면 보안성이 좋다는 장점이 있습니다.
하지만 이 전용선은 망 일부를 독점하기 때문에 비싸다는 단점이 있습니다.
그렇다면 비싼 전용 회선을 사용하지 않고 사설망과 사설망을 안전하게 연결할 수 있는 방법은 어떤 것이 있을까요?
위 그림처럼 비싼 전용 회선 대신 공인망(internet)을 사용하고, 데이터를 암호화해서 안전을 보장한다면, 위 두 가지 문제가 해결되면서도 훨씬 저렴하게 사설망을 연결할 수 있습니다.
이러한 솔루션이 바로 VPN입니다.
VPN을 사용하면 두 사설망이 데이터 암호화/인증 방식을 협상하고, IP 패킷을 캡슐화 및 암호화하여 공인망을 사설망처럼 안전하게 사용할 수 있습니다.
2. GRE Tunneling Protocol
GRE Tunneling에 대해서 알아보기 전, 터널링(Tunneling)이라는 기술에 대해 먼저 알아보겠습니다.
2-1. Tunneling
위 그림과 같이 두 사설망이 있다고 가정하겠습니다. PC_A에서 PC_B로 “Welcome”이라는 데이터를 보내고 싶으면 어떤 방법을 사용할 수 있을까요?
떠올릴 수 있는 방법은 NAT일 것입니다. 하지만 B에 도착하는 경로까지 직접 NAT를 지정하는 일은 비효율적입니다. 이러한 문제를 해결하기 위해, 두 사설망을 연결해주는 기술인 터널링이 존재합니다.
PC_A에서 “Welcome!”을 보내면 우선 Router_A로 포워딩이 됩니다.
그러면 Router_A에서는 다음과 같이 패킷이 생성됩니다.
이후 인터넷 망에서 라우팅이 되게 위해서는 Router A와 B의 공인 ip주소를 사용해야 합니다. 하지만 현재 만들어진 패킷의 source와 destination ip 를 수정하면, 원래 목적지를 잃어버리게 되겠죠. 그래서 Router A 에서 L3로 한 번 더 감싸줍니다. 이 과정을 encapsulation 즉, 캡슐화 한다고 합니다.
캡슐화를 하고 나면, 위처럼 패킷 앞에 각 G/W Router의 공인 ip hdr가 붙게 됩니다. 이때 원래 있던 ip header를 Original ip hdr, 새로 추가된 부분을 tunnel ip hdr 라고 합니다.
public 망에서는 tunnel ip hdr를 가지고 Router B 까지 라우팅됩니다.
Router B는 해당 패킷의 tunnel ip hdr를 보고 목적지를 확인한 후, Decapsulation합니다.
이후 original ip hdr를 보고 원래 목적지인 PC B로 패킷을 포워딩 시킵니다.
이처럼 l3 패킷을 또 한 번 l3로 캡슐화해서 public network 에서도 패킷이 라우팅되도록 하는 기술이 터널링 입니다.
터널링 과정에서 Original Hdr와 Tnnel Hdr로 동작하는 부분을 나누어보면 다음과 같습니다.
Tunnel은 Original Header로 동작하는 두 point만을 생각하고, 터널 내부의 실제 장비는 신경 쓰지 않는 point to point 구조의 ovelay network 입니다. (Tunnel hdr로 동작하는 부분은 underlay Network로 터널 구성 시 신경쓰지 않습니다. /논리적으로 구분됨)
이러한 터널 기술의 장점은 다음과 같습니다.
- 캡슐화를 하기 때문에 사설망과 internet 환경 사이의 ip protocol이 다른 경우가 있어도, original ip hdr가 아닌, tunnel ip hdr(public ip)만으로 동작하기 때문에 문제 없이 전달된다.
- Underlay를 신경 쓰지 않아도 된다.
2-2. GRE Tunneling Protocol
GRE 터널은 위 터널링 과정에서 캡슐화 될 때, GRE hdr가 추가로 붙습니다.
추가된 GRE 헤더의 내용을 보면, 아래와 같습니다.
여기서 Protocol Type은 Original Packet의 ip protocol을 뜻합니다.
2-3. GRE Config (Cisco Packet Tracer)
GRE 터널을 실습할 환경은 다음과 같습니다. 빨간 박스는 GRE 터널 인터페이스 입니다. Internet 역할로 라우터 하나를 사용했고, A와 B 사설망의 G/W는 .100으로 두었습니다.
각 ip가 할당된 상태에서 진행하겠습니다.
(참고) 라우터에 Serial 선 연결이 안되는 경우
해당 라우터의 전원을 끄고 HWIC-2T 장착해주시면 됩니다.
만약 저 모듈이 없다면 NIM-2T 모듈 장착해주시면 됩니다.
(1) GRE 터널 설정
- A-Router config
interface tunnel l0
ip address 172.16.1.1 255.255.0.0
tunnel mode gre ip
mtu 1476
tunnel source Serial0/0/0
tunnel destination 20.0.0.10
- B-Router config
interface tunnel l0
ip address 172.16.1.2 255.255.0.0
tunnel mode gre ip
mtu 1476
tunnel source Serial0/0/0
tunnel destination 10.0.0.10
- interface tunnel [터널 번호 사용자 지정]
- 지정한 번호로 터널 인터페이스를 만드는 설정입니다.
- 예제에서는 10으로 만들었습니다.
- mtu 1476
- mtu 사이즈를 변경하는 설정입니다. 왜 설정하는 지에 대해서는 아래 (참고)를 확인해주세요.
- tunnel source [public ip 선이 연결된 port]
- 터널 인터페이스의 출발 ip 주소를 지정하는 설정입니다.
- 예제에서는 port(Serial 0/0/0)를 넣어줬는데 그냥 Public ip로 작성해도 설정이 됩니다:3
- tunnel destination [목적지 라우터의 Public ip 주소]
- 도착 라우터의 공인 ip를 지정합니다.
위와 같이 출발지/목적지 라우터에 터널 인터페이스가 생성되었다면, ping이 되어야 합니다.
(2) tracert 명령어로 제대로 설정되었는지 확인
GRE 설정이 안되었을 때는 위 그림과 같이 underlay에서 거쳐가는 라우터의 ip가 다 표시됩니다.
GRE 터널 설정을 한 후에는, 도착 라우터의 경로 정보가 모두 뜨지 않고, 터널로 연결된 라우터의 터널 인터페이스 ip 주소가 출력됩니다.
(참고) 터널 설정 시 mtu 1476 설정을 하는 이유
encapsulation되면서 GRE헤더(204byte)가 추가되기 때문에 1500-24를 해서 1476으로 조정해주는 것 입니다. MTU 사이즈를 조절해서 패킷 분편화를 방지하여 전송 속도를 보다 더 빠르게 하기 위해서 설정해주었습니다.
(참고) GRE 터널 동작 방식과 다중 인터페이스 설정
터널 인터페이스를 각각 설정하는데 터널이 어떻게 만들어지는 걸까? 라는 궁금증이 생겼다면 GRE 터널의 동작 방식을 살펴보면 됩니다.
B-Router에 패킷이 도착했을 때를 보겠습니다. 터널 헤더 부분의 출발지 ip 와 목적지 ip가 B-Router에 존재하는 터널 인터페이스의 목적지 ip와 출발지 ip랑 같으면 (패킷의 source ip == 터널의 destination ip & 패킷의 destination ip == 터널의 source ip) decapsulation 합니다.
라우터는 터널 인터페이스가 존재하면 받은 패킷을 무조건 터널 인터페이스로 토스합니다. 그렇기에 터널 인터페이스 생성 시 두 라우터의 Source와 Destination을 각각 크로스로 동일하게 설정해준다면, 한 라우터에 터널 인터페이스를 여러 개 생성해도, 지정된(의도하는) 터널로 데이터가 안전하게 이동합니다.
이처럼 여러 개의 터널 인터페이스를 지정할 수 있지만, 결국 Point to Point 연결이기 때문에 본사 한 곳에 지사 10개가 연결되어야 하는 구조라면 터널을 10개나 만들어야 하는 번거로움이 있습니다.
2-4. Dynamic Routing Protocol 동작 확인 실습
GRE는 Broadcast와 Multicast를 지원하기 때문에 터널 인터페이스 간 동적 라우팅 프로토콜이 가능합니다. 실습을 통해 확인해보겠습니다.
우선 동적 라우팅을 확인하기 위해 사설망 C를 추가하고 터널을 아키텍처와 같이 설정해주었습니다.
(1) 각 라우터에 OSPF 설정
- A-Router
router ospf 11
router-id 1.1.1.1
nerwork 192.168.10.0 0.0.0.255 area 0
network 172.16.0.0 0.0.255.255 area 0
- B-Router
router ospf 11
router-id 2.2.2.2
nerwork 192.168.20.0 0.0.0.255 area 0
network 172.16.0.0 0.0.255.255 area 0
network 172.17.0.0 0.0.255.255 area 0
- C-Router
router ospf 11
router-id 3.3.3.3
nerwork 192.168.30.0 0.0.0.255 area 0
network 172.17.0.0 0.0.255.255 area 0
(2) 터널 인터페이스로 라우팅이 되는지 확인
source에서 Destination으로 tracert를 해보자 터널 인터페이스를 통해 통신되는 것을 확인할 수 있습니다.
A라우터에서 show ip route ospf 11 명령어로 ospf 라우팅 테이블도 확인할 수 있습니다.
이제 A와 C 리전 사이에도 터널을 설정해보겠습니다.
(3) 터널 추가하고 동적 라우팅 되는지 확인하기
- A-Router
# Tunnel 설정
interface tunnel 20
ip address 172.15.1.2 255.255.0.0
tunnel source Serial0/0/0
tunnel destination 30.0.0.10
# ospf 설정
router ospf 11
network 172.15.0.0 0.0.255.255 area 0
- C-Router
# Tunnel 설정
interface tunnel 20
ip address 172.15.1.1 255.255.0.0
tunnel source Serial0/0/0
tunnel destination 10.0.0.10
# ospf 설정
router ospf 11
network 172.15.0.0 0.0.255.255 area 0
설정 후에 이전과 같이 region A에서 C로 패킷을 보내보면, 경로가 다음과 같이 바뀌는 것을 알 수 있습니다. 이를 통해 터널 인터페이스 간 OSPF의 이웃과 업데이트가 공유되고 있으며, 동적 라우팅이 되었다는 것을 알 수 있습니다.
마찬가지로 ospf 라우팅 테이블도 업데이트 된 모습입니다.
2-5. PDU 확인하기
Router A 에서 B로 패킷을 전송한 뒤 캡쳐한 사진입니다. A 라우터에서 위와 같은 패킷이 아웃바운드 되는 것을 시뮬레이션 기능으로 확인할 수 있습니다.
3. IPSec
IPSec 프로토콜은 암호화도 되고, 터널링도 되는 프로토콜입니다. 모드는 터널 모드와 전송 모드 두 가지가 있습니다. 전송 모드는 end-to-end 종단점 간 연결에서 사용됩니다. 그렇기에 라우터와 라우터 간의 통신에서 사용되며, Tunnel ip(Private ip)가 아닌, Original ip(Public ip) 하나만을 사용해서 통신하기 때문에 Tunnel ip hdr로 인한 오버헤드가 없다는 장점이 있습니다.
실습 환경
구성해볼 아키텍처는 다음과 같습니다. ip가 각각 설정되어 있다는 가정 하에 진행하겠습니다.
(참고) Static Routing
static으로 라우팅 경로를 먼저 지정해줍니다.
- A-Router
ip route 0.0.0.0 0.0.0.0 10.0.0.20
- B-Router
ip route 0.0.0.0 0.0.0.0 20.0.0.20
- Internet Router
ip route 192.168.10.0 255.255.255.0 10.0.0.10
ip route 192.168.20.0 255.255.255.0 20.0.0.10
IKE 1단계 터널 매개변수 정의
(1) 정책 우선 순위
Router(conf)# crypto isakmp policy [정책 식별 번호]
[정책 식별 번호]는 정책의 우선 순위 레벨을 정의하기 위해 사용하며, 고유해야 합니다.
1 ~ 10,000 사이의 숫자를 사용하며, 숫자가 높을수록 우선 순위가 높습니다.
- A, B-Router
crypto isakmp policy 1
(2) 암호화/해시/인증 알고리즘 지정
암호화를 어떤 방식을 사용할 지 지정해줍니다.
Router(config-isakmp)# encryption [암호화 알고리즘]
Router(config-isakmp)# hash [해시 알고리즘]
Router(config-isakmp)# authentication [인증 방식]
해시 알고리즘 - 공개키 정보를 주고받을 때, 제 3자에게 노출이 되지 않도록 하기 위해 해시 사용 (양쪽 동일한 해시 사용)
인증 방식 - 상대방이 보낸 메세지가 맞는지 확인
- A, B-Router
encryption 3des
hash sha
authentication pre-share
pre-share의 경우, 상대방이 미리 정한 암호를 알고 있는지 확인하는 방식(각 라우터에 같은 key설정 필요)
(3) Diffie-Hellman 그룹 지정
Router(config-isakmp)# group [DH 그룹 번호]
DH 그룹 번호에 따라 사용하는 암호의 크기가 다릅니다.
암호의 크기가 클 수록 보안성은 좋지만 계산 시간이 더 걸려서 성능이 떨어진다는 단점이 있습니다.
1그룹 - 768bit
2그룹 - 1,024bit
5그룹 - 1,536bit
- A, B-Router
group 2
(4) 보안 연계(SA) 수명 시간 지정
VPN 설정의 유효 기간을 정합니다.
Router(config-isakmp)# lifetime [VPN 지속시간(s)]
- A, B-Router
lifetime 86400
86400은 24시간으로 초 기준으로 작성해주면 됩니다.
(5) 인증 기법을 pre-share로 설정한 경우 (사전 공유 열쇠 인증)
Router(config)# crypto isakmp key [비밀번호] address [상대 IP 주소]
- A-Router
Router1(config)# crypto isakmp key CISCO address 20.0.0.10
- B-Router
Router1(config)# crypto isakmp key CISCO address 10.0.0.10
위 과정을 하면 A-Router와 B-Router 사이에 안전하게 정보를 교환 할 수 있는 채널이 형성됩니다.
IKE 2단계 터널 매개변수 정의
실제 데이터를 주고받을 때 어떻게 암호화를 할 지, 어떻게 인증할 것인지 정의합니다.
(1) 교환 집합 정의
Router(config)# crypto ipsec transform-set [정책 식별 이름] [IPsec 암호화 알고리즘] [인증 알고리즘]
- A, B-Router
Router1(config)# crypto ipsec transform-set ABTransform esp-3des esp-sha-hmac
(2) 보안 대상 트래픽 정의 (ACL 정의)
Router1(config)# access-list [acl 식별 번호] permit ip [source pn ip] [서브넷] [destination pn ip] [서브넷]
- A-Router
Router1(config)# access-list 101 permit ip 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255
- B-Router
Router1(config)# access-list 101 permit ip 192.168.20.0 0.0.0.255 192.168.10.0 0.0.0.255
(3) Crypto Map 작성
Router(config)# crypto map [정책 식별 이름] [정책 식별 번호] ipsec-isakmp
Router(config-crypto-map)# set peer [상대 IP 주소]
Router(config-crypto-map)# match address [접근 제어 목록]
Router(config-crypto-map)# set transform-set [IPsec 정책 이름]
- A-Router
Router(config)# crypto map ABCryptoMap 10 ipsec-isakmp
Router(config-crypto-map)# set peer 20.0.0.10
Router(config-crypto-map)# match address 101
Router(config-crypto-map)# set transform-set ABTransform
- B-Router
Router(config)# crypto map ABCryptoMap 10 ipsec-isakmp
Router(config-crypto-map)# set peer 10.0.0.10
Router(config-crypto-map)# match address 101
Router(config-crypto-map)# set transform-set ABTransform
(4) 인터페이스에 Crypto Map 적용
Router1(config)# interface [Public ip 연결된 인터페이스]
Router1(config-if)# crypto map [생성한 Crypto map 이름]
- A, B-Router
Router1(config)# interface Serial 0/0/0
Router1(config-if)# crypto map ABCryptoMap
위와 같이 설정하면 %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON 이렇게 활성화가 되었다고 뜹니다.
확인하기
(1) Packet
A에서 B로 ping을 보내고, A-Router에서 Outbound 되는 패킷을 살펴보면 ESP 헤더가 생기고, 사설 IP가 암호화 된 것을 볼 수 있습니다.
추가로, IPSec 설정된 라우터가 해당 프로토콜로 통신하는 것도 보입니다.
(2) Tracert
VPN 설정 전에는 위와 같이 4개의 경로를 통해 지나갔지만,
설정 후에는 이처럼 underlay동작은 나타나지 않고, Tunnel destination의 ip만 나타납니다.
(3) show crypto ipsec sa
show crypto ipsec sa 명령어를 통해 설정한 내용을 확인할 수 있습니다.
만약 패킷을 보내도 파란 부분의 정보가 갱신 되지 않는다면, show crypto isakmp sa 명령어로 제대로 설정이 되었는지 확인하면 됩니다.
4. GRE over IPSec
IPSec의 터널 모드를 통해 VPN을 구성할 수 있지만, 멀티캐스트/브로드캐스트를 지원하지 않는 문제가 있습니다. 이 때문에 라우터 간, OSPF나 EIGRP와 같은 Dynamic Routing Protocol (동적 라우팅 프로토콜)이 지원되지 않는다는 단점이 있습니다. (static으로 경로 설정을 해야함)
이 문제를 해결하기 위해 멀티캐스트/브로드캐스트가 지원되는 GRE 터널과 IPSec을 같이 사용한 것이 GRE over IPSec입니다.
GRE over IPSec을 사용하면, 터널 인터페이스의 동적 라우팅이 가능하게 됩니다.
질문 - IPSec over GRE 는 안되나요?
IPSec over GRE의 경우 GRE 헤더를 암호화하면서 발생하는 오버헤드가 사라진다는 장점이 있습니다.
GRE over IPSec 실습
IPSec 대상을 GRE 트래픽으로 지정하는 부분을 제외하고, 기본 IPSec 설정 방법과 동일합니다.
access-list 101 permit gre host 10.0.0.10 host 20.0.0.10
access-list 101 permit gre 192.168.10.0 0.0.0.255 host 20.0.0.10
- GRE over IPSec
- IPSec 헤더 + GRE 헤더 + 원본 IP 패킷
- Tunnel Mode(default)
- 전체 GRE 패킷이 IPSec 내에서 캡슐화, 암호화 됨
- 페이로드에 사용할 수 있는 여유 공간이 줄어듦 → IPSec 터널을 통해 데이터를 전송할 때 더 많이 잘려 보내짐
- Transform Mode
- 터널모드보다 패킷이 짧음
- end-to-end 연결에 사용 (Router to Router)
- IPSec over GRE
- GRE 헤더 + IPSec 헤더 + 원본 IP 패킷
- IPSec을 사용하여 캡슐화된 패킷이 GRE를 사용하여 캡슐화됨 → GRE 헤더 암호화에 따른 추가 오버헤드가 사라짐
- IPSec암호화가 터널 인터페이스에서 수행됨
- ACL과 일치하는 패킷은 터널을 통해 전송되기 전에 IPSec 패킷으로 캡슐화 된 다음 GRE 패킷으로 캡슐화 됨
- ACL과 일치하지 않으면 IPSec 캡슐화 없이 GRE 터널을 통해 직접 전송됨
즉, IPSec over GRE는 GRE 헤더 암호화를 하며 발생하는 오버헤드가 없지만, GRE 암호화가 되지 않습니다. 또한, 멀티캐스트(동적 라우팅 프로토콜)가 지원되지 않습니다.