4. 서버 측 공유기 포트포워딩 및 라우팅 설정

     (1) 서버 측 공유기 포트포워딩 설정

          우리가 사용하는 인터넷 공유기는 외부 네트워크와 내부 네트워크를 연결해 주고, 내부 네트워크를 보호해 주는 역할을 합니다. 외부 네트워크에서 봤을 때, 우리의 내부 네트워크는 기본적으로 하나의 (외부)IP와 (공유기의) MAC 주소를 가진 하나의 단말기 혹은 디바이스로 보입니다. VPN이라는 것이 기본적으로 외부에서 내부 네트워크로 마치 빨대를 꽂아 빨아 먹듯 사설 파이프를 연결하여 쓰는 것이므로 내부 네트워크 안에 있는 우리의 라즈베리파이 (혹은 오렌지파이) OpenVPN 서버와 지정된 포트(기본적으로 UDP 1194)로 막힘없이 통신할 수 있어야 합니다. 따라서 서버 측 공유기의 포트포워딩 설정을 통해 외부 OpenVPN 클라이언트와 내부 OpenVPN 서버가 통신할 수 있도록 설정해 줍시다. 

          우리 주변에 설치된 공유기들은 너무나 종류가 다양하고 펌웨어 또한 파편화 되어 있어, 모든 종류의 공유기에 대하여 설명한다는 것은 불가능 합니다. 여기서는 우리나라에서 가장 널리 쓰이는 ipTIME 제품을 예로 설명합니다. 포트포워딩과 다음에 기술할 라우팅 테이블 설정은 공유기의 기본 중 기본 기능이므로 용어와 메뉴 위치만 다를 뿐 다른 공유기에도 대동소이하게 존재하는 기능일 것으로 생각됩니다. 이 글을 참고하실 분들은 여러분의 공유기의 메뉴를 찬찬히 살피시어 그 동일한 기능을 제공하는지를 확인하시기 바랍니다.

          아울러, 이 설명은 제1부 "환경"부분에서 제시한 바와 같이 외부에서 우리 공유기를 찾아 들어올 수 있도록 외부 고정IP가 서비스되고 있거나, Dynamic DNS 서비스 (DDNS)가 이미 설정되어 있고, OpenVPN 서버가 내부 고정IP로 설정되어 있거나 공유기 단의 dhcp 서비스에서 예약/지정된 내부 유동IP를 할당받은 상태(우리의 예시는 192.168.0.2) 에서의 설명임을 다시 한번 상기시켜 드립니다.

          웹브라우져를 열고 주소창에 공유기의 내부네트워크 주소(일반적으로 192.168.0.1 이지만 공유기에 따라 혹은 본인 설정에 따라 아닐 수도 있습니다.)를 입력하고 엔터를 치면 공유기 관리화면 로그인 화면이 나옵니다. 로그인한 후 "관리도구"를 선택하여 들어갑니다. 브라우져 왼쪽 프레임에 메뉴탐색기에서 하단의 "고급설정-NAT/라우터관리-포트포워드 설정"을 차례로 클릭하고 들어갑니다. 그러면 오른쪽에 "포트포워드 설정"이라는 프레임이 열립니다.

          "정의된 리스트" 항목에는 "사용자 정의"를 선택하여 주시고, 그 왼쪽 "규칙이름"란에는 "OpenVPN"이라고 기재해 주세요. 그 아래쪽 "내부 IP 주소" 란에는 우리의 파이 OpenVPN 서버의 내부 주소인 192.168.0.2를 네 칸에 맞추어 입력해 줍니다. 프로토콜은 서버와 클라이언트 설정파일에서 선언해 준 대로 "UDP", 외부포트는 클라이언트 설정파일에서 선언해 준 대로 "1194", 내부포트도 서버 설정파일에서 선언해 준 대로 "1194"를 입력해 주고 아래 "추가" 버튼을 눌러 주면 설정이 완료됩니다. 아래 그림을 참조해 주세요.

ipTIME 공유기 포트포워드 설정 화면ipTIME 공유기 포트포워드 설정 화면입니다.

 

     (2) 공유기 라우팅 테이블 설정

          지난 회에서 설명할 기회가 없었지만, 우리는 서버와 클라이언트의 설정파일을 만드는 과정에서 "client-to-client"라는 옵션을 선언해 주었습니다. (서버 .conf 파일과 클라이언트들의 .ovpn 파일들을 한번 열어서 확인해 보세요.) 이것이 의미하는 바는 클라이언트가 OpenVPN에 접속하면 OpenVPN 서버 컴퓨터인 우리의 파이뿐만 아니라, 서버 측 내부 네트워크의 다른 내부 IP를 가진 장치들 (예를 들어 192.168.0.3의 주소를 가진 리눅스 서버 혹은 192.168.0.154의 주소를 가진 윈도우 PC 등등...)에 서버측 내부 네트워크 주소체계로 접근하여 통신하겠다는 의미입니다. 더 구체적으로 설명하자면, 우리의 예처럼, 외부 윈도우클라이언트에서 내부의 파이로 만든 OpenVPN 서버에 성공적으로 접속하여 10.8.0.0/24의 VPN네트워크가 형성되었다면, 외부 윈도우 클라이언트는 OpenVPN 서버인 파이에 ssh 접속을 10.8.0.1로도 할 수 있고, 192.168.0.2로도 할 수 있게 됩니다. 이뿐 아니라, 서버측 윈도우 PC에 원격데스크톱 접속을 하고 싶다면 (공유기 방화벽에 관계 없이 OpenVPN 서버의 도움으로) 내부 주소인 192.168.0.154로 원격 접속이 가능하다는 의미입니다.

          이것이 가능하기 위해서는 두 가지 조건이 필요한데, 첫째는 클라이언트측이 사설 IP 주소를 사용하여 접속한 경우, 서버 측과 클라이언트측의 내부 네트워크 주소가 동일한 세그먼트를 사용해서는 안된다는 것입니다. 즉, 만약 서버와 클라이언트 각 각 다른 내부 네트워크에 있지만, 모두 192.168.0.0/24 주소체계를 사용한다면, client-to-client 접속은 불가능합니다. 따라서 애초에 공유기 설정을 통해 서버 측 내부 네트워크를 10.XXX 로 시작하는 내부 주소로 전환하여 구성한 뒤에 OpenVPN 서버를 설치하는 것을 권장하기도 합니다. 대부분의 공유기들이 192.168.XXX 로 시작하는 내부 주소체계를 기본으로 채택하기 때문입니다.

          client-to-client를 가능하게 하는 두번째 조건이 바로 우리의 주제인 공유기 라우팅 테이블 설정입니다. 서버와 클라이언트가 아무리 설정을 통해 선언하여도 외부클라이언트가 10.8.0.0/24 네트워크를 통해서 192.168.0.X에 보내오는 데이터를 어디로 보내야 될 지 모르면 그 데이터는 갈 곳을 잃고 사라지고 맙니다. 그래서 '이 길로 가라'라고 지정해 주는 것이 라우팅이고 그것이 표로 정리된 것을 '라우팅 테이블'이라고 합니다. 이 과정을 통해 우리는 10.8.0.0/24 네트워크를 통해 나오는 데이터는 공유기인 192.168.0.1이 게이트웨이가 아니고 OpenVPN 서버인 192.168.0.2가 게이트웨이임을 선언해 줄 것입니다.

          다시 ipTIME 공유기로 가 보겠습니다. 왼쪽 메뉴탐색기에서 하단의 "고급설정-NAT/라우터관리-라우팅 테이블 관리"로 들어갑니다. 역시 오른쪽에 "라우팅 테이블 관리" 화면이 생깁니다. 맨 앞 "Type"엔 "Net"을 선택해 주시고, "Target"에는 10.8.0.0을 네 칸에 맞게 입력하여 주시고, "Mask"에는 숫자 "24"를 입력합니다. 마지막 "Gateway"에는 192.168.0.2를 역시 네 칸에 맞추어 입력해 주고 아래 "추가"를 누르면 설정이 완료됩니다. 아래 그림을 참조해 주세요.

ipTIME 공유기 라우팅 테이블 관리 화면ipTIME 공유기 라우팅 테이블 관리 화면입니다.

5. 문제 해결 (Troubleshooting and Workarounds)

     (1) 데비안 Jessie의 systemd 도입에 따른 이슈

          데비안은 Jessie 버전부터 init 시스템 대신 systemd를 전면 도입했습니다. 이것이 의미하는 바는 이전 Wheezy 버전까지는 시스템이 부팅되면 init 스크립트 체계에 설정해 놓은 선후관계에 따라 디먼(윈도우의 서비스)을 자동 실행하는 체제였다면, Jessie 버전부터는 총사령관 역할을 하는 systemd라고하는 디먼(서비스)가 먼저 실행되어 똬리를 틀고 앉아서 각 서비스의 의존관계에 따라 유연하게 순서를 정하여 각 서비스들을 자동 실행하는 것으로 바뀐 것입니다. 우리 같은 문외한이 보면 어차피 순서대로 실행만 잘 되면 별로 느낌이 안오는 변화인데, 운영체제를 깊이 파고들면 굉장히 큰 변화라고 합니다. 이게 그런데 아직 완벽하게 잘 정착이 되지는 않은 모습입니다. 제 리눅스 데스크탑도 데비안 jessie 기반의 우분투 16.04나 민트18에서 시스템 종료/재부팅 시 심한 딜레이에 빠져 systemd 관련 설정파일을 수정해야 했습니다. 데비안 OpenVPN 패키지도 마찬가지 인데요. 이 녀석은 기존에 init 시스템이 openvpn 디먼 서비스를 시작하면 OpenVPN이 .conf 파일을 불러들여 시작하는 형태였습니다. 그런데 systemd 체제는 OpenVPN이 하나의 서비스로 시작되고, 설정파일들이 종속적인 다른 각각의 서비스로 시작되어야 하는 구조로 되어 있습니다. 패키지 설치시에는 당연히 .conf 설정파일이 존재하지 않으므로, 설치 스크립트에 의해서 systemd 서비스가 enable 될래야 될 수 없는 구조인 것이죠. 따라서 Jessie 버전 이후부터는 서버의 .conf 파일을 만들어 주고 난 후 이것을 서비스로 enable 해 주는 절차가 수작업으로 필요하게 되었습니다. 마치 윈도우즈용을 설치하고 난 후 제어판 서비스에 가서 "자동" 실행으로 변경해 주어야 하는 것처럼 말이죠. Raspbian이든 Armbian이든 Jessie 이후 버젼이라면 이 절차를 따라야 합니다. 기본적으로 Debian 운영체제이거든요.

          다시 파이에 접속해 봅니다. 우리가 서버 측 설정파일의 이름을 server.conf라고 했지요. 재부팅 필요 없이 지금 server.conf 설정을 구동하고 싶다면 아래와 같이 입력합니다.

1
$ sudo systemctl start openvpn@server.service 
cs

          아래와 같은 명령도 동일한 결과를 가져옵니다.

1
$ sudo service openvpn@server start 
cs

          OpenVPN 설정파일을 부팅시 자동시작하도록 하고자 한다면 아래와 같이 입력해 줍니다.

1
$ sudo systemctl enable openvpn@server.service  
cs

          위 명령이 실제 하는 일은, openvpn 패키지로 설치된 "/lib/systemd/system/openvpn@.service"라는 파일에 연결되는 심볼릭 링크를 /etc/systemd/system/multi-user.target.wants/openvpn@server.service라는 링크 파일로 만들어 주는 것입니다.

          이제 재부팅하여 OpenVPN 서버 설정 서비스가 잘 시작되는 지 봅시다.

1
$ sudo reboot 
cs

 

     (2) .conf 설정파일의 서비스가 active되지 않는 경우

          재부팅이 완료되면 다시 파이에 접속하여 server.conf 서비스가 부팅 시 정상적으로 실행되었는 지를 확인합니다. 이를 위하여 아래의 명령을 이용합니다.

