Strongswan Structure/View (Strongswan의 구조도)

 

Strongswan의 구조도 여러 개에 대한 설명글입니다.

 

 

Static View

Strongswan은 크게 두 개의 Unix/Linux 데몬 "Charon" and "Pluto" 로 구성되어있습니다. 그것들은 IKE 프로토콜을 구현한 데몬들입니다. Charon은 IKEv2 프로토콜을 책임집니다, 반면에 Pluto는 IKE 프로토콜의 첫번째 버전을 구현했습니다. IKEv2를 구현하는 것이 목적이라면, Charon을 이용하는 것이 바람직합니다.

(참고: 2012년 6월 이후로, Pluto는 더이상 Strongswan5.0에 포함되지 않습니다. Charon이 IKEv2 그리고 IKEv2를 지원합니다.)

 

strongSwan의 메인 컴포넌트는 아래와 같습니다:

그림 6 : strongSwan의 중요한 컴포넌트들 (출처 : http://security.hsr.ch/mse/projects/2012_IPSECKEY_based_Authentication_using_DNSSEC.pdf)

Charon daemon의 대부분은 libcharon 그리고 libstrongswan 안에 구현됩니다.

 strongSwan은 libcharon으로 부터 VPN 엔드포인트들의 클래스들을 인증을 위해 사용됩니다. libcharon은 libstrongswan 그리고 libhydra의 클래스들을 사용합니다.

 libhydra는 daemon 구체적인 코드를 포함합니다.

 libstrongswan은 클래스들을 제공합니다. 그 클래스들은 암호화 알고리즘과 같은 strongSwan을 위한 기본적인 기능 그리고 libstrongswan에 의존하는 다른 strongSwan 컴포넌트들을 제공합니다.

 strongSwan 컴포넌트들은 interface들을 많이 사용하고, plug-in 메커니즘을 구현합니다. 이 interface들 그리고 plug-in 메커니즘은 strongSwan을 configurable 그리고 extendable (구성가능하고, 확장가능한)하게 만듭니다.

 

 

 

그림 8: Charon의 구조

 Charon의 디자인은 멀티스레드입니다. Charon은 쓰레드 풀을 사용합니다. (그림 8에 Processor라고 불리우는 것) Charon의 task들을 수행하기 위해서죠.

 이 데몬은 incoming(외부에서 들어오는 IKE message들을 "receiver"에 저장하고, 그것의 스레드들이 IKEv2 protocol에 따라, 그리고 그것들이 속한 SA에 따라, incoming IKE 메시지를 처리합니다. (그리고 answer들을 만듭니다)

 

 커널 인터페이스 위에서, Charon은 IPsec SAs를 설치합니다 OS 커널 안에서 말이죠. 커널은 IPsec SA 안에 묘사된 ESP/AH 프로토콜을 적용하는 책임이 있습니다, Charon들의 task는 IKEv2 프로토콜으로 제한됩니다.

 

 

 

 

Runtime View

그림 9: strongSwan의 런타임 구조 (Charon)

Processor의 역할

 Charon의 Processor는 Joqueue의 스레드들의 풀을 포함합니다. processor(처리기)는 Jobqueue로 부터 job하나를 픽해서 스레드에 job을 할당합니다. 스레드는 그러면, 그 job을 실행합니다 (그것이 기능을 실행합니다, 그 기능은 job안에 포함된것이죠) 그리고 Processor에게 알립니다, 그것이 job을 끝날 떄 말이죠.

 스레드가 그것의 job을 끝난 후에, 스레드는 기다립니다, Processor가 새로운 job을 할당할 때 까지 말이죠. 이 일을 하기 위해서, (그 일은 job으로 묘사되는), 스레드는 Strongswan의 다른 컴포넌트들 사용합니다, ike_sa_manager 처럼 말이죠.

 Processor의 Jobqueue는 Receiver 그리고 Scheduler에 의해서, 공급됩니다.

 

Receiver의 역할

 Receiver는 incoming IKE 메시지들을 위한 소켓을 listen하고 있습니다. 만약 그 Receiver라는 녀석이 소켓을 통해, IKE 메시지를 받으면, 그 녀석은 메시지를 위해서 "process_message_job"을 들고, job을 Processor의 Jobqueue에 추가합니다. 그리고나서  IKE 메시지가 Processor와 그것의 스레들을 통해서 처리됩니다. Receiver는 분리된 스레드를 가지고 있지 않습니다. 단지 "receiver"라는 job이 있습니다. 그것은 정기적으로 Processor에 의해 실행될 뿐이죠.

 

Scheduler의 역할

 Scheduler를 통해서, job들을 스케줄하는 것이 가능합니다, 미래에 실행하기 위해서 말이죠. 그 Scehduler는 내부적으로 힙을 가지고 있습니다, 거기안에서 그녀석은 스케줄된 job들을 저장합니다, 시간에 의해 정렬된채로 말이죠, 첨언하면, 그들이 실행되어야만 할 때 Scheduler는 job들을 저장합니다.

 Receiver와 마찬가지로, Scheduler는 "scheduler" job을 가지고 있습니다, 분리된 스레드 대신에 말이죠. (instead of a separate thread) 이 "scheduler" job은 정기적으로 실행됩니다, Processor에 의해서 말이죠 그리고 스케줄된 잡들을 추가합니다, 그것들은 실체로 실행되어야만 합니다, 어디로 추가되냐면 Processor의 Jobqueue로 추가됩니다.

 

Sender의 역할

 Job들은 새로운 IKE 메시지들을 만들 수 있습니다, Job들이 처리되는 동안에 말이죠. 그런 message를 보내기 위해선, job은 파라미터로써 message (packet)를 가진채, Sender의 "send" 함수를 불러야만 합니다. 그래야 메시지를 보낼 수 있습니다. Sender는 Sendqueue를 가지고 있습니다. 거기에서 그녀석은 outgoing(바깥으로 나가는) 메시지들을 buffer(일시적으로 저장) 합니다, 그녀석이 메시지들을 소켓을 통해 보낼 수 있을 때 까지 말이죠.

 그 자신 스레드 대신에, Sender 또한 특별한 "sendor" job을 사용합니다, 그의 work을 수행하기 위해 말이죠.

 

 Job은 다양한 task들로 구성될 수 있습니다. "job의 모든 task들"은 스레드에 의해 처리됩니다, 그 스레드에게로 job은 할당이 된채로 말이죠.