이하, 본 발명의 일 실시예에 의한 본 발명의 다중 터널 VPN 게이트웨이를 이용한 데이터 전송 장치에 대하여 첨부된 도면을 참조하여 상세히 설명하면 다음과 같다.
도 1 은 다중 터널 VPN 게이트웨이를 이용한 데이터 전송 장치를 나타낸 블록도이고, 도 2 는 다중 터널 VPN 게이트웨이를 이용한 데이터 전송 장치에서 VPN 게이트웨이를 나타낸 블록도이며, 도 3 은 도 2 의 클라이언트측의 다중 터널 생성 모듈의 작동을 나타낸 순서도이다.
또한, 도 4 는 도 2 의 서버측의 다중 터널 생성 모듈의 작동을 나타낸 순서도이고, 도 5 는 도 2 의 다중 터널 적용 모듈의 초기화 과정을 나타낸 순서도이며, 도 6 은 도 2 의 다중 터널 적용 모듈의 회선 상태 및 보안 관계 변경에 따른 처리를 나타낸 순서도이다.
또한, 도 7 은 도 2 의 클라이언트 또는 서버측 다중 터널 적용 모듈에서 인터넷 회선으로 전송하는 패킷의 처리를 나타낸 순서도이고, 도 8 은 도 2 의 인터넷 회선에서 전송되는 패킷을 클라이언트 또는 서버측 다중 터널 적용 모듈에서 수신하여 처리하는 것을 나타낸 순서도이다.
이어서, 도 9 는 도 2 의 회선 상태 검사 모듈의 작동을 나타낸 순서도이고, 도 10 은 도 2 의 해쉬 테이블의 등록, 선택 방법에 따른 함수를 나타낸 예시도이다.
본 발명은 도 1 및 도 2 에 도시한 바와 같이, 클라이언트 통신수단(40), 클라이언트 VPN 게이트웨이(10b), 인터넷(90), 외부 로드 밸런서(20b), 서버 VPN 게이트웨이(10a) 및 내부 로드 밸런서(20b)로 구성되며, 상기 클라이언트 및 서버 VPN 게이트웨이(10b, 10a)는 키 관리 데몬(11), 회선 상태 검사 데몬(12), VPN 드라이버(13) 및 게이트웨이 설정 데몬(14)으로 이루어진다.
이어서, 상기 클라이언트 통신수단(40)에서는 사용자의 키 조작에 의해 전송하고자 하는 내용을 패킷 데이터로 전송하는 역할을 하고, 상기 클라이언트 VPN 게이트웨이(10b)에서는 상기 클라이언트 통신수단(40)으로부터 출력된 패킷 데이터를 입력받아 암호화한 후 부하가 걸려있지 않은 다중 터널 회선(93, 94, 95)을 선택하여 해당 회선을 통해 전송하는 역할을 한다.
또한, 상기 인터넷(90)에서는 상기 클라이언트 VPN 게이트웨이(10b)를 통해 출력된 암호화된 패킷 데이터를 다중 터널 회선(93, 94, 95)을 통해 입력받아 인터넷 회선(96)을 통해 전송하는 역할을 하고, 상기 외부 로드 밸런서(20b)에서는 상기 인터넷(90)으로부터 전송된 암호화된 패킷 데이터를 인터넷 회선을 통해 입력받아 부하 분산에 의해 부하가 걸려있지 않은 게이트웨이로 출력하는 역할을 한다.
또한, 상기 서버 VPN 게이트웨이(10a)에서는 상기 외부 로드 밸런서(20b)로부터 출력된 암호화된 패킷 데이터를 입력받아 복호화한 후 출력하는 역할을 하고, 상기 내부 로드 밸런서(20a)에서는 상기 서버 VPN 게이트웨이(10a)로부터 출력된 복호화된 데이터를 입력받아 해당 서버로 출력하는 역할을 한다.
한편, 상기 클라이언트 및 서버 VPN 게이트웨이(10b, 10a)의 키 관리데몬(11)에서는 다중 터널을 포함하여 VPN 터널을 생성하기 위해 상대방 VPN 게이트웨이와 암호화 키 협상을 수행하는 역할을 하고, 상기 회선 상태 검사 데몬(12)에서는 상기 다중 터널을 이용하여 회선에 대한 부하 분산 및 고 가용성을 수행하기 위해 각 회선의 상태를 검사하는 한편, 검사 상태를 다른 데몬 및 드라이버에게 알려주는 역할을 한다.
또한, 상기 VPN 드라이버(13)에서는 상기 키 관리 데몬(11)에 의해 생성된 암호화 키를 가지고 실제 VPN 통신을 수행하는 역할을 하고, 상기 게이트웨이 설정 데몬(14)에서는 일반적으로 사용자 인터페이스 기능을 포함하여 게이트웨이의 각 데몬 및 드라이버들의 작동을 제어하는 역할을 한다.
이하, 상기와 같이 구성된 다중 터널 VPN 게이트웨이를 이용한 데이터 전송 장치의 동작과정을 설명하면 다음과 같다.
우선 도 1에 나타난 각 장치들의 기능을 살펴보면, 클라이언트 및 서버 VPN 게이트웨이(10b, 10a)는 본 발명의 주체가 되는 VPN 장치이다. 상기 클라이언트 및 서버 VPN 게이트웨이(10b, 10a) 간에 다중 터널을 포함한 VPN 터널을 형성하게 되는 것인데, 서버 네트워크 쪽 VPN게이트웨이(10a)와 클라이언트 쪽 VPN 게이트웨이(10b)는 구조적으로는 차이가 없으나 네트워크 구성에서의 위치와 VPN 터널 생성을 위한 협상을 누가 시작하는가에 따라 작동이 약간 변화된다.
이어서, 상기 클라이언트 및 서버 VPN 게이트웨이(10b, 10a)의 구조는 도 2에 나타나며, VPN 게이트웨이의 작동은 VPN 터널 협상 시작 여부에 따라 달라지는 것을 포함하여 도 3에서 도 9까지 순서도로써 보여주고 있다.
한편, 도 1의 내부 로드 밸런서(20a)와 외부 로드 밸런서(20b)는 서버 쪽 네트워크에 연결된 VPN 게이트웨이(10a) 들이 회선 단위가 아닌 장치 단위로써 서로 부하 분산 및 고 가용성의 기능을 가질 수 있도록 선택적으로 적용된 장치이며 보통 L4(Layer 4) 스위치(Switch)를 이용한다.
또한, 상기 내부 및 외부 로드 밸런서(20a, 20b) 들이 없다면 서버 VPN 게이트웨이(10a)를 병렬로 두 대 이상 연결하기 위해서는 VPN 게이트웨이(10a) 자체에서 클러스터링(clustering) 기술을 이용한 상호 작용을 통해 부하 분산 및 고 가용성 기능을 달성해야 한다.
또한, 상기 각 내부 및 외부 로드 밸런서(20a, 20b)는 기본적으로 한쪽 네트워크 세그먼트에서 도달한 패킷을 분석하여 부하 분산을 달성할 수 있는 적절한 방법으로 분류한 뒤 해당하는 네트워크 세그먼트로 패킷을 전달하는 역할을 수행한다.
이어서, 도 1에 나타난 나머지 장치들(30, 40, 90)은 일반적인 클라이언트/서버 구조에서의 서버(30), 클라이언트 통신수단(40), 인터넷(90)을 가리키는 것으로 특별히 언급되어야 할 기능을 가지고 있는 것은 아니다.
각 장치들의 기능을 고려하여 도 1을 살펴보면, 본 발명은 일반적인 VPN 구성과 달리 클라이언트 네트워크 쪽의 VPN 게이트웨이(10b)에서 두 개 이상의 회선(93, 94, 95)을 이용하여 다중으로 VPN 터널을 형성하고 있음을 알 수 있는데,각 회선들에 대해 적절한 과정을 통해 다중으로 형성된 VPN 터널을 통하여 클라이언트 통신수단(40)과 서버(30)간의 암호화 통신이 이루어지게 된다.
즉, 클라이언트 통신수단(40)에서 출발한 패킷은 클라이언트 쪽 VPN 게이트웨이(10b)에서 암호화가 이루어진 후 적절한 회선 선택 과정을 통해 다중 터널 회선(93, 94, 95) 중의 하나로 선택되어 전송되며, 인터넷(90)을 거쳐 서버 네트워크 쪽 인터넷 회선(96)을 타고 외부 로드 밸런서(20b)에 전달된다.
이때, 외부 로드 밸런서(20b)는 자체의 부하 분산 정책에 따라 서버 쪽 VPN 게이트웨이(10a) 중의 하나로 패킷을 전달하고, 해당 VPN 게이트웨이(10a)는 보안 정책에 따라 해당 암호화 패킷을 복호화하여 내부 로드 밸런서(20a)를 통하여 서버(30)로 전달하게 된다.
한편, 상기와 언급한 기술적 내용과 반대로 서버(30)에서 출발해 클라이언트 통신수단(40)으로 향하는 패킷은 상기 내부 로드 밸런서(20a)에 도달하여 상기 내부 로드 밸런서(20a) 자체의 부하 분산 정책에 따라 서버 쪽 VPN 게이트웨이(10a) 중의 하나로 전달되고, 해당 서버 VPN 게이트웨이(10a)는 패킷을 암호화하고 적절한 회선 선택 과정을 통해 상대방 클라이언트 VPN 게이트웨이(10b)의 다중 터널(93, 94, 95) 중의 하나로 그 패킷을 전송한다.
이때, 상기 패킷은 외부 로드 밸런서(20b), 서버 네트워크 쪽 인터넷 회선(96), 인터넷(90)을 차례로 거친 후, 이미 선택된 한 다중 터널 회선(93, 94, 95)을 통해 클라이언트 쪽 VPN 게이트웨이(10b)에 도달하고, 상기 클라이언트 쪽 VPN 게이트웨이(10b)는 패킷을 복호화(해독)하여 내부 클라이언트 통신수단(40)으로 전송한다.
단, 도 1의 서버 쪽 네트워크에서 내/외부 로드 밸런서(20a, 20b)를 이용하여 부하 분산 및 고 가용성을 지원하는 것은 일반적인 VPN 네트워크에서도 나타날 수 있는 것으로, 다중 터널 VPN 시스템과는 직접적인 관계가 없다.
다만, 상기 내/외부 로드 밸런서(20a, 20b)의 구성 환경에서도 다중 터널을 정확하게 유지하기 위해서 유의해야 할 사항들이 있으므로 본 예시에 나타나게 된 것이며 그 내용은 뒤에서 알아볼 것이다.
또한, 대게 서버 네트워크 쪽에는 여러 클라이언트 네트워크의 요청에 대해 충분히 처리할 수 있게 하기 위해서 대역폭이 크고 안정적인 전용회선을 사용하는 것이 일반적이며, 클라이언트 네트워크 쪽에는 앞에서 밝힌 바와 같이 저렴한 회선을 사용하는 것이 일반적이기 때문에 도 1의 예시는 클라이언트 네트워크 쪽의 VPN 게이트웨이(10b)가 다중 회선(93, 94, 95)을 가지는 것으로 되어 있는 것일 뿐 반드시 클라이언트 쪽 VPN 게이트웨이(10b) 만이 다중 회선을 지원하는 것은 아님에 유의한다.
그러나, 이어지는 설명에서는 도 1을 기준으로 하고 있으므로 클라이언트 쪽 VPN 게이트웨이(10b)가 다중 회선(93, 94, 95)을 가지고 있는 것으로 간주한다.
이상으로 다중 터널 VPN 게이트웨이(10a, 10b)를 이용한 네트워크 구성에서 통신이 이루어지는 과정을 간략하게 살펴보았다. 이하에서는 도 1에서 나타난 것과 같이 구성되어 앞에서 설명한 바와 같은 작동을 보여주기 위해 개선된 VPN 게이트웨이(10a, 10b)의 구조를 상세히 알아보기로 한다.
다중 VPN 터널은 다중 회선을 가지고 있는 VPN 게이트웨이, 즉 도 1의 예시에서는 클라이언트 쪽 VPN 게이트웨이(10b)가 초기화 과정에서 각 다중 회선(93, 94, 95)을 이용해 상대방 서버 쪽 VPN 게이트웨이(10a)에 터널 생성을 요청함으로써 이루어진다. 양쪽 VPN 게이트웨이(10a, 10b)의 내부 구조를 도식화한 것이 도 2에 나타나 있는데, 도 2에서는 다중 터널 VPN을 가능하게 하기 위한 모듈들만을 중심으로 보여주고 있다.
도 2에서 나타난 데몬 및 드라이버들은 각각 키 관리 데몬(11), 회선 상태 검사 데몬(12), VPN 드라이버(13), 게이트웨이 설정 데몬(14)에 해당된다. 이 중 키 관리 데몬(11)은 다중 터널을 포함하여 VPN 터널을 생성하기 위해 상대방 VPN 게이트웨이와 암호화 키 협상을 수행하는 역할을 한다.
본 발명에서 제시하는 다중 터널 생성을 제외한 나머지 기능들은 대부분 표준 IKE 데몬의 기능에 준하며, 다중 터널의 생성도 표준 IKE의 절차 중에 섞여 있다. 이 내용에 대한 자세한 설명은 뒤에서 이어질 것이다.
한편, 상기 회선 상태 검사 데몬(12)은 다중 터널을 이용하여 회선에 대한 부하 분산 및 고 가용성을 달성하기 위해서 각 회선의 상태를 검사하고 다른 데몬 및 드라이버들에게 알리는 기능을 수행한다. 회선의 상태를 검사하기 위해서는 다양한 기법들을 사용할 수 있는데, 세부적인 검사 기법들은 본 발명에서 언급할 내용이 아니므로 소개하지 않고, 대신에 회선의 상태 변화가 감지되었을 때의 작동을 다중 터널 생성 및 유지와 관련하여 뒤에서 보다 자세히 알아볼 것이다.
이어서, VPN 드라이버(13)는 키 관리 데몬(11)에 의해 생성된 암호화 키를가지고 실제 VPN 통신을 수행하는 역할을 한다. 이 역시 표준 IPsec 드라이버의 기능에 준하지만, 다중 터널의 생성 및 적용에 관하여 부가적인 기능이 포함된 것이다. 역시 이 내용에 대한 자세한 설명은 뒤에서 알아본다.
또한, 상기 게이트웨이 설정 데몬(14)은 일반적인 사용자 인터페이스 기능을 포함하여 게이트웨이의 각 데몬 및 드라이버들의 작동을 제어할 수 있는 데몬을 의미한다. 이 게이트웨이 설정 데몬(14)의 구조나 작동 방법은 굳이 본 발명에서 언급하지 않아도 될 것이다.
한편, 상기 각 데몬 및 드라이버들의 구체적인 작동 과정을 살펴보자면, 우선 키 관리 데몬 (11)은 그 내부에 다중 터널 생성 모듈(111)을 포함하고 있다. 이 다중 터널 생성 모듈(111)은 VPN 게이트웨이(10a, 10b)의 초기화 과정에서 터널 생성을 요청하거나, 그러한 요청에 적절히 응답하는 기능을 수행한다. 다중 터널 생성 모듈(111)은 또한 도 2에 나타난 바와 같이 보안 정책(security policy)(112), 보안 관계(security association)(132), 회선 상태(134), 해쉬 테이블(hash table)(133) 등의 저장 정보를 이용하거나 기록하면서 작동하게 된다.
또한, 도 3은 도 2의 다중 터널 생성 모듈(111)의 작동 중에서, 다중 회선을 가지고 있는 VPN 게이트웨이(10b) 쪽의 터널 생성 과정을 간략히 나타낸 순서도이다. 도 3을 참조하면, 우선 보안 정책(112)을 확인하여 다중 터널로 설정된 모든 회선에 대해서 다음 두 단계(S111a2, S111a3)를 반복한다(S111a1). 상대방 게이트웨이(10a)와 IKE 통신 중 Phase1 키 협상을 통해 Phase2 키 협상을 보호할 수 있는 환경을 만든 후(S111a2), 실제 IPsec에서 사용될 암호화 키를 협상하는 Phase2 협상을 수행하여 보안 관계(132)를 형성함과 동시에 다중 터널 적용 모듈(131)에 의해 이미 생성된 해쉬 테이블(133)을 상대방 게이트웨이(10a)에 전송한다(S111a3). 단계(S111a2) 및 단계(S111a3)이 정확히 수행되면 단일 암호화 터널의 생성이 완료되며, 다중 터널로 설정된 회선 중 암호화 터널이 설정되지 않은 것이 아직 존재한다면 단계(S111a1)으로 돌아가 반복한다.
다중 터널 생성이 완료가 되면, 다중 터널 적용 모듈(131)이 이용할 수 있는 모든 다중 회선에 대한 보안 관계(132)가 수립이 된다. 그러나 회선 상태(134) 및 보안 관계(132)의 상태 변경에 따라 보안 관계(132)를 재협상 하거나 해쉬 테이블(133)을 재전송 하여야 하는 상황이 계속해서 발생할 수 있으므로, 그 이후의 단계(S111a4~S111a9)에서는 상태를 감시하고 있다가 필요에 따라 재협상 및 재전송을 수행한다. 이때, 단계(S111a6)에서 다중 터널 회선 중 활성 상태인 것에 대해 모두 반복하는 것은, 상대방 VPN 게이트웨이(10a)가 도 1에서 나타난 것과 같이 로드 밸런서(20)를 이용하여 부하 분산 및 고 가용성이 가능한 구성이 되었을 때도 각 상대방 VPN 게이트웨이(10a)가 해쉬 테이블을 정확하게 갱신할 수 있도록 하기 위한 것으로서, 필수적인 요소이다.
다음으로 도 4는 도 2의 다중 터널 생성 모듈(111)의 작동 중에서, 다중 회선을 가지고 있지 않은 VPN 게이트웨이(10a) 쪽, 즉, 다중 회선을 가지고 있는 VPN 게이트웨이(10b)에 의해 터널 생성 요청을 받게 되는 쪽의 터널 생성 과정을 간략히 나타낸 순서도이다. 전반적인 과정은 다중 회선을 가지고 있는 VPN 게이트웨이(10b)와 유사한데, 그것으로부터 요청을 받아 작동한다는 점에서 차이가있다. 도 4를 참조하면, 우선 상대방 VPN 게이트웨이(10b)로부터 IKE Phase1 요청이 오는 대로 모두 Phase1 및 Phase2 협상을 반복하여 수행한다(S111b1). 단계(S111b2)에서 Phase1 키 협상을 수행하는데, 이때 상대방 VPN 게이트웨이(10b)는 자신이 가지고 있는 다중 회선의 각 IP 주소를 이용하여 서버 쪽 VPN 게이트웨이(10a)에 Phase1 요청을 하게 되므로, 서버 쪽 VPN 게이트웨이(10a)의 다중 터널 생성 모듈(111b)의 입장에서는 각기 다른 클라이언트 쪽 VPN 게이트웨이(10b)가 터널 생성을 요청한 것과 동일하게 간주할 수도 있다. 그러나 Phase2 협상 시에 보안 관계(132)를 설정하는 한편, 해쉬 테이블(133)을 수신하여 저장하게 되므로(S111b3) 일반적인 과정과는 차이가 있고, 이렇게 수신된 해쉬 테이블(133)을 서버 쪽 VPN 게이트웨이(10a)의 다중 터널 적용 모듈(131)에서 이용하게 된다. 그리고, 도 1에서 나타난 것과 같이 로드 밸런서(20)를 이용하여 구성되는 경우에는, 다중 회선을 가진 VPN 게이트웨이(10b)의 각 회선에 대한 요청이 모두 하나의 서버 쪽 VPN게이트웨이(10a)에 전달되지 않고, 로드 밸런서(20b)에 의해 분산되는 경우도 있음에 유의한다.
다중 터널 생성이 완료가 되면, 역시 그 이후의 단계(S111b4~S111a9)에서는 상대방 게이트웨이의 변경 요청에 따라 보안 관계(132)를 재협상하거나 해쉬 테이블(133)을 수신하여 변경한다.
이와 같이 VPN 게이트웨이(10a, 10b)의 다중 터널 생성 모듈(111)의 작동에 대해서 알아보았다. 그런데, 다중 회선을 가진 쪽의 VPN 게이트웨이(10b)의 다중 터널 생성 모듈(111a)이 해쉬 테이블(133)을 전송하기 위해서는 적절한 해쉬 테이블(133)이 생성되어 있어야 하며, 그 일은 도 2의 VPN 드라이버(13)의 내부에 존재하는 다중 터널 적용 모듈(131)이 수행하게 된다. 다중 터널 적용 모듈(131)은 해쉬 테이블(133)의 생성 외에도 다중 터널 VPN 네트워크의 작동을 위해 여러 가지 일을 수행하게 되는데, 도 5에서 도 8이 그 수행하는 일들에 대한 순서도이다. 단, 다중 회선이 적용되지 않은 쪽의 VPN 게이트웨이(10a)의 경우에는 도 5, 도 6의 기능은 수행할 필요가 없고 그 기능을 수행한 상대방 VPN 게이트웨이(10b)에 의해 상태의 변경에 대응하게 됨에 유의한다.
도 5를 참조하면 VPN 드라이버(13)가 초기화될 때(S131a1) 보안 정책(112)을 검사하여(S131a2), 다중 터널이 존재한다면(S131a3) 소수(素數, prime number) 크기의 해쉬 테이블(133)을 생성하고(S131a4), 보안 정책(112)에 포함된 가중치 정보 및 회선 상태 정보를 이용하여 해쉬 테이블(133)의 항목들을 등록한다(S131a5). 도 10의 a)에서 이렇게 생성된 해쉬 테이블(133)의 예를 보여주고 있다. 예에서 해쉬 값은 회선의 선택 시에 사용되는데, 특정 패킷에 대해 도 10의 c)에서 나타난 것과 같은 회선의 선택 함수를 통해 얻어진 결과가 해쉬 값이며 그 해쉬 값에 해당하는 회선을 선택하게 된다. 도 10의 c)에서x,y는 각각 암호화될 패킷의 출발지 및 목적지 IP 주소를 가리키며,p는 해쉬 테이블(133)의 크기에 해당하는 소수 값이다. 즉, 해쉬 값(h(x,y))을 얻기 위해서는 패킷의 출발지 및 목적지 IP 주소를 합한 값을 해쉬 테이블(133)의 크기로 나눈 나머지를 취하면 된다는 의미이다. 여기서 해쉬 테이블(133)의 크기를 소수로 정하는 이유는, 다중 회선 VPN을 위해 사용하는 해쉬 테이블은 일반적인 해쉬 테이블과 달리 한 해쉬 값에 둘 이상의 항목이 들어갈 수 없기 때문이다.
한편, 도 10의 a)에서 나타난 회선 항목은 선택된 해쉬 값에 일대 일로 대응되는 실제 회선의 식별자가 되는데, 본 예에서는 도 1 의 구성과 같이 회선 번호(93, 94, 95)를 사용하였다.
또한, 상기 회선 식별자가 해쉬 테이블에 등록되는 빈도 수(frequency)는 각 회선에 대한 가중치 값(weight)에 따라 달라져야 하고, 가중치 값들의 합은 반드시 100으로 정해져 있다.
또한, 도 10 의 b)에서 나타난 함수가 해쉬 테이블(133)에서 회선 식별자가 가중치에 따라 나타나는 빈도 수를 표현한 것인데,i는 회선 식별자를 나타내고f(i)는 각 회선의 출현 빈도 수를 나타내며,w(i)는 각 회선의 가중치 값을 의미한다.
이어서,p는 도 10 의 c)의 경우와 같이 해쉬 테이블(133)의 크기를 나타내는 소수 값이고, 기호는 가우스(Gauss) 기호로서, 정수 근사 값을 취하기 위해서 사용되었으며, 도 10의 a)에 나타난 회선 가중치 및 해쉬 테이블(133)의 크기에 따른 빈도 수는 각각 회선(94)가 4, 회선(95)가 4, 회선(93)이 2가 된다. 그러나 해쉬 테이블(133)의 크기는 소수로 결정되나 가중치의 합은 100이므로 경우에 따라 해쉬 값에 따른 회선 항목이 존재하지 않을 수 있으므로, 이 경우 남은 해쉬 값에 대해서는 임의의 회선을 선택하여 등록한다. 해쉬 테이블(133)의 크기가 작을 경우 가중치 값에 완전히 부합되지 않을 수 있으나, 크기를 상대적으로 큰 소수로 지정할 경우 문제가 되지 않는다. 도 10의 예에서는 회선(93)이 가중치에 비해 한번 더 등록이 되었다.
다중 터널 적용 모듈(131)은 또한 회선 상태(134)의 변경에 따라 해쉬 테이블(133)의 회선 항목을 유지해야 한다. 도 6은 그러한 작동에 대한 순서도를 나타낸 것인데, 회선 상태(134)의 변경 사항을 감시하고 있다가(S131b1), 상태가 변경되었으면(S131b2), 보안 관계(132)를 변경하고(S131b5), 해쉬 테이블(133)을 갱신한다(S131b6). 또한 보안 관계(132) 자체의 변경 상황도 동시에 검사하고 있다가(S131b3), 변경 조건이 되면(S131b4), 보안 관계(132)를 변경하고(S131b5), 해쉬 테이블(133)을 갱신한다(S131b6). 특정 회선이 정상인 상태에서 사용할 수 없게 되면, 그 회선을 통해 설정된 VPN 터널을 보안 관계(132)에서 찾아 비활성 상태로 변경하여 해당 VPN 터널을 사용하지 못하도록 한 후, 해쉬 테이블(133)에 대해서는 그 회선이 해당되는 해쉬 값에 대해서는 나머지 회선들의 식별자로써 가중치에 따라 임의의 순서대로 등록하게 된다. 또, VPN 터널을 이루고 있는 보안 관계(132) 항목들의 경우 수명(lifetime)의 종료, 상대방의 요청 등에 의해 더 이상 사용하지 못하게 되는 경우가 있을 수 있으므로 이 경우에도 보안 관계(132) 및 해쉬 테이블(133)이 변경되어야 한다. 이렇게 변경된 보안 관계(132) 및 해쉬 테이블(133)이 앞에서 설명된 도 3에서 반영이 되는 것이다.
도 7과 도 8은 다중 터널 적용 모듈(131)에서 실제로 패킷이 전달되는 과정을 보여주는 순서도이다. 도 7은 내부의 서버 혹은 클라이언트 네트워크에서 인터넷(90) 쪽으로 나가는 아웃바운드(outbound) 패킷에 대한 처리 과정을 나타내고 있다. 다른 모듈에서 아웃바운드 패킷이 다중 터널 적용 모듈(131)로 전달되면(S131c1), 다중 터널 적용 모듈(131)은 우선 보안 관계(132)를 검사하고(S131c2), VPN이 적용되어야 할 패킷이 아니라면(S131c3) 다음 패킷 처리 모듈로 패킷을 그냥 전달한다(S131c7). 그렇지 않으면 해쉬 테이블(133)을 검사해(S131c4) 해쉬 테이블(133)에서 전송 회선을 선택하게 된다(S131c5). 이 때 전송 회선의 선택은 앞에서 설명한 바와 같이 도 10의 c)에 따라 이루어진다. 전송 회선이 선택되면 보안 관계(132) 정보를 이용해 나머지 VPN 처리를 수행하고(S131c6), 다음 패킷 처리 모듈로 패킷을 전달하는(S131c7) 과정을 수행한다. 여기서, 실제 패킷의 처리 과정에서는 해쉬 테이블(133)의 검사 외에는 특별한 작업이 수행되지 않아 패킷 전달 속도 등에 큰 영향을 미치지 않을 것임을 짐작할 수 있다.
도 8은 상대방 VPN 게이트웨이(10a, 10b)가 인터넷(90)을 통해서 보낸 인바운드(inbound) 패킷을 받아 내부의 서버 혹은 클라이언트 네트워크 쪽으로 전달하는 과정을 보여주는 순서도이다. 이전 패킷 처리 모듈에서 전달 받은 인바운드 패킷을(S131d1) 검사하여(S131d2), VPN 적용 패킷이 아니라면(S131d3) 다음 패킷 처리 모듈로 그냥 넘긴다(S131d5). VPN 적용 패킷일 경우에는 보안 관계(132)를 이용해 VPN 처리를 수행하여(S131d4) 다음 패킷 처리 모듈로 넘긴다(S131d5). 여기서, 인바운드 패킷의 처리 과정은 기존의 IPsec 처리와 동일하게 이루어진다. 즉, 본 발명에서 제시하는 다중 터널 VPN 게이트웨이(10a, 10b)를 이용하여 VPN 통신을 하게 될 경우, 패킷을 보내는 쪽에서만 해쉬 테이블(133)을 이용하여 출발 회선 혹은목표 회선을 선택하게끔 되어 있다.
마지막으로 도 9는 도 2에서 나타난 회선 상태 검사 데몬(12)의 회선 상태 검사 모듈(121)의 작동 과정을 나타낸 순서도이다. 다중 터널로 설정된 모든 회선에 대해 상태를 확인하여(S1211) 상태가 변경되었다면(S1212) VPN 드라이버(13) 내부에 있는 회선 상태(134) 정보를 갱신하는 작업을 반복하게 되며, 회선의 상태는 여러 가지 방법으로 확인이 가능하다.