1
$ systemctl status openvpn@server.service 
cs

          그 결과 초록색 점과 "Active"항목의 결과값이 초록글씨의 active (running) 이라면 정상적으로 실행이 된 것입니다. 그러나 빨간색으로 표시되며 inactive 하다고 나오는 경우가 있습니다. 그 이유는 대부분 systemd가 실시간으로 의존성을 분석해 시작한 순서에 문제가 있어서 즉, 너무 빨리 실행되어 의존성을 만족시키지 못해 오류가 났을 가능성이 가장 큽니다. 이때의 대처방안은 서비스설정파일 (Unit 파일)을 수정하여 의존성 추가로 실행 순서를 늦추어 주는 것입니다.

          데비안 Jessie에 포함된 systemd 버전 상 Unit 파일을 수정해 주는 방법은 직접 해당 파일을 수정해 주는 것[각주:1]이므로 아래 명령으로 해당 파일을 에디터에 불러 들입니다.

1
$ sudo nano /lib/systemd/system/openvpn@.service 
cs

          열린 파일의 상단 쪽을 보시면,  [Unit] 섹션 아래 쪽 마지막에 "ReloadPropagatedFrom=openvpn.service" 이라고 하는 항목이 있습니다. 이 줄 맨 끝에 가서 엔터를 눌러 주어 한 줄을 더 만들어 줍니다. 새로 만들어 준 줄에 아래 내용을 복사하여 붙여 넣고 저장하고 닫습니다.

1
After=multi-user.target 
cs

          위 설정으로 server.conf 서비스의 부팅 시 실행 순서가 상당히 뒤로 갈 것입니다. 다시 한번 재부팅해 주고 서비스 실행 여부를 확인합니다.

 

     (3) 그래도 .conf 서비스가 active되지 않는 경우

          이론적으로는 사실 위의 설정만 제대로 해 주면 안될 이유는 없습니다. 다만, 그래도 server.conf 서비스가 부팅시에 active되지 않는다면 아래의 조치를 해 볼 필요가 있습니다.

          우선 서버 설정파일을 엽니다.

1
$ sudo nano /etc/openvpn/server.conf 
cs

          상단 "port 1194" 아래에 "local 192.168.0.2"라고 되어 있는 줄의 맨 앞에 "#"을 붙여 주어 그 줄 전체를 주석 처리하고 저장 후 닫습니다.

          한 해외 커뮤니티에 따르면, 원인을 알 수 없는 설정파일 서비스의 inactive 상황의 경우, 위와 같이 서버 설정파일에서 서버의 내부 IP 주소를 명시적을 선언해 주는 위 설정을 없애 주면 (주석처리해 주면) 정상적으로 작동한다는 경험자의 성공담이 있었습니다. inactive의 원인도 해결책의 원리도 밝혀진 것은 없지만, 서버가 내부 ip 주소체계를 확정하기 전에 설정파일 서비스가 시작될 경우 "local 192.168.0.2"라는 설정이 실행에 오류를 내기 때문으로 추정해 볼 수 있습니다.

          아무튼, 명시적인 서버 내부 주소의 선언이 없이도 OpenVPN 네트워크가 잘 돌아가므로, 다소 군더더기에 가까운 이 "local XXX.XXX.XXX.XX"라는 설정은 없애는 것이 오류를 줄이는 것임은 확실한 듯 합니다.

 

이상으로 Raspberry Pi를 OpenVPN 서버로 만들기의 3부작 모든 연재를 마칩니다. 부족한 지식으로 장황하게 쓴 글이지만, client-to-client 방식 접속을 위해 국내에  널리 쓰이는 공유기 관련된 OpenVPN 설정 문서가 부족하고 최신 Jessie 버전에 맞는 설정 방법에 대한 안내문도 부족한 현실에서 나름의 의의를 가지는 문서가 되기를 희망해 봅니다. 이 글을 참조해서 OpenVPN을 성공적으로 도입하시는 분들이 한 분이라도 생긴다면 감사하고 보람된 일이 될 것 같습니다.

          길고 어지러운 글 끝까지 읽어 주셔셔 감사합니다.

 

 

  1. systemd 218 버젼부터는 sudo systemctl edit openvpn@.service 라는 명령이 가능해 졌습니다. /lib/systemd/system/ 폴더에 있는 파일은 직접 수정하면 업데이트시 수정본이 사라지므로 간접 편집방식을 지원하게 된 것입니다. 자세한 사항은 systemd 관련 문서를 참조하세요. [본문으로]
Posted by truerain
l

3. 설정 (B) - 설정파일 생성

 

     (1) 서버 측 설정파일 (.conf) 만들기

1
# nano /etc/openvpn/server.conf 
cs

          위 명령을 실행하여 빈 파일 server.conf 파일을 편집합니다.

          아래 텍스트를 전체 선택하여 복사 후 위 server.conf 파일에 붙여넣기 한 후 파일을 저장하고 나옵니다.

1
#################################################
#                                               #
#     My Server OpenVPN Server Configuration    #
#                                               #
#################################################
 
port 1194
local 192.168.0.2
proto udp
dev tun
 
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key  # This file should be kept secret
dh /etc/openvpn/easy-rsa/keys/dh2048.pem
 
server 10.8.0.0 255.255.255.0
 
ifconfig-pool-persist ipp.txt
 
push "route 10.8.0.1 255.255.255.255"                # Add route to Client routing table for the OpenVPN Server
push "route 10.8.0.0 255.255.255.0"                  # Add route to Client routing table for the OpenVPN Subnet
 
push "route 192.168.0.2 255.255.255.0"               # local subnet
 
push "dhcp-option DNS 8.8.8.8"                       # Set primary domain name server address to th Google DNS
push "dhcp-option DNS 8.8.4.4"                       # Set primary domain name server address to th Google DNS
 
push "redirect-gateway def1"                         # Override the Client default gateway by using 0.0.0.0/1 and
           # 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of
           # overriding but not wiping out the original default gateway.
 
 
client-to-client
 
keepalive 10 120
 
tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0
cipher AES-128-CBC
comp-lzo
 
user nobody
group nogroup
 
persist-key
persist-tun
 
status /var/log/openvpn-status.log 20
log /var/log/openvpn.log
 
verb 3
 
crl-verify crl.pem 
cs

         보안 강화를 위해 아래와 같이 server.conf 파일의 권한을 변경해 줍니다.

1
# chmod 640 /etc/openvpn/server.conf 
cs

 

     (2) 서버 측 인터넷 데이터 포워딩 설정

         서버 측인 Raspbian (혹은 Armbian) 운영체제는 기본적으로 설정된 네트워크 간에 데이터 포워딩을 허용하지 않습니다.  server.conf 파일에 의해서 새롭게 구성되는 10.8.0.0/4 네트워크가 인터넷 통신을 하기 위해서는 이 설정을 변경하여 가능하도록 해 줍니다.

1
# nano /etc/sysctl.conf 
cs

         파일 내용이 꽤 긴데, 아래로 쭉 내리시면 중간 쯤에 “Uncomment the next line to enable packet forwarding for IPv4.” 라는 문구가 보이실 겁니다. 그 바로 아랫 줄의 # 표시를 제거하여 설정이 enable 되도록 변경해 주고 저장 후 nano에서 나옵니다. (아래 그림을 참조하시기 바랍니다. 중간 쯤에 제가 하이라이트 해 놓은 부분입니다.)

 /etc/sysctl.conf 파일/etc/sysctl.conf 파일을 nano 에디터로 열고 중간 정도 까지 스크롤 다운 한 화면입니다.

 

          이제 라즈베리파이 시스템에 우리가 설정을 변경하였다는 것을 알려 주기 위해 다음 명령을 입력합니다.

1
# sysctl -p 
cs

          위 명령을 통해 라즈베리파이 시스템은 재부팅 없이도 (at runtime) sysctl.conf 파일의 최신 변경사항을 반영할 것입니다.

          이제 리눅스 방화벽 차원의 인터넷 데이터의 포트포워딩을 설정해 주어야 합니다. 이 과정은 아래의 간단한 쉘스크립트를 통하여 가능합니다. 아래의 명령으로 새로운 빈 스크립트 파일을 엽니다.

1
# nano /etc/firewall-openvpn-rules.sh  
cs

          새로 열린 파일에 아래의 내용 전체를 복사하여 붙여 넣고 저장하면서 나옵니다.

1
#!/bin/sh
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j SNAT --to-source 192.168.0.2 
cs

          보안상 중요한 파일이며 실행권한이 필요하므로 아래와 같이 입력해 줍니다.

1
# chmod 700 /etc/firewall-openvpn-rules.sh 
cs

          위에서 만들어준 OpenVPN을 위한 방화벽 예외 사항이 부팅 시(혹은 이더넷이 켜질 때)에 자동으로 실행될 수 있도록 아래와 같이 해 줍니다. 

1
# nano /etc/network/interfaces 
cs

          이 파일이 열리면 내용 중에서 "iface eth0 inet dhcp"라고 나오는 부분을 찾습니다. 우리가 이전에 이 파일을 열어서 고정IP로 변경하는 설정을 해 주지 않았다면 위의 내용이 보일 겁니다. 이 줄의 맨 끝에서 Enter키를 눌러 주어 한 줄을 추가한 다음 Tab키를 두 번 누르고 그 자리에 아래 내용을 복사하여 붙여 넣기를 해 주고 저장하며 종료합니다.

1
pre-up /etc/firewall-openvpn-rules.sh 
cs

          자 이제 서버 측에서 설정하고 구성하여야 할 것들은 거의 끝났습니다. 서버 측에서 남은 것은 이제 실제로 운용해 보면서 나오는 이슈들을 해결하기 위해 설정을 튜닝하는 것뿐입니다. 서버를 이제 재부팅합시다.

1
# shutdown -r now 
cs

 

     (3) 클라이언트 측 설정파일 (.ovpn) 만들기

          ssh를 통해 서버에 원격접속해 있었다면 1분 정도 여유있게 기지개를 좀 펴고 스트레칭 좀 하면서 파이가 재부팅할 시간을 준 뒤 재접속합니다. 그리고 루트 환경으로 진입한 후 우리가 작업하던 easy_rsa 폴더로 다시 가 봅시다.

1
2
$ sudo -s
# cd /etc/openvpn/easy-rsa/
cs

          클라이언트 측에는 사실 여러 가지 파일을 많이 가지고 있어야 합니다. 설정파일인 .ovpn (혹은 .conf) 파일, CA 파일, 키 파일, 클라이언트 인증서 등등... 이 파일들을 윈도우, 리눅스, 맥 클라이언트 들같은 데스크탑/랩탑에 복사하고 관리하는 것이야 뭐 큰 문제 없다고 할 수도 있지만, 요즘과 같은 모바일 세상에서 안드로이드나 iOS 클라이언트까지 저 잡다한 파일들을 죄다 옮겨서 유지 관리하기 보다는 좀 더 간편한 파일관리를 원하게 됩니다.

          그래서 Eric Jodoin 이라는 분이 배시 쉘 스크립트를 개발해서, 우리가 지난 1부에서 클라이언트를 위해 만들었던 잡다한 파일들을 설정파일 하나에 모두 집어 넣어, 설정파일 하나만 클라이언트 디바이스에 넣고 OpenVPN을 돌리면 서버에 문제 없이 접속되도록 해 놓으셨습니다. 설정파일을 비롯해 네다섯 개의 파일을 클라이언트에 넣으려고 scp 명령을 여러번 써 가며 고생했는데 신세계를 열어 주셨네요. 어떤 분인지 잘 모르지만 감사의 말씀을 전합니다.

          아무튼 이 스크립트를 쓰기 위해서 우리는 클라이언트 설정파일의 기본적인 내용을 담고 있고 CA, 인증서, ta.key 등의 내용이 합쳐질 기본 템플릿 파일 노릇을 할 txt 파일 하나를 만들어 놔야 합니다. 지금까지와 마찬가지로 복붙신공으로 순식간에 만들어 보겠습니다.

1
# nano /etc/openvpn/easy-rsa/keys/Default_Client_Template.txt 
cs

          역시 마찬가지로 새로 열린 파일에 아래의 내용 전체를 복사하여 붙여 넣습니다.

1
client
dev tun
proto udp
remote my_network.iptime.org 1194
resolv-retry infinite
nobind
persist-key
persist-tun
mute-replay-warnings
ns-cert-type server
key-direction 1
cipher AES-128-CBC
comp-lzo
verb 3
mute 20 
cs

          자, 우리는 지난 제1부의 처음 도입부에서 네트워크 시스템의 환경부분을 언급하며, DDNS가 설정되어 있고 그 이름이 my_network.iptime.org 인 것으로 가정한다고 했습니다. 기업의 경우에는 외부 고정IP를 보유하고 계신 곳도 많으니, 만약 고정IP를 사용하신다면 그 고정IP를 my_network.iptime.org 자리에 입력하시면 됩니다. KT, SKB, LG U+ 등 통신회사가 제공하는 서비스가 유동IP 서비스라면 반드시 DDNS 서비스를 등록하시고 URL을 부여 받으신 뒤 그 주소를 my_network.iptime.org 자리에 입력하셔야 제대로 동작합니다. 이 글의 주제에서 벗어난 이슈이기 때문에 자세한 언급은 생략하지만, DDNS 서비스는 무료 제공이 대세입니다. 우리의 파이가 클라이언트 역할을 할 수도 있으며, ipTIME 공유기의 경우 공유기 차원에서 등록하고 유지 관리 및 클라이언트 역할을 할 수 있어 편리한 점이 있습니다. 

          Control+X 키를 누른 후 저장하겠냐는 물음에 Y하고 파일을 빠져 나옵니다.

          이제, 언급해 드린 배시 쉘 스크립트 파일을 만들 차례입니다.

1
# nano /etc/openvpn/easy-rsa/keys/MakeOVPN.sh 
cs

          새로 열린 파일에 아래의 내용 전체를 복사하여 붙여 넣고 저장하면서 나옵니다.

1
#!/bin/bash
# Default Variable Declarations
DEFAULT="Default_Client_Template.txt"
FILEEXT=".ovpn"
CRT=".crt"
KEY=".key"
CA="ca.crt"
TA="ta.key"
#Ask for a Client name
echo "Please enter an existing Client Name:"
read NAME

#1st Verify that client’s Public Key Exists
if [ ! -f $NAME$CRT ]; then
 echo "[ERROR]: Client Public Key Certificate not found: $NAME$CRT"
 exit
fi
echo "Client’s cert found: $NAME$CR"

#Then, verify that there is a private key for that client
if [ ! -f $NAME$KEY ]; then
 echo "[ERROR]: Client 3des Private Key not found: $NAME$KEY"
 exit
fi
echo "Client’s Private Key found: $NAME$KEY"
#Confirm the CA public key exists
if [ ! -f $CA ]; then
 echo "[ERROR]: CA Public Key not found: $CA"
 exit
fi
echo "CA public Key found: $CA"
#Confirm the tls-auth ta key file exists
if [ ! -f $TA ]; then
 echo "[ERROR]: tls-auth Key not found: $TA"
 exit
fi
echo "tls-auth Private Key found: $TA"
#Ready to make a new .opvn file - Start by populating with the default file
cat $DEFAULT > $NAME$FILEEXT
#Now, append the CA Public Cert
echo "<ca>" >> $NAME$FILEEXT
cat $CA >> $NAME$FILEEXT
echo "</ca>" >> $NAME$FILEEXT
#Next append the client Public Cert
echo "<cert>" >> $NAME$FILEEXT
cat $NAME$CRT | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' >> $NAME$FILEEXT
echo "</cert>" >> $NAME$FILEEXT
#Then, append the client Private Key
echo "<key>" >> $NAME$FILEEXT
cat $NAME$KEY >> $NAME$FILEEXT
echo "</key>" >> $NAME$FILEEXT
#Finally, append the TA Private Key
echo "<tls-auth>" >> $NAME$FILEEXT
cat $TA >> $NAME$FILEEXT
echo "</tls-auth>" >> $NAME$FILEEXT
chmod 600 $NAME$FILEEXT
echo "Done! $NAME$FILEEXT Successfully Created."
#Script written by Eric Jodoin 
cs

 

           이제 키 파일들이 위치한 디렉토리에서 작업하기 위해 폴더를 변경합니다.

1
# cd /etc/openvpn/easy-rsa/keys/ 
cs

          아울러 이 파일은 실행을 전제로 하는 쉘 스크립트이므로 실행권한을 주도록 변경합니다.

1
# chmod 700 ./MakeOVPN.sh 
cs

          자, 이제 드디어 쉘 스트립트를 실행해 봅시다.

1
# ./MakeOVPN.sh 
cs

          이 스크립트가 실행 되면서, 클라이언트의 이름을 입력하라고 합니다. 우리는 지난 제1부에서 Client1이라는 이름의 클라이언트를 생성해 준 바 있습니다. 이걸 넣어 보죠.

1
Done! Client1.ovpn Successfully Created. 
cs

          우리가 클라이언트의 이름을 오타없이 잘 입력했다면 위와 같은 메세지를 남기며 스크립트가 종료됩니다. 만약 다른 클라이언트를 더 만들었다면, 위의 스크립트를 반복 실행하면서 다른 클라이언트들의 .ovpn파일들을 모두 만들어 줍니다.

 

     (4) 클라이언트 측 소프트웨어 설치 및 구성

          우리는 지금까지 서버 측에서 모든 작업을 해 왔습니다. 이제 클라이언트 소프트웨어를 설치하고, 서버에서 만들어 놓은 .ovpn 파일을 클라이언트에 옮겨 놓고 실행하는 것이 남았네요. 클라이언트는 정말 다양한 환경에서 구동되기 때문에 이 글에서 모두 설명할 수는 없을 것 같습니다. 다만, 윈도우, 리눅스, 안드로이드, iOS 등 대부분의 운영체제에 OpenVPN 소프트웨어가 설치되고 클라이언트로 동작할 수 있는데 반해, MacOS에는 서드파티 소프트웨어만 존재하는 것으로 알고 있습니다. 그 중 쓸만한 것 하나가 Tunnelblick이라는 건데, 우리가 만들어 준 .ovpn 파일도 잘 인식하고 작동합니다.

          서버에 만들어 놓은 클라이언트용 .ovpn 설정 파일을 옮기는 과정도 파이에 랜만 물려 놓고 ssh로 원격접속해 쓰시는 분들은 참 난감하실 수 있습니다. 리눅스에 익숙하신 분들이야 scp로 파일을 순식간에 받으시겠지만 윈도우 쓰시는 분들은 Winscp를 설치하여 파일을 받으셔야 합니다. 파이에 sftp나 ftp 서버를 설치하고 윈도우 등에서 filezilla 등의 ftp/sftp 클라이언트로 .ovpn 파일을 받아오는 방법도 있습니다. 만만치 않은 작업들입니다만, 이글의 작성 목적을 벗어나므로 더 이상의 언급은 생략합니다.

          여기서는 우리나라 PC환경의 대부분을 차지하는 윈도우 클라이언트 설치 및 설정 과정만을 살펴 보겠습니다.

          우선 OpenVPN의 공식사이트 커뮤니티 다운로드 페이지에서 CPU와 윈도우즈 아키텍처에 맞는 32bit x86용 혹은 64bit x86_64용 윈도우즈 인스톨러 파일을 다운로드 받습니다. 특별한 커스터마이징 없이 설치과정을 마치면 "C:\Program Files\OpenVPN"폴더에 프로그램이 설치되고 바탕화면에 바로가기 아이콘이 생성됩니다. 이 설치 폴더 하위 폴더에 "config"라는 폴더도 설치되는데 이 곳에 우리가 서버에서 만들어 준 .ovpn 파일을 넣어 줍니다.

          이제 우리 Windows 클라이언트에서 수동으로 OpenVPN 서버에 접속하기 위해 바탕화면의 OpenVPN GUI 아이콘을 클릭합니다. OpenVPN GUI가 실행되면 시스템 트레이에 자물쇠가 있는 회색 모니터 모양의 트레이 아이콘이 나타납니다. 이 트레이 아이콘에 대고 오른쪽 클릭을 하면 아래 그림과 같은 메뉴가 나오게 되는데 여기서 "Connect"에 대고 클릭을 해 주게 되면 새로운 텍스트 창이 하나 열리면서 우리가 "config"폴더에 넣어 준 .ovpn 설정의 내용에 따라 서버에 접속을 시도하게 됩니다. 

OpenVPN GUI 실행 모습윈도우즈 용 OpenVPN GUI가 실행되어 시스템 트레이에 관련 아이콘이 나타나고 이를 오른쪽 클릭했을 때의 화면입니다.

          이때 접속에 성공하면 접속 프로세스를 보여주는 창이 자동으로 닫히면서 시스템 트레이 아이콘의 모니터 색이 회색에서 연두색으로 바뀌게 되고, 실패하면 접속 진행 창에 에러메세지를 보여 주게 됩니다.

          윈도우용 OpenVPN 프로그램은 GUI 수동접속 지원과 함께 윈도우즈 서비스에도 등록되어 부팅시 자동실행 시키거나 런타임으로 재시작할 수 있도록 되어 있습니다. 다만, 처음 설치하면 이 기능의 기본값은 수동시작으로 되어 있으므로 서버로 실행하거나 클라이언트를 부팅시부터 자동으로 시작하고 싶다면 이를 자동시작으로 바꾸어 줄 필요가 있습니다.

          윈도우즈 바탕화면 왼쪽 하단의 윈도우즈 로고를 오른쪽 클릭하면 나오는 제어판을 실행해 줍니다. 제어판-시스템 및 보안-관리도구에 있는 "서비스"를 클릭하여 실행해 줍니다. ABC 순으로 나오는 각종 서비스들을 주욱 스크롤 다운하면 "OpenVPN Service"라는 서비스 항목이 보이는데 이를 더블클릭합니다. 일반 탭의 중간 쯤 보면 "시작 유형"이 "수동"으로 되어 있을 것입니다. 이것을 아래 그림과 같이 "자동"으로 바꾸어 주고 적용을 누르고 "확인"을 눌러 빠져나옵니다.

윈도우즈 용 OpenVPN Service 속성 화면OpenVPN Service 항목을 더블클릭하면 나오는 속성 화면입니다. 이 화면에서 바로 서비스를 시작, 중지, 일시중지, 계속을 할 수 있으며 부팅 시의 시작유형을 변경할 수도 있습니다.

          이제 재부팅 해 주면 자동으로 OpenVPN 서비스가 시작됩니다.

 

이상으로 Raspberry Pi를 OpenVPN 서버로 만들기 제2부를 마칩니다. 마지막 제3부에서는 VPN이 제대로 운영되기 위한 공유기 설정과 문제해결 (Trouble Shooting and Workaround)에 대해 언급하고 연재를 마치겠습니다.

Posted by truerain
l

1. 환경

 

     (1) 실행 하드웨어 및 운영체제

         - Raspberry Pi 2 (운영체제 : Raspbian Wheezy/Jessie) 또는,

           호환 확인된 유사 보드 : Orange Pi PC (운영체제 : Armbian Jessie)

         ※ 물론 ARM 계열 보드들 뿐만아니라 Debian의 Wheezy 혹은 Jessie 배포판을 사용하는 일반적인 PC환경에서도 동작할 것입니다.

 

     (2) 네트워크 – 공유기 (ipTIME) 내부 사설 네트워크

         - 공유기 게이트웨이 : 192.168.0.1

         - OpenVPN이 설치될 라즈베리파이 (혹은 오랜지 파이) 보드 :  

                                     192.168.0.2 (공유기 설정에서 사설IP 예약 할당)

           - 공인 고정 IP 혹은 DDNS (이 글에서는 my_network.iptime.org로

           DDNS 설정이 되어 있는 상황을 가정합니다.)

 

2. OpenVPN 설치

 

     (1) 데비안 Wheezy 버젼인 경우 

          easy-rsa가 openvpn 패키지에 포함되어 있으므로 별도로 설치할 필요가 없습니다.

1
$ sudo apt install openvpn
cs

 

 

     (2) 데비안 Jessie 버젼 이후의 경우 

          easy-rsa가 별도 패키지로 분리되었기때문에 함께 설치가 필요합니다.

1
$ sudo apt install openvpn easy-rsa    
cs

 

 

3. 설정 (A) : easy-rsa 관련파일 생성

 

     (1) root프롬프트 전환

          권한문제 등을 원활히 해결하기 위하여 아래와 같이 root 프롬프트 환경으로 진입합니다.

1
$ sudo –s    
cs

 

     (2) TLS기반 인증을 위한 easy-rsa 스크립트 폴더 복사

         - Wheezy의 경우

1
# cp –r /usr/share/doc/openvpn/examples/easy-rsa/2.0 /etc/openvpn/easy-rsa   
cs

 

         - Jessie의 경우

1
# cp –r /usr/share/easy-rsa /etc/openvpn/easy-rsa   
cs

 

     (3) vars 파일 변수 설정 편집

1
2
# cd /etc/openvpn/easy-rsa
# nano ./vars
cs

          vars파일이 열리면 ‘EASY_RSA’라는 변수를 찾아 =표시 뒤의 값이 아래와 같이 되도록 바꾸어 줍니다.

1
export EASY_RSA=”/etc/openvpn/easy-rsa”
cs

 

(이때 줄 맨 앞에 #표시가 붙지 않아야 합니다. 설정파일 특정 행의 선두에 #이 붙어있다는 것은 그 행 전체가 주석이라는 의미입니다.)

vars파일의 EASY_RSA 변수 부분.vars파일의 EASY_RSA 변수 부분을 찾아 그 값을 변경해 준 이후의 모습입니다.

          계속해서 아래 내용이 나오는 부분을 찾습니다.

1
export KEY_COUNTRY="US"
cs

          위 변수 선언이 나오는 곳을 찾아 =부호 뒤 따옴표 안의 US를 서버가 위치한 곳의 국가코드로 바꾸어 줍니다. (반드시 2자리 국가코드 형태로 입력합니다. 우리나라는 KR이겠지요.)

          그 아래로 KEY_PROVINCE  변수는 =부호 뒤 따옴표 안의 CA를 서버가 위치한 특별/광역시/도 영어 이름으로 바꾸어 줍니다. 마찬가지 방법으로 도시도 바꾸어 주고, KEY_ORG는 영어 회사명 혹은 누구네 집 (~’s home)정도를 입력해 줍니다. KEY_EMAIL은 굳이 기재할 필요는 없는데 스크립트가 공란을 허용하지 않으므로, . 만 입력하고 넘어갑니다. KEY_OU는 부서명을 영어로 입력하거나 .를 입력하여 넘어갑니다. 아래 그림은 서울시 용산구에 위치한 용산(주) 영업부라는 가상 조직의 예를 var파일의 해당 변수에 입력한 예시 화면입니다.

vars파일 예시입니다.이 그림은 서울시 용산구에 위치한 용산(주) 영업부라는 가상 조직의 예를 var파일의 해당 변수에 입력한 예시 화면입니다.

          위 KEY_COUNTRY부터 KEY_OU까지는 아래에서 언급할 키 생성 스크립트들에서 사용자에게 물어보는 값들입니다. 이때 [ ]안에 우리가 var파일에 입력한 국가코드, 시도 이름, 도시 이름 등이 기본값으로 제시되며 그냥 엔터만 누르고 지나가면 기본값이 입력되고, 변경하고자 한다면 변경될 값을 입력한 후 엔터를 입력하면 변경된 값이 적용되는 방식입니다. 

          자, 이제 Control + X 키를 누른 뒤 nano 에디터가 저장할 지를 물으면 Y 키를 눌러 저장하고 나옵니다.

 

     (4) CA (Certificate Authority) 구축

1
2
3
# source ./vars
# ./clean-all
# ./build-ca
cs

          위 bash 명령어에서 첫 줄은 vars 파일에서 선언해 준 변수들을 읽어들여 참조하라는 의미이며, 두번째 줄은 서브디렉토리 keys/가 생성되어 있다면 해당 폴더의 내용을 전부 지우는 명령입니다. 따라서 처음 key들을 생성할 때 이외에는 실수로 이 명령어를 입력하지 않도록 주의하여야 하며, 반대로 모든 key작업을 처음부터 다시 시작하여야 할 필요가 있을 때, 유용하게 이 명령을 사용함으로써 초기화된 깨끗한 환경에서 새로 CA와 키들을 생성할 수 있습니다. 세번째 줄의 명령어는 CA (Certificate Authority)를 생성하라는 의미입니다.

          CA 생성을 시작하면, EASY_RSA 프로그램은 난수를 생성한 뒤, 위에서 우리가 변수로 선언한 국가코드 등을 어떻게 적용할지를 사용자에게 묻는 절차를 진행합니다. vars파일 편집을 잘 해 놓으셨다면 특별히 변경 없이 엔터를 입력하여 넘어가도 무방해 보입니다.

 

     (5) 서버 Certificate 및 KEY 생성

1
# ./build-key-server [서버_이름] 
cs

          이제 위 명령어를 통해 서버 인증서와 키를 생성해 줍니다.

          서버 이름은 해당 부서 혹은 회사 전산실에서 OpenVPN 서버로 사용할 컴퓨터를 네트워크 상에서 구분해서 부르는 영어(와 숫자로 된) 실제 이름을 붙여 기재합니다. 예를 들어, 그냥 Server라는 이름을 붙였을 경우 아래와 같이 입력합니다.

1
# ./build-key-server Server 
cs

          단, 서버 이름은 이 후에 만들 클라이언트들의 이름과 겹치지 않도록 하는 것이 관리 목적상 중요합니다. 아울러 이 명령에 입력하는 [서버_이름]이 서버키를 만드는 과정에서 스크립트가 CN (Common Name) 값을 물어볼 때 [ ]안에 들어가는 기본값이 되는데, 이 기본값을 유지해 주어야 합니다. 이 CN 값은 모든 클라언트와 서버가 각각 고유한 값을 가져야 합니다. (즉, 동일한 값을 입력하면 작동시 오류가 납니다.) 단, 설정파일에서 동일한 값을 갖을 수 있도록 옵션을 설정할 수는 있지만, 역시 관리목적상 바람직하지 않습니다.

          또한가지 중요한 것은, 스크립트가 사용자의 입력값을 요구하면서 아래와 같이 묻습니다.

1
A challenge password?
cs

          이때 어떠한 값도 입력하지 말고 엔터를 입력해야 합니다.

1
Sign the Certificate?
cs

          라는 질문에는 Y를 입력해야 합니다.

1
Sign the Cer1 out of 1 certificate requests certified, commit?
cs

          여기에도 Y를 입력하면 비로소 정상적으로 서버 인증서와 키가 완성됩니다.

 

     (6) Client Certificate 및 Key 생성

          이제 클라이언트용 키를 생성하는 단계입니다. 클라이언트용 키는 일반적으로 VPN에 접속할 VPN사용자 단위로 만들어 줍니다. 그래야 회사의 경우 VPN사용자 퇴사 시 해당 클라이언트 키만 무효화하여 서버와 다른 클라이언트를 유지할 수 있습니다. 따라서 이 경우 해당 VPN사용자의 고유한 값 (e.g. 사원번호)을 [클라이언트_이름]과 CN 값으로 입력하는 것이 현명해 보입니다.

          만약 가정에서 운용하고, 접속하는 VPN사용자는 극히 적고 변동될 가능성이 없는데 동일한 VPN사용자가 PC, MAC,  모바일 기기 등 여러 디바이스로 접속한다면, 접속하는 디바이스의 고유 이름대로 클라이언트 키를 만들어 줄 수도 있을 것입니다. 물론, 이 경우 접속하던 디바이스를 처분할 때, 해당 클라이언트 인증서와 키를 폐기하는 스크립트를 실행해 주어야 하겠지요. 특히 비밀번호 없이 클라이언트를 생성할 경우 폐기 절차는 보안에 절대적으로 필요합니다.

           아래 명령어는 참고만 하십시오.

1

# ./build-key-pass [클라이언트_이름] 

cs

          역시 [클라이언트_이름]으로 입력해 준 값이 CN 기본값이 됩니다.  위 명령은 클라이언트 키를 생성하는 스크립트가 진행될 때 PEM 패스워드를 만들도록 되어 있습니다. 위 방식으로 클라이언트 키를 만들면, VPN사용자는 OpenVPN 서버에 접속할 때마다 PEM 패스워드를 입력하여야 합니다. 또한 위 방식으로 만든 클라이언트가 iOS, 안드로이드 등 모바일기기에서 서버에 접속하고자 한다면, 3des 파일을 한 번 더 만들어 줘야 한다고 합니다. 이 글에서는 위 방식은 다루지 않고 아래와 같이 PEM 패스워드를 입력하지 않고 접속하는 클라이언트 생성방법을 설명합니다.

1
# ./build-key [클라이언트_이름] 
cs

          [클라이언트_이름]은 전술한 바와 같이 적절하고 고유한 클라이언트의 실제 이름으로 치환하여 입력하여야 합니다. 예를 들어, Client1 이라는 이름으로 클라이언트 키를 생성하기 위해 아래와 같이 입력합니다.

1
# ./build-key Client1 
cs

          그러면 스크립트가 난수 생성과정을 진행한 뒤 서버키 생성때와 마찬가지로 사용자의 입력값을 쭉 요구하고 나서 아래와 같이 묻습니다.

1
A challenge password?
cs

          역시 이때 어떠한 값도 입력하지 말고 엔터를 입력해야 합니다.

1
Sign the Certificate?
cs

          라는 질문에는 Y를 입력해야 합니다.

 

     (7) Diffie-Hellman key exchange 생성

1
# ./build-dh 
cs

          우리가 var파일에서 해당 변수에 특별한 변경을 하지 않았다면, 위 명령을 입력했을 때, 스크립트가 2048 비트로 암호화하는 dh2048.pem 파일을 keys 디렉토리 내에 생성합니다. 이 파일의 생성시간이 상대적으로 서버, 클라이언트 난수 생성보다 꽤 길게 느껴질 것입니다. 그래서 데비안 wheezy 때까지만 해도 암호화 수준을 1024 비트 수준으로 하는 것이 var파일의 기본값이었고 권장값이었는데, Jessie로 넘어오면서는 기본값이 2048 비트로 되어 있더군요. 아마 하드웨어의 성능이 비약적으로 향상되면서 1024 비트의 암호해독 속도도 줄었을 것이고, 반대로 2048 비트로 암호화 하는 체감 속도도 과거 보다는 빨라졌기 때문에 생긴 변화일 것이라 생각해 봅니다. (순식간에 완료하겠구나 하고 오해하는 것은 금물입니다. 과거보다 빨라졌을 뿐, 2048비트 암호화 파일 생성시간이 orange pi pc 기준으로 12~13분 가량 이상은 됩니다.) 아무튼 보안 수준이 높아진다는 것은 나쁠 것은 없지요.  

 

     (8) ta.key 파일 생성

1
# openvpn –-genkey –-secret keys/ta.key 
cs

          이제 해커의 DoS (Denial of Service) 공격을 대비하기 위해 서버와 클라이언트가 공유하는 파일인 ta.key 파일을 위와 같은 명령으로 만들어 줍니다.

 

   이상으로 Raspberry Pi를 OpenVPN 서버로 만들기 제1부 내용을 마칩니다. 이어질 2부에서는 서버와 클라이언트 설정파일을 생성하는 과정까지 마치고 3부에서는 실제로 운용해보고 발생하는 문제에 대한 대처 등을 다루어 볼까 합니다.

Posted by truerain
l

   지난 달 28일 법원은, 故 백남기 농민에 대한 부검영장을 발부하면서, 첨부 문서 형태의 '압수수색 형태의 검증과 제한'이라는 글을 통해 부검장소, 참관인 등 중요 절차에 관련하여 유족의 의사를 반영하여 진행하도록 한 바 있습니다. 이 영장은 기존에 알려져 있던 영장의 형식과 내용에서 크게 벗어난 것이어서 논란이 되었습니다. 법원이 1차 영장청구는 기각한 뒤, 2차로 제출된 영장청구를 기각시키지 못하고, '내키지 않는 부검영장을 내어 주면서 탄생한 고육지책의 흔적이다.'라든지, '말도 안되는 부검에 대한 고민과 책임을 유족 측에 떠넘기는 것이다.' 등의 논란이 분분했습니다. 이 영장은 집행기관인 검찰/경찰과 피집행 측인 유족에도 법원의 진의(眞意)와 강제성에 대한 숱한 논란을 야기했지요.

   이런 와중에 검찰은 지속적으로 '영장(집행)의 강제성'을 강조하며, 집행을 강제할 수 없는 영장은 있을 수 없다는 논리를 보여왔습니다. 급기야 어제 (6일) 오후에는 서울지검 관계자가 기자간담회를 열어, '조건부영장이란 없다. 영장을 발부받았으면 집행해야 한다.'는 이야기를 하며, 유족과 합의가 되지 않더라도 유족의사에 반하여 영장을 집행하겠다는 의지를 천명했다고 하는 기사가 나왔습니다.

   검찰이 이야기하는 '영장 집행의 강제성'... 과연 맞는 말일까요?

   위키피디아에서 '영장(令狀)'을 찾아보면 다음과 같이 그 뜻을 설명하고 있습니다.

 

영장(令狀)은 명령을 기록한 종이문서로, 특히 법원 또는 법관이 사람 또는 물건에 대하여 체포, 구금, 수색, 압수 명령 이나 허가를 내용으로 하여 발부하는 문서를 말한다.
대한민국헌법에서 체포·구속·압수 또는 수색을 할 때에는 적법한 절차에 따라 검사의 신청에 의하여 법관이 발부한 영장을 제시하여야 한다.
다만, 현행범인인 경우와 장기 3년 이상의 형에 해당하는 죄를 범하고 도피 또는 증거인멸의 염려가 있을 때에는 사후에 영장을 청구할 수 있다.
영장은 ‘명령서’, ‘통지서’로 한국어 순화어를 쓰도록 권장 됨에 따라 입영영장은 입영통지서로 쓴다.
 ● 수색영장은 수사기관에게 피의자 등을 상대로 형사소송상의 증거물을 수색할 것을 명령하는 법원의 명령장이다.
 ● 체포영장은 혐의자의 체포를 지시하는 검찰이 청구하고, 판사는 이를 검토하여 승인하는 명령장이다.
 ● 구속영장은 피고인이나 또는 피의자를 구인·구금하기 위하여 검사의 청구에 따라 법원이 발부하는 영장이다.
 ● 인신보호영장은 이유없이 구금되었을 때 신청해 구금에서 풀려날 수 있게하는 영장으로, 대한민국에서는 구속적부심사를 쓴다.

 

   부검영장은 故백남기씨의 '사인(死因)을 밝히겠다'는 취지로 수색하겠다는 수색영장의 일환입니다. 앞서 위키피디아도 적시하고 있듯, 수색영장은 사법부가 행정부의 수사기관에게 이렇게 이렇게 수색하라는 명령서(장)입니다. 명령을 하는 쪽이 법원이고, 명령을 받아 집행하는 쪽이 수사기관입니다. 즉, 수사기관 자의(恣意)에 의해서가 아닌, 법원의 권위와 명령을 '수사기관이 받아' 법원의 명령을 집행한다는 것입니다. 이에 따라 영장 집행의 '강제성'이라고 하는 것은, 수사대상에게만 적용하는 것이 아니라, 행정부 수사기관도 '법원의 명령에 따라' 집행하여야 한다는 '강제성'을 의미합니다. 그것을 현재 검찰에서는 '집행의 강제성'만 강조하며 강제집행 운운하고 있는 것이지요. 당연히, 검찰/경찰 등 행정부 수사기관의 자의적(恣意的) 영장집행은 수사기관의 위법 행위를 의미하게 됩니다. 만약, 사법부의 명령을 무시한 자의적(恣意的)인 '강제집행'을 검/경 수사기관이 강행한다면, 이 위법을 누가 벌할 수 있을까요? 입법부가?... 사법부가?... 제4부라고 일컬어 지는 언론에서?... 이도 저도 아니면 저들이 개, 돼지라고 멸시하는 99% 국민들이?... 견제받지 않고 무소불위로 폭주하는 검찰, 경찰, 세무서 등의 행정부 권력기관이 의미하는 바는 뭘까요?

   대한민국은 민주주의를 표방하는 법치국가입니다. 법치국가에서 3권분립의 철저한 준수는 민주주의 실현 정도의 척도가 될 수 있습니다. 행정부의 수사기관은 사법부의 (명)령장없이는 국민을 자의적(恣意的)으로 구속하거나 수색하는 등 기본권을 침해할 수 없습니다. 수사기관이 사법부의 (명)령장을 자의적(恣意的)으로 해석하여 (명)령장에 반(反)한 위법행위를 하는 것도 있을 수 없는 일입니다. 만약 가능하다면, 행정부가 사법부를 무시하고 사법부 위에 있음을 인증하는 바로미터가 될 수 있겠지요. 바로 (그 어느 분이 그렇게 듣기 싫어 하신다는) 헬조선 독재국가를 인증하는 순간이 될 것입니다.

   삼가 故 백남기 농민의 명복을 빕니다.

Posted by truerain
l


    지난 8월 초, 마이크로소프트사는 자사의 운영체제 윈도우10 (Windows 10)의 출시 1주년을 기념하는 대대적인 업데이트를 출시하였습니다. 이른바 1주년 기념 (Anniversary) 업데이트 였는데요. 버전 넘버를 1607, 코드명이 Redstone 1이라고 했지요.

    이 업데이트로 보안 등 여러 분야의 업데이트가 있었겠지만, 아무래도 저와 같은 평범한 End User들은 사용자 경험 (UX) 부분에 눈길이 가기 마련입니다. 저는 그 중에서도 시작 화면의 ‘모든 앱’ 이 사라지고 이 모든 앱들이 바로 세로로 죽 표시되도록 바뀌었다는 점이 눈에 띄더군요. 또 하나는 바로 이 글의 주제인, 이전 1511버전까지 ‘자주 사용되는 앱’ 오른쪽 끝에 있었던 ‘점프목록(Jump List) 보기’라는 기능을 가진 ‘>’ 모양의 단추가 사라졌다는 것이 눈에 들어 왔습니다.

    아래 1511 버전의 부분 스크린샷을 보시면 아시겠지만, 이전 버전까지 존재했던 버튼이었습니다.

윈도우10 1511버전의 시작화면 부분스크린샷윈도우10 1511버전의 시작화면 부분스크린샷입니다. '자주 사용되는 앱'에 있는 앱들의 아이콘과 앱 이름 오른쪽으로 '>' 모양의 '점프목록보기' 단추를 보실 수 있습니다.



    ‘어? 이게 어디갔을까…?’

    일 하다가 점프목록으로 필요한 엑셀파일을 열던 습관이 있어서 계속 찾게 되었지만 어디에도 보이지 않더군요. 그러다가 우연히 어제 1607버전 윈도우10을 쓰면서 점프목록을 볼 수 있는 방법을 발견했습니다. 저는 이전 1511버전 윈도우10도 별도로 돌리고 있어서, 확인해 보니 그 버전에서도 가능했던 방법이었네요. 그래서 이미 아시는 분들은 다 알고 계셨겠지만, 저처럼 그냥 아무 생각 없이 이전 버전에서 ‘>’ 단추로 점프목록을 불러와 사용하시던 분들은 1607 버전에서 당황하셨을 수도 있겠다 싶어, 공유해 봅니다.

    1607버전은 화면 좌측하단의 윈도우 로고를 클릭하여 나오는 ‘시작화면’에 ‘자주 사용되는 앱’에서부터 숫자, ABC, 가나다 순으로 세로로 앱들을 표시합니다. 이때 ‘자주 사용되는 앱’에 있든지 그 아래 순서대로 있든지에 관계 없이, 그냥 해당 앱을 찾아 그 위에 마우스 커서를 놓고 우클릭합니다.

윈도우10 1607버전의 시작화면 부분스크린샷윈도우10 1607버전의 시작화면 부분스크린샷입니다. '자주 사용되는 앱'들 뿐만 아니라 그 아래 숫자, 알파벳 순으로 늘어선 앱들의 오른 쪽에 '>' 단추가 더이상 보이지 않지만, 오른쪽 클릭으로 '점프목록'을 불러 오는 것은 여전히 가능합니다.


    그럼 위 그림과 같이 이전 버전에서 ‘>’ 단추를 클릭했던 것과 동일한 점프목록을 보실 수 있습니다. 앞에서도 언급한 바와 같이 이전 버전의 윈도우10에서도 가능했던 방법이므로 1511 버전 사용자 분들도 적용 가능하십니다. 이 소소한 팁이 쾌적한 윈도우 사용에 작은 보탬이 되시길 바랍니다.

Posted by truerain
l

 

● ‘메르스 사태’의 현황… 현재 대한민국 정부는 메르스를 통제할 능력이 있는가?


현 상황부터 빠르게 한 번 보자.

연합뉴스의 보도에 따르면 인터넷 기사의 최종 수정 시간인 2015년 6월 2일 오전 9시 50분 현재, 사망자 2명, 확진환자는 3차 감염자 포함 25명, (이 기사에는 나오지 않지만 다른 기사는) 자가격리 대상자가 현재 680여명 이상이라고 한다.

지금까지 정부가 뒤늦은 대처로 정부의 통제력 밖에서 지속적인 환자와 사망자가 발생한 점을 고려하면 현재의 관리상태는 반드시 조만간 ‘주의’에서 ‘경계’ 이상으로 격상되어야 한다. 즉, 역학조사의 전면 재 실시를 통해 모든 감염경로를 재 추적하고, 감염 의심자를 포함한 모든 (잠재적) 환자와 접촉한 사람들을 자가 격리가 아닌 시설 격리 조치하여야 이 사태를 ‘현재 수준에서’ 통제할 수 있다.

여기서 이미 대한민국 정부는 이 새로운 전염병에 대한 통제력을 상실했을 가능성이 높다. 이미 최초 국내 감염자와 2차 감염자에 관련하여 골든 타임을 놓친 것은 주지의 사실이다. 이것이 의미하는 바는 1차 및 2차 감염자가 감염된 후 접촉한 모든 사람을 파악하는 것이 현 시점에 와서는 거의 불가능하다는 것이다. 보균자의 전염률이 어쩌고, 잠복기의 전염 불가능이 어쩌고 하는 이야기는 집어 치우자. 지금까지 정부관계자와 관련 전문가 분들이 언론에 나오셔서 하셨던 말씀 중에 맞는 말씀이 얼마나 있었는가? 그런 이야기는 정부와 전문가들에 대한 불신만 키울 뿐 사태 해결에 아무런 도움도 주지 못한다.

게다가, 위 언론 보도에 의하면 시설 격리 대상자가 1천 명을 넘기게 되면 대한민국 내 의료시설 수준에서 시설 격리 자체가 불가능할 수 있다고 한다. 이 이야기는 격리 대상자가 1천 명을 넘기면 전수(全數) '강제' 시설 격리 자체를 시행할 수 있는 물리적인 시설이 없어, 시행하고 싶어도 할 수 없는 상황이 된다는 의미이다.

현미경으로 관찰된 MERS 바이러스현미경으로 관찰된 MERS 바이러스의 모습 (출처 : 영문판 위키피디아)http://en.wikipedia.org/wiki/Middle_East_respiratory_syndrome_coronavirus

만약, 사태가 정부의 통제력을 벗어나게 되면, 즉 국내에 신규 전염병이 ‘창궐’하는 수준이 되면, 질병관리본부는 그들의 매뉴얼대로 업무를 했는지 여부와 관련 없이, 결과적으로 그들의 핵심 과업이자 존재 이유인 '신규 전염병의 신속하고 적절한 통제 및 확산 방지'라는 직무수행에 완벽하게 실패하는 것이 된다.

자, 대한민국 정부는 현재, 메르스를 통제할 능력이 있는가?


책임소재… 질병관리본부 실무자와 책임자 만의 잘못인가?


만약, 대한민국 정부가 메르스를 통제할 능력을 이미 잃었다면, 혹은 조만간 잃게 된다면, 그 책임은 누가 져야 하는가? 언론이 우선 원인 규명에 나서게 마련이다. 이미 최초 감염자 확진 이후 하루 이틀 사이 2차 감염자가 ‘예상 외로’ 속출하면서, 의료기관과 질병관리본부의 대응에 관하여 문제가 없었는지를 점검하는 언론의 보도가 하나 둘 나오고 있었다. 이 보도들 중 최근의 한 보도를 보면 최초 감염자에 대한 의료진의 메르스 의심이 시작된 5월 17일부터 메르스 확진이 나온 20일까지 질병관리본부 대응이 매우 안일했고, 2일 이상의 골든 타임을 놓침과 동시에 감염루트를 확인할 수 없어서 통제 자체가 불가능한, 현재의 이 엄중한 상황이 만들어 진 것으로 보인다. 그렇다면 일차적으로는 질병관리본부 해당 담당자와 그 관리 감독자가가 책임져야 할 일이다. 그것은 당연한 일이다.

그런데, 그 질병관리본부에서는 오늘의 이 사태를 예견했을까?…. 언론이 파고 들기 시작하자 5월 21 무렵 해명을 내어 놓은 바 있다. 자신들은 매뉴얼을 준수했으며 환자와 의료진이 제공한 정보가 메르스에 대한 조치를 개시할 수 있는 수준이 아니었으며 제공되지 않은 정보도 있었다는 취지의 해명이었다.

좋다. 공무원의 해명을 그대로 믿어 보자. 여기에서 두 가지의 책임소재 이슈가 더 발생한다. 하나는 국민들이 죽어나가도 매뉴얼 대로만 움직였으면 괜찮은 것인가 하는 공무원의 복지부동 문제이고, 두 번째는 매뉴얼을 충실히 이행했는데도 그 매뉴얼의 목표 달성을 이렇게 철저히 실패한다면, 이런 후진적이며 사후약방문적인, 적절한 대응이 결코 불가능한 매뉴얼을 왜 아직까지 유지하고 있었는가 하는 문제이다.

 

공무원들의 무사안일, 복지부동이 과연 핵심일까?


이런 사태가 발생하면 늘 그렇듯, 공무원들의 무사안일과 복지부동을 질타하는 언론의 보도와 여론의 흐름을 읽게 된다. 이번 사태도 그런 경향을 볼 수 있다. 물론 나도 백 번 동의한다. 그리고 이 사태 초기부터 아마 누구나 예상하고 걱정했을 것이다.

그런데, 공무원의 무사안일과 복지부동은 사실 그들의 본질적 특성이다. 인터넷 댓글들을 보면, 이런 사태가 발생하게 되는 것을 근거로 모든 공무원들의 연금혜택, 신분보장 등을 박탈해야 한다는 식으로 과격하게 주장하는 사람들이 있는데, 그러한 연금혜택과 신분보장을 괜히 해 주는 것이 아니다. 그런 보장을 전제로 나랏 일을 시켜야 공무원의 애국심과 봉사정신을 유도하고, 국가가 안정적인 대 국민 서비스를 보장할 수 있다는 믿음에서 그런 제도를 (여러 보수적인 선진국가들처럼) 공무원들에게 제공하는 것이다. 이러한 공무원에 대한 보장 제도로부터 불가피하게 (어쩌면 필요악으로서) 무사안일과 복지부동이 나온다.

그렇기 때문에 공무원 신분보장 및 연금 제도를 시행한 이래로 역사상 단 한번도 공무원들이 무사안일과 복지부동하지 않은 적이 없다. 물론 이러한 속성을 이겨내고 개인적인 성품에 따라 헌신적이고 귀감이 되는 공무원 ‘개인’이 때때로 나온다. 나는 지금 공무원 ‘집단’의 본질적 속성과 성향을 이야기하고 있는 것이다.

공무원들의 무사안일과 복지부동은 어제 오늘 이야기가 아닌데, 때에 따라서 공무원들의 업무가 가시적인 성과로 나타나기도 하고 이번 사태와 같이 처참한 실패로  귀결되기도 한다. 무엇이 그러한 차이를 발생시킬까?

열쇠는 공무원 집단을 지휘 통제하는 ‘정권’이 쥐고 있다. 우리가 싸잡아 비판하는 ‘정부’에는 권력에 따라 사람이 바뀌며 정부 조직의 상위직을 차지하는 ‘정권’이 있고, 이른바 관료집단이라고도 하는 ‘직업적 공무원’들이 있다. ‘직업적 공무원’들은 전술한 바와 같이 애당초 무사안일과 복지부동을 숙명적 속성으로 하고 있다. 그들은 과잉대응해서 생기는 귀찮은 문제를 싫어 한다. 때로는 그러한 과잉 대응으로 인해 그들의 혜택인 보장된 신분에 문제가 발생할 수도 있기 때문이다. 마찬가지로 정상적이고 평범한 공무원이라면 최소한 매뉴얼 수준으로는 일하고자 한다. 공무를 매뉴얼 수준으로도 하지 않는다는 것은 공무원의 복무규정 위반을 뜻하는 것으로써 역시 그들의 보장된 신분상 혜택을 박탈 당한다는 것을 의미하기 때문이다. (지난 세월호 사건 때의 해경 진도관제센터 당직자를 상기해 보시라.) 한편으로는 그들이 (적절한) 매뉴얼대로 대응해야 국가 시책의 일관성과 안정성이 담보되기도 한다.

아무것도 안하고 싶다. 이미 아무것도 안하고 있지만 더 격렬하게 아무것도 안하고 싶다.얼마전부터 사람들의 공감을 얻어 유행한 한 신용카드사의 광고장면 속 카피이다. 매뉴얼보다 높은 수준의 (과잉) 대응을 바라보는 직업공무원의 시각을 정확히 대변해 주는 카피가 아닐까 싶다. ⓒ삼성카드 (출처 : youtube.com)

결론적으로 ‘정권’은, 담당 공무원이 때마침 헌신적인 공무원이어서 본인의 인사상의 불이익을 무릅쓰고 국민이 잠재적으로 처할 수도 있는 위험에 적극적으로(매뉴얼에 비하면 과잉으로) 대응해 주는 요행을 바랄 것이 아니라, 이러한 일반적으로 복지부동 성향의 ‘직업적 공무원’들을 이끌고 이들이 올바르고 적절한 매뉴얼을 갖추고 '매뉴얼 대로' 대(對)국민 서비스를 하도록 인사권, 시행령,시행규칙 등을 통해 지휘, 통제해야 하는 것이다. 

위에서 두 번째 문제로 제시한 후진적, 사후약방문적 대응 매뉴얼의 문제는 바로 이 지점에서 해법이 나온다. 국가적 위기 대응 시나리오를 철저하게 재검증하여, 이러한 어이없는 땜질식 대응이 ‘매뉴얼’을 근거로 시전(施展)되는 후진적 비극이 생기지 않도록 '정권'이 '공무원'들을 제대로 지휘, 통제하는 것... 그래서 선진적, 선제적 매뉴얼을 구축하고 국민에게 온전히 서비스될 수 있도록 하는 것... 그것이 핵심인 것이다. (어디서 많이 듣던 레파토리 아닌가? 한... 1년 전 쯤에?...)

 

국가 재난 관리 체계가 이러한데 세월호 진상규명 요구가 여전히 지겨운가?


그랬다. 사실 우리에게는 1년 여 전에 위와 같은 시스템과 매뉴얼을 갖출 수 있는 절호의 기회가 있었다. 일부의 일반인을 포함하여 3백여 명 이상의 꽃다운 학생들이 남해 바다에 수장되는 것을 충격 속에 목도하며 온 국민이 통한과 통곡의 눈물을 흘린 댓가로 얻은 기회였다. 어디 이런 기회가 한 번뿐이었으랴마는… 당시에 행정부 수반께서는 참담하게 드러난 대한민국의  재난 대응 능력의 부재(不在)를 보시고, 그 원인을 구시대의 유물인 ‘적폐’에서 찾으셨다. 그리하여 마침내 ‘해경을 해체’하시겠다고 선언하시며 범국가적 재난 대응 시스템을 다시 세우시겠다고 약속하셨다.

그런데 1년 여 뒤, 오늘을 보라. 신규 전염병이 발병율과 사망자 수에서 세계 선두권을 달리며 국격을 드높이고(?) 있고, 관련 공무원의 안일한 대응으로 이웃 국가에 까지 질병을 수출하시어, ‘더러운 보균국', ‘질병관리 후진국’ 소리 들어가며 비난 받고 있다.

전술한 바와 같이 ‘정권’이 ‘직업 공무원’들을 어떻게 움직이냐에 따라 2000년대 중반 노무현 정권 때의 ‘사스’ 대응처럼 전세계적인 칭찬과 부러움을 받느냐, 아니면 이 정권의 메르스 대응처럼 이웃 국가의 멸시와 조롱과 혐오를 받느냐의 차이가 결정된다.

자, 여전히 세월호 유족들과 일부 사회단체들은 세월호 진상규명 및 온전한 선체인양 조사를 요구하고 있다. 아직도 1년 지난 세월호 타령이냐는 분들께 묻고 싶다. 세월호 진상규명 요구(보상 규모를 묻는 게 아니다.)가 지금도 지겨우신가?


궁극적으로 최종 책임은 누가 지는가?


그렇다면 이번 메르스 통제 실패의 최종 책임은 ‘정권’이 지는가? 만약, 그렇게 된다면 나름 다행(?)이라고 할 수 있을까? 하지만 결코 그렇지 않다. 그 책임은 결국 ‘국민’이 지게 된다. 이 글이 결국 비극적 결론을 내는 순간이다. 국민의 책임은 결코 그 정권 창출에 기여하거나 찬성한 국민과 반대한 국민, 별 관심 없던 국민을 가리지 않는다. 비극을 넘어 처참한 결말이 되겠다.

‘정권’은 어떻게든 책임을 다른 데로 돌릴 것이다. ‘공무원’들의 무사안일과 복지부동이 그들의 본질이듯, ‘정권’의 책임 돌리기 또한 정권재창출을 위한 그들의 본질적 속성이다. 전 정권의 책임으로 돌리든가, ‘세월호’의 유병언같은 이를 찾든가, 여러 방안들이 있을 것이다. 어느 인터넷 댓글처럼 이번엔 질병관리본부를 해체하실까나? 이왕이면 통크게 보건복지부를 해체해 버리실 수도... 뭐 이도 저도 안되면 질병관리본부장이나 보건복지부 장관 경질하는 수준에서 그냥 뭉개든가…. 이 정권에는 무슨 잘못을 해도 괜찮은 지지율 40%짜리 천부(天付) 콘크리트 ‘까방권’이 있지 않은가?

감기 바이러스 등의 대재앙을 다룬 영화 포스터들2차, 3차 감염자 속출, 사망자 연쇄 발생 등 MERS의 공포가 확산되는 가운데, 그동안 감기 바이러스 등을 소재로 다루었던 재난 영화들이 회자되고 있다. (출처 : 쿠키뉴스. http://durl.me/8wgo8g)

국민은 정권에 대한 찬성 여부에 상관없이, 다른 데가 아파도 병원 가면 메르스 옮을까 두려워하면서 메르스 감염자가 있을지도 모를 병원에 가야 하며, 메르스 감염자가 있을지도 모를 버스에 타는 공포의 모험을 감행하는 형태로 책임을 져야 한다.(러시안 룰렛 수준의 스릴과 어드밴쳐를 선사해 주신 대한민국 정부에 감사패라도 드려야 하나?) 차라리 이웃 국가 국민들로부터 받는 멸시와 조롱, 그리고 요우커들이 '더러운 병 옮을까 두려운' 대한민국 관광 대신 '지진 날까 두려운' 일본 관광을 택하는 경제적인 손실 따위는 국민이 져야 할 책임 중에 부차적인 것이 될 수 있다. 입에 담고 싶진 않지만, 최악의 경우 도대체 어디서 옮았는지 알 수 없는 메르스로 인해 억울하게 사망해야 하는 형태로 책임을 질 수도 있는 것이다.

물론 신뢰가 무너져, 사태가 확산될 때마다 나오는 정부의 회의와 대책 자체가 공포와 괴담 수준이기에, 오늘을 대한민국 국민으로 살아가고 있다는 것 자체가 결국은 국민이 책임지고 있다는 것이겠지만…

Posted by truerain
l
    우리 사회는 지난 몇일 전부터 인터넷 상으로 표출된 한 이슈에 관련하여 큰 논란에 휩싸이고 있다. 바로 김문수 도지사의 '119 전화'와 그로부터 비롯된 '인사조치'에 관련해서 였는데, 경기도 홈페이지가 마비될 정도의 네티즌들의 공세에 김 도지사 측이 백기를 들면서 급기야 전화를 받은 두 소방관에 대한 원상복귀 조치가 내려지는 상황까지 전개가 되었다. 이번 사건으로 인해 김문수 도지사는 많은 네티즌들로부터 '긴급하지 않은' 행정문의를 위하여 '긴급전화'에 전화를 한 개념 없음과 보복성 인사조치로 성품의 치졸함이 적나라하게 드러났다는 평가를 받았다. 그러나 이렇게 (사람 하나 찌질한 놈으로 만들고) 논란을 접기 보다는 한번 쯤은 더 생각해 보아야 할 문제가 있지 않을까? 이제 이 폭풍같던 논란이 수그러질 때가 되었기에 그 생각들을 정리해 본다.

   우선, 많이 지적된 사안인 김문수 도지사의 두 번의 119전화의 적절성 여부, 두번째는 그 전화를 받은 두 소방관 대응의 적절성 여부, 세번째로는 그로 인해 비롯된 인사조치의 적절성 여부, 네번째로는 원상복귀의 적절성 여부 및 복귀 과정에서의 김 전지사측 대응의 문제에  관련한 단상을 정리하고자 한다.

  <김문수지사의 첫 번째 119 통화 내역 녹취파일-출처 유튜브>

   첫번째로, 김문수 지사가 119에 전화한 것과 관련하여 그것이 과연 적절했는가에 대한 문제이다. 이는 바로 네티즌들의 공분을 산 바로 그 측면으로서 '김 지사측의 해명처럼 '암환자 긴급수송체계를 문의하고자 하였다면, 왜 도대체 (소방관이 대응한 말마따나) 일반 행정전화를 사용하지 않고 119에 전화를 하여 본인이 김문수라는 말만 반복하고 상대방의 이름만 묻고 끊었을까'하는 것이다. 김 지사를 보호하려는 보수성향의 모 인터넷 신문의 기사에 '119는 일반 민원 전화'라는 웃지 못할 억지 주장이 실리기도 했지만, 엄연히 119는 긴급 전화이다. 소중한 긴급전화 라인을 긴급하지 않은 목적으로 사용한다면 긴급 전화는 왜 만들어 놓는가? 김 지사는 암환자인 지인의 병문안 후 귀가 길에 뜬금없이 긴급전화 119에 전화를 걸어 본인이 김문수라면서 본론을 이야기하지 않은 채 상대방이 관등성명을 대지 않았다고 짜증을 냈고, 김 지사의 첫번째 전화를 받은 소방관은 장난전화로 '오인'을 하고 전화를 끊었다. 이렇게 김문수 지사 본인이 장난전화로 '오인'하게 원인을 제공하였으므로 아주 적절치 못했다고 본다. 그러면서 경기도 소방방재의 통수권을 적절히 행한 것이라고 강변하는 직선 도지사는 유권자들이 현명히 판단하셔서 다음 선거 때 심판하실 일이다.

   두번째로, 두 소방관 대응의 적절성 여부인데, 전술하였다시피, 김문수 지사 본인이 장난전화로 '오인'하게 원인을 제공하였다. 만약 두 소방관은 성실히 근무하고 있었다고 전제한다면, 매뉴얼이고 뭐고를 떠나서 적어도 그 시간에 올지 모를 '긴급한' 전화를 받기 위해서라도, 본인이 경기도 지사라고 주장하며 계속 용건은 이야기하지 않고 이름을 대라고 주장하는 전화 발신자의 전화를 끊거나 발신자 스스로 끊도록 유도하였을 것으로 충분히 생각할 수 있다. 다만 경기도 소방본부 측이 제시한 매뉴얼로 보면 두 소방관은 전화를 받자마자 관등성명부터 대고 용건을 신속하게 접수하여 긴급대응을 진행하여야 했다고 하며, 자의적으로 장난전화 여부를 판단하지 말았어야 했다고 한다. 그 매뉴얼에 의하면 분명 두 소방관은 규정을 어긴 것이며 본인들도 그 점을 인정하고 반성했다. 그러므로 적어도 두 소방관이 복무규정을 어긴 것은 부인할 수 없는 사실일 것이다.

   세번째는 그로부터 발생된 두 소방관의 인사조치과 과연 적절했는가의 문제이다. 이번 논란의 과정에서 '긴급전화에 관등성명부터 대라'는 매뉴얼이 과연 적절한 메뉴얼인가 등의 문제제기가 있었다는 점을 우리는 기억해야 한다. 또한, '자의적인 장난전화 판단 금지' 관련된 규정상의 문제이다. 이 규정은, 장난전화를 직접 받은 소방관이 아닌 다른 누군가가(타의적으로?) 장난전화로 결정해 주어야 장난전화로 대응할 수 있다는 의미의 규정일 것이다. 장난전화가 횡횡하는 119에 용건을 이야기하지 않으며 난데없이 본인이 김문수라고 주장하는 상대방을 자의적이 아닌 주변의 그 누가 장난전화가 아님을 정확히 결정해 줄 수 있을까? 직속상관이? 장난전화 판정 위원회라도 있는가? 경기도 소방본부는 해명자료에서 2009년 남양주에서 119상황실 근무 소방관이 자의적으로 장난전화로 판단하여 한 노인이 동사한 사건을 예로 든 모양이다. 당시 상황은 신고자가 사실을 신고하면서 정확한 위치를 제공하지 못한 것에 대하여 소방관이 (자의적인) 실수로 장난전화라는 판단을 한 것이다. 이번 처럼 용건 조차 이야기하지 않고 본인이 김문수라며 관등성명 대라고 우긴 상황과 전혀 다른 것이다. 이번 건은 자의가 아니라 타의라도 (김문수라는 말에 '쫄지' 않는 한) 장난전화라는 판단을 할 확률이 높을 수 밖에 없지 않을까? 그러므로 전술한 바와 같이 소위 '매뉴얼대로' 대응하지 않은 점이 있다 하더라도 그것이 좌천성 전보발령 수준인가 하는 점에는 동의하기 어렵다. 오히려 소방통수권자의 심기를 불편하게 하여 심기가 불편한 통수권자가 지시를 하였든 소방본부에서 '알아서 기셨든' 지나친 인사였다는 것이 여론이며 나도 그렇다고 본다. 현행 매뉴얼이 지켜지고 있지 않다면 거기에 상응하는 수준의 문책과 교육이면 족하고, 매뉴얼이 문제라면 매뉴얼을 손볼 일이다.

   네번째로, 원상복귀와 관련하여 생각해 볼 점이 있다. 위와 같은 여론에 대하여 김문수 지사측도 수긍을 했는지, 결국 약 일주일 전의 인사를 번복하는 인사를 경기도 소방본부에 지시하셨다고 하는데, 경기도 소방방재본부 인사규정상 인사조치 후 6개월 내 다른 인사조치를 금하고 있다고 하므로 이 원상복귀 지시도 김 도지사의 규정 위반 지시가 되는 것이다. 이러한 과정에서 김 지사 측은 여론 형성 초기에 인사조치에 대하여 알고 있으며 당연하고 정당한 인사조치였음을 강변하다가, 여론이 무르익자 인사조치는 도 소방본부에서 규정에 의거 진행한 것이며 김 지사 본인은 모르고 있었다는 등의 말을 바꾸어 나가는 모습을 보여 주다가 결국 또다시 규정을 무시한 원상복귀 인사를 지시하는 악수를 거듭하고야 만 것이다. 의사 결정이 여론의 향배에 따라 참 빠르기는 하나, 진중한 면이 없다. 규정에 대한 고려도 찾아 볼 길이 없다. 여러 가지로 법치국가의 직선제 수장이 보여주어서는 안될 모습을 유권자들께 보여 주고 있는 것이다.



         <김문수 도지사 119전화 관련 한 네티즌의 비판적인 패러디 게시물-원본 출처 불명>

    앞서 언급한 것처럼 결국 (원상복귀 되었으므로) 해프닝이 되어버린 이번 사건에서 우리는 잠재적인 한 피선거권자의 자질의 일부를 볼 수 있었다. 많은 유권자들의 참고가 되었을 것이다. 또한 '긴급 전화' 근무자의 대응 매뉴얼에 불합리한 측면이 존재하고 있었다는 것도 세상에 알려지게 되었다. 각 광역자치단체 소방당국자 분들께서는 이번 '해프닝'을 더욱 합리적인 대응 매뉴얼로 다듬는 기회로 활용하셨으면 좋겠다. 무엇보다도, 이번 해프닝이 해피엔딩으로 끝나가는 것 같아 기쁘다. 모쪼록, 새해에도 두 소방관님과 그 가족분들과 그리고 김 도지사님의 행복과 건강을 빈다. Happy New Year!

Posted by truerain
l

오늘 모처럼 한가로이 인터넷 뉴스를 보고 있는데, 연비 관련 기사(ⓒ한겨레)가 하나 보였다. 이 기사에 의하면 기아차 2010형 모닝 1.0 수동 모델이 연비 21.2Km로 1위라고 지경부에서 발표했단다. 상기 차종은 자동모델 중에서도 연비 18.0Km로 최고(전체3위)란다. 물론 올해 상반기에 나온 차량들 이야기지만, 4년 된 우리 집 모닝도 정말 자~알 나간다. ㅋ

 

주초부터 충남 천안시 병천면(병천순대의 그 병천 맞다.)에 소재한 한국기술교육대학교(이하 한기대)로 집체 연수교육을 매 평일마다 9시부터 18시까지 들으러 다니고 있다.

한기대에서 생활관(기숙사)를 제공(유료)하는데, 최신식 시설로 지어져서 정말 좋다고 동기 선생님들이 전한다. 그러나 가족들이나 나나 서로 떨어져 지내고 싶지 않고, 서진이를 위해서도 아빠가 함께 있는 게 좋을 것 같아서 왕복 200 Km가 넘는 거리를 출퇴근하기로 결심하였다.

지각해도 연수 성적에 감점이 되기 때문에 아침에 피말리면서 운전해 가고 있는데, 가속페달도 정말 세게 밟게 된다. 그러면서 한쪽 뇌는 항상 ‘아, 기름 값…’.

출퇴근 하시는 동료 분들이 몇 분 계시는 것으로 아는데, 아마도 수도권 등 원거리에서 승용차로 다니시는 분은 아마 나 말고 없는 듯 하다.  내가 이렇게 무리하게라도 다닐 수 있는 것은 그나마 모닝이라는 경차가 있기 때문이다.

지난 일주일간의 톨비, 주유금액 등을 오늘 온라인 차계부에 정리하면서, 자동 계산된 연비를 확인해 보니, 최근 연비가 리터당 17.5Km가 조금 넘게 나왔다. 만약 서진엄마가 모닝을 가지고 다니고, 내가 스펙트라를 천안에 가지고 다녔다면, 약 10Km의 연비가 예상되므로 주유비용이 1.7배 이상 늘었을 것이다. 게다가 톨게이트비용도 50%할인이 안되므로 매일 2배를 내야 했을 것이다.

이렇게 길에서 하루 3시간 이상 운전하느라 시간도 버리고 생활관에 있는 것 보다 비용도 좀 더 들고 몸도 고달프지만, 생활관 비용보다 조금 더 들여서 사랑하는 가족들과 함께 저녁 식사를 하면서 시간을 보낼 수 있기에, 오늘 모닝에게 감사한다.

모닝아, 내 비록 최악의 승차감이라고 매일 투덜대지만, 경제성은 네가 정말 최고야~.

아, 그런데 1가구 1경차 조건에 못 들어가서, 모닝 유류세 경감 혜택을 못받는 건 참 아쉽네. 헐

P.S.) 이 글은 개인 블로그 및 가족 팀블로그에 동시 게재됨.

Posted by truerain
l

파란메일이 2010년 4월 15일 부로 IMAP 메일 서비스 모든 파란메일 사용자에게 개방한 것으로 보인다.

파란메일 측은 아래와 같은 공지를 사이트에 올려 두었다.

아이폰으로 대표되는 스마트폰의 거대한 물결을 새삼 느끼게 된다. 불과 지난해 하반기까지도 네이버, 다음 등 국내 대표 포탈 서비스들이 제공하는 메일서비스는 자사 페이지 뷰를 유지하기 위해 웹메일 접속만을 허용해 왔다. 그리고 일부 사용자들에게는 유료로나마 POP3 프로토콜에 의한 서비스를 제공하여 Outlook Express, Thunderbird 등의 메일클라이언트 접속을 제한적으로나마 제공해 왔다. 그러나 한국도 스마트폰의 빗장이 열리면서 PC/노트북 뿐 아니라, Wi-Fi에 연결된 스마트폰들 또한 메일클라이언트의 역할을 담당하게 되면서, 이제 메일은 컴퓨터를 켜야만 볼 수 있는 것이 아니라, 스마트폰이 Wi-Fi망에 연결되어 있다면 메일 수신 여부를 일정 시간 간격으로 확인하여 마치 문자메세지가 도착하였음을 알려 주듯이 사용자에게 알려 주므로, 거의 실시간에 가깝게 휴대폰을 통해 메일을 주고 받을 수 있는 시대가 도래한 것이다.

이러한 메일 환경의 변화는 IMAP4라는 통신규약(프로토콜)이 있기에 가능해 진다. POP3 프로토콜은 메일 클라이언트가 메일 서버의 메일들을 무조건 긁어오기만 할뿐인데 비해 IMAP프로토콜은 메일 서버의 메일뿐 아니라 메일박스 구조까지 분석하여 클라이언트의 메일 및 메일박스(폴더)들을 동기화 시킨다. 그러한 이유로  사용자가 데스크탑, 넷북/노트북, 스마트폰 등의 2~3개의 메일 클라이언트를 가동시켜도 IMAP메일 서비스는 이 모든 장치들의 받은 메일들을 동기화 하여 사용할 수 있다.  스마트폰이 제대로 ‘스마트’하기 위한 선행 조건 쯤 되는 것이랄까?

전 세계적으로 스마트폰이 활성화 되기도 훨씬 이전부터, 구글은 자사의 Gmail 서비스를 통해 선도적이고 혁신적인 성과들을 이루어냈다. 한국의 포탈들이 페이지뷰라는 프레임에 묶겨 웹메일만을 고집하고 있을 때, 구글은 POP3 서비스, 자유로운 메일 Forwarding 등 남들이 꺼리는 서비스들을 무료로 풀더니, 급기야 일찌감치 IMAP4 서비스를  무료로 지원한 바 있다. (다만, 한국의 사용자들은 일부 표준을 지키지 않는 메일서버들이 뿌리는 메일을 IMAP으로 볼 때 인코딩 문제가 발생하는 경우가 있다.)

이렇게 GMail의 혁신이 성공하고 있음에도, 그간 우리 포털들은 꿈쩍도 않더니, 지난해 하반기부터 몰아친 스마트폰의 열풍으로 인해 서서히 변화를 받아들이기 시작한다. 네이버와 다음이 지난해 하반기와 올해 초에 각각 POP3와 IMAP4서비스를 모든 사용자에게 공개하였고, 후발주자 파란이 지난 2월 POP3를 풀더니, 엇그제 드디어 IMAP4 서비스를 개방한 것이다.

개인적으로는 네이버와 다음의 메일 ID는 원하는 ID를 선점당하여 다른 ID를 사용하여야 하는 아픔이 있으나, 파란의 경우 하이텔-한미르 통합 때 원하는 ID를 선점하여 사용 중이다. 그러나 공룡 KT의 그닥 ‘땡기지 않는’ 서비스들로 인해 파란메일을 잘 사용하지 않고 있었는데 최근의 파란서비스(특히 메일)들이 많이 좋아지는 것 같아서 파란을 많이 사용하는 것도 괜찮을 듯 싶다.

아기자기하게 파란메일 포인트 모아서 5Giga 용량과 SMS 추가 무료 서비스를 함 받아 봐?

Posted by truerain
l

얼마 전부터 내 개인 컴퓨터를 켜서 주로 사용하는 윈도우즈 운영체제를 부팅시키면 SK커뮤니케이션즈(이하 SK컴즈)가 운영하는 포탈사이트 네이트(www.nate.com)의 홈페이지가 기본 웹브라우저를 통해 화면에 뜨기 시작했다. 처음에는 내가 부팅하면서 뭘 잘못 건드렸나 싶어 브라우저 종료 버튼을 누르기를 몇 차례… 이건 뭔가 아닌 듯 싶었다. 찬찬히 이유를 살펴보니, 범인은 SK컴즈의  ‘Killer Application’인 인터넷 메신저(이하 IM) 네이트온이었다.

필자는 윈도우즈 로그인할 때마다 네이트온을 구동시켜 로그인하기보다는 윈도우즈 시작과 동시에 자동접속으로 실행되게끔 해 놓았다. 평소 지나치게 높은 (그리고 거의 강제적인) 광고 노출로 인해 매우 쓰기 싫지만, 워낙 주변 사람들의 높은 사용률 때문에 어쩔 수 없이 쓰게 된다는 IM 네이트온을, 필자 또한 그렇게 쓰고 있었다. 로그인 하면 무차별적으로 쏟아지는 뉴스온, 핫클립 등의 쓰레기 팝업창들을 불쾌한 마음으로 ‘환경설정’ 메뉴를 통해 자동으로 뜨지 않도록 해 놓아도, 네이트온에 접속할 때마다 윈도우즈 오른 쪽 아래 시계 근처의 ‘알림영역’ 위로 불끈불끈 지겹도록 솟아오르는 광고와 모니터 화면 정 중앙에 떡하니 뜨는 광고창은 그 어떤 ‘환경 설정’으로도 막을 수 없었다. 로그인 후 떡하니 화면 정 중앙에 뜨는 광고창 하단에는 다음부터 이 광고 보지 않는다는 취지의 옵션 버튼이 항상 달려 있는데, 그 옵션을 켜고 그 창을 닫아도 다음 날이면 다시 정중앙 광고창이 어김없이 등장해 사용자의 속을 뒤집어 놓았다. 이건 뭐 광고가 ‘불멸의 이순신’이야?

그런 '불멸의 광고’를 감수하며, 그래도 주변 사람들과의 ‘커뮤니케이션’을 위해서 억지로 쓰고 있었는데, 최근 이 네이트온은 나와 같은 사용자들의 화를 돋우는 ‘걸작’ 업데이트를 선보였다. 핫클립 자동 실행을 꺼 놓은 사용자들은 이 업데이트( Ver. 4.0.9.8 build 1437)를 설치한 후부터 네이트온에 로그인 하는 순간, 본인이 구동하지도 않은 웹브라우저의 새 창이 열리면서 본인이 원하지 않은 네이트 메인페이지가 네이트온 계정으로 로그인한 상태로 화면에 뜨는 것을 지켜 봐야만 한다. (아니면 핫클립을 보던지…)

필자는 여기까지는 SK컴즈 측을 이해했다. 그래… 최근 엠파스 등의 합병으로 몸집을 부풀린 후, ‘포털 페이지 뷰’에서 <다음>을 확실한 3위로 밀어내 2위를 공고히 하고, 나아가 <네이버>를 추월하여 1위에 등극할 ‘사명(使命)’이 SK컴즈 임직원들에게는 있지…그래서 지극히 ‘당연히 있어야 하는’ 환경설정의 ‘로그인 시 네이트 메인 페이지 않보기’ 옵션을 찾아 보았다.

그런데… 없다.

‘환경설정’을 아무리 뒤져 보아도 ‘로그인 시 보기 설정’이라는 환경 설정 항목의 선택버튼에는 ‘네이트 메인 보기’와 ‘핫클립 보기’ 만이 있다. (하단 그림 참조)

 

필자는 그래도 혹시 이것이 SK컴즈 측의 ‘의도되지 않은 실수’일 수 있다는 판단하에 관련 사항을 구글링하기 시작했다.

그런데, 아래의 연결과 같은 인터넷 기사가 튀어 나왔다.

네이트온으로 네이트 트래픽 유도 논란 (2010년 04월 07일 15:46:48 / 이민형 기자 (디지털데일리)

아, 그렇구나, 명백히 SK컴즈 측의 노림수로구나…. 대한민국 국민 3천만 명이 사용한다는 ‘국민 어플’ 네이트온이 회사 페이지 뷰를 올려 주기 위한 ‘시녀 어플’로 전락하는 순간이다. 동시에 필자에게는, 광고 창을 앞으로 보여주지 않겠다며 계속 보여주고, 네이트 메인이든 핫클립이든 강제로 보는 건 싫다는 사용자에게 ‘안돼, 무조건 화면 띄울 테니 네가 알아서 매번 꺼’라고 하고 있는 이 ‘저렴한’ 어플을 ‘Junk IM (쓰레기 인터넷 메신저)’로 규정할 수 밖에 없는 순간이다.

이제 필자, 그리고 필자와 같은 생각을 하는 여러 사용자들은 어떤 선택을 해야 하는 걸까?

우선 네이트온의 대안 프로그램을 찾으려 한다. 이 세상에는 다양한 IM들이 경쟁하며 발전하고 있다. 온 누리로 보면 Windows Live Messenger가 시장 우위에 있고 AOL의 AIM, 야후의 야후!메신저, 구글의 Google Talk 등도 자사의 다른 서비스들과 연계해 IM을 제공하고 있다. 그러고 보니 Skype도 있다. 지인들이 네이트온만 쓴다고? 그럼 ‘통합 메신저’라는 것을 고려해 보자. 최근 리눅스 진영에서 각광을 받고 있지만 윈도우즈용도 있는 Pidgin이라는 IM이 있고, Apple Mac 전용이지만 Adium이라는 것도 있으며 웹서비스형 IM인 Meebo도 있다. Pidgin의 경우 네이트온 플러그인이 이한선 님에 의해 개발되어져 제공되고 있다. 다만, 이러한 통합 메신저는 파일전송, 문자 메세지 등 네이트온이 사용자의 발목을 잡고 있는 기능들을 구현하지는 못한다. 그러나 강제 광고창 안보고 내 어플을 내 맘대로 제어하고 싶다면 선택할 만 할 것이다.

                                       

위의 연결된 기사의 SK컴즈 측 대응에서 보듯, 만약 사용자의 저항이 거세지면, 아마 향후의 업데이트에서 네이트 메인 혹은 핫클립을  무조건 봐야 하는 바보 짓을 안하도록 환경 설정을 꾸며 놓는 후퇴도 할 수 있을 것이다. 그러나 그것도 오래 가지 않을 것이라고 필자는 확신한다. 네이트온은 대한민국 3천만 명이 그들의 커뮤니케이션 수단으로 목 매달고 있는, 적어도 한국 시장에서의 독점 어플이다. 운영체제에서의 Windows의 한국에서의 지위와 다를 바 없다. 이번 사태는 SK컴즈 입장에서는 그런 네이트온의 지위를 충분히 활용해 본 것 뿐이며, 일단은 소기의 목표인 네이트 메인페이지 뷰의 증가를 달성하면서 본인들이 밀어붙인 상황에 대하여 사용자의 반응을 보고 있는 중일 뿐이다.

거칠게 말해서, 여기서 욕 좀 먹어도 네이트 페이지 뷰 점유율 올라가고, 네이트온 점유율도 크게 떨어지지 않는다면, SK컴즈 임직원 성과도 올라가는 거다. 님도 보고 뽕도 따고…. SK컴즈 임직원들은 이미 사용자 모니터에 광고를 ‘처발라도’ 대한민국 사용자들이 이를 인내하면서 멍청하게 계속 사용한다는 걸 배웠다. 멋대로 자기들 페이지를 사용자 모니터에 띄우는 개짓은 멈추더라도, 이 무례한 독점 사업자의 또 다른 ‘도발’은 언제 어디서든 계속될 것이다.

자, 이제 제어판을 띄워 네이트온 IM 프로그램을 설치제거하고, 통합 메신저 중 맘에 드는 것 하나와 네이트온 플러그인을 설치해 보자. 그리고 네이트온 망에 접속하여 지인들과 네이트온의 폐혜에 대하여 이야기 해보고, 그 지인과의 메세징은 다른 사업자의 프로토콜을 이용해 보기로 하자.(이왕이면 통합 메신저들이 기본적으로 지원하는 글로벌한 프로토콜이 좋겠다.) 그렇게 조금씩이라도 저 철옹성을 허물어 보아야 저 오만한 사업자가 사용자들을 존중하는 척이라도 하지 않겠나? 웹 브라우저가 쓰레기 같은 Active X로 처발려지고, 뭐 같지도 않은 IM때문에 바탕화면이 ‘불멸의’ 광고와 멋대로 뜨는 홈페이지로 떡칠이 되는 상황을 언제까지 참고 있어야 하나?

'셈틀 이야기' 카테고리의 다른 글

파란메일, IMAP 서비스 무료 제공 개시  (0) 2010.04.17
Posted by truerain
l