오늘 사무실 MacOS를 El Capitan에서 Sierra로 업그레이드  했습니다.  Sierra에서는 Mac용 Siri를 사용할 수 있다는군요.  뭐 사무실 컴퓨터에는 어차피 마이크도 없고...  사무실에서 시리와 이야기 하느니 차라리 사무실 벽을보고 이야기 하겠다는 잡스러운 생각을 하면서 약 15분간의 업그레이드 시간을 기다렸습니다.

   업그레이드를 완료한 Sierra의 모습...은 아름다웠지만,  뭔가 거추장스럽고 끈적끈적한 증상이 기다리고 있었습니다.  바로 네트워크 윈도우 공유 폴더에 접근할때마다 사용자 이름과 암호를 매번 물어보는 증상이었는데요.  아래 그림처럼 말이죠...

네트워크 서버 암호 확인 창

 

그전  El Capitan까지만 해도 Apple Script 편집기로

1
mount volume "smb://192.168.0.2/Share" 
cs

와 같은 내용을 넣고 스크립트 실행파일을 만들어 주고 로그인 시에 시동되는 프로그램으로 등록해 주면,  /Volumes 폴더에 해당 마운트지점(/Volumes/Share)이 자동 생성되고 여기에 마운트가 가능했습니다.  물론 사용자 이름과 비밀번호는 처음 한 번 입력해 주면 키체인에 저장되어 다시 입력할 이유가 없었죠.  저처럼 로그인 자동실행까지는 아니어도 위와 같은 명령이나 GUI로 윈도우 공유폴더를 마운트 해 쓰시던 분들이 많을 겁니다.

    '왜 이러지?'하며 열심히 구글링을 해 보니, 애플 개발자 포럼인가 하는 커뮤니티에 이르기를...  '애플이 MacOS 10.12 Sierra부터 일반사용자의 /Volumes  마운트를 막는 정책을 써서 그런 현상이 있다'네요.  그 해결책(workaround)으로 '사용자의 홈폴더 밑에 마운트지점을 만들고 여기에 마운트를 해서 쓰라'는 권고를 해 주네요.

    하지만,  저는 소시적에 리눅스를 만지면서 수세리눅스 데스크톱 제 홈폴더에 네트워크 공유폴더를 마운트 해서 쓰다가...  나중에  홈폴더의 설정이 꼬여서 열받은 나머지 아래와 같은 명령어를 날린 적이 있습니다.

(아래 명령어는 절대로 아무 생각없이 복사해서 배시 셀에 붙여넣기 하고 엔터를 누르면 안됩니다!!!)

1
$ rm -rf ~/*
cs

   이런 짓을 하는 것은 남들의 경험담에서만 보는 건 줄로만 알고 있었는데... ㅠㅠ 그 후로 오랫동안 충격에서 헤어나지 못하다가,  공유폴더의 자료들을 어느  정도 다시 모은 후에는 리눅스의 시스템 쪽 폴더  (/mnt  랄지  /media  같은...)  아래에 제 마운트 포인트를 만들고 제 홈폴더 밑에는 마운트 포인트로 가는 소프트링크를 걸어  놓고 사용하는 것을 철칙으로 하게 되었습니다.  (이제는 제 사용자 계정으로 홈폴더에서 무슨 망나니같은 짓을 해도 최소한 소중한 자료가 모여 있는 네트워크 폴더들은 무사하도록  해 놓은 것이죠.

     MacOS도 예외일 수는 없습니다.  그동안에는 mount volume  옵션 명령으로 시스템 폴더인 /volumes폴더를 사용해 왔다면 이제는 굳이  (애플이 원하지 않는)  /Volumes 폴더를 마운트포인트로 쓸 것이 아니라, 홈폴더 쪽이 아니더라도 다른 폴더를 만들어서  제 목적을 달성하면 되겠지요.  그런데 Mac에서 쓸  일이 없는 폴더이름을 만들어야 겠습니다.  나중에 혼동되지 않으려면요...

    그래서 /Mount 라는 폴더를 한번 만들어 봅니다. 유닉스/리눅스에서라면 /mnt가 있는데, 맥에서는 현재 활성화되지 않아서 동일한 이름을 만들어 쓰면 될 것 같지만, 혹시 몰라서 이 이름은 피하는 게 좋을 것 같았습니다. 그 /Mount 폴더 아래에 제가 공유폴더로 쓰는  폴더들의 이름으로 하위폴더들을 만들어 줍니다.  그 중 하나의 이름이 'Share'라면 아래와 같겠지요. 한꺼번에 아래와 같이 만들어도 되겠네요. 터미널을 열고 아래와 같이 작업합니다.

1
$ sudo mkdir -p /Mount/Share
cs

그리고 ' Share'폴더의 소유권을 내 것으로 바꿔 줍니다.

1
sudo chown 내계정명:Staff /Mount/Share
cs


이제 홈폴더 밑에 소프트링트들을 저장할 폴더 하나를 만들어 줍니다.

1
$ mkdir ~/Netfolder
cs

Netfolder로 들어가서 위에서 만들어 놓은 'Share'폴더로 향하는 소프트 링크를 만들어 줍니다.  (제 경우는 /Volumes/Share 폴더로 향하던 소프트링크 파일을 삭제하고 새로 만들어야죠.)

1
$ ln -s ../../../Mount/Share Share
cs

이제 아래와 같은 명령어로 네트워크 공유폴더를 마운트합니다.

1
$ mount -t smbfs //사용자이름:비밀번호@서버주소/Share
cs

위에서 언급한 바와 같이 애플이 더  이상 시스템폴더 마운트포인트에 네트워크 공유 암호를 키체인에서 자동으로 불러 들이는 것을 허용하지 않기 때문에,  시스템폴더 쪽을 마운트포인트로 쓰면서도 사용자 이름과 암호를 계속 물어보는 현상을 해결하는 방법으로는 위와 같은 명령을 스크립트로 만들어서 쓸 수 밖에 없는 것 같습니다. 여기서 사용자이름과 비밀번호는 우리 네트워크 공유폴더의 사용자이름과 비밀번호입니다.

'Launchpad-기타'에 있는 '스크립트 편집기'를 실행합니다.

1
2
3
try
    do shell script "mount -t smbfs //사용자이름:비밀번호@서버주소/Share /Mount/Share"
end try
cs

라고 입력하고 이름을 'Mount Net Folder'로 바꿔 준 뒤 저장해 줍니다.

이 스크립트 파일을 실행파일로 전환해 주기 위해 상단 메뉴어서 '파일-보내기'를 선택합니다.

보내기 대화창이 열리면  아래 그림과 같이 '다음으로 보내기' 옆에 'Mount Net Folder'라는 이름을 확인하고 아랫쪽 '응용프로그램'  폴더를 저장폴더로 하고 '파일포멧'은  '응용프로그램'으로 선택해 주시고,  '실행전용'란에 체크표시해 주고 저장을 눌러 줍니다. 아래 그림을 참조하시면 되겠습니다.

애플스크립트 보내기 창의 확장

 

이제 응용프로그램 폴더에 우리가 만든 'Mount Net Folder' 앱이 생겼습니다.  이 녀석을 로그인 시 자동 실행되도록 해 봅시다.

바탕화면 아래 독에 '시스템 환경설정'을 엽니다.  '사용자 및 그룹'을 선택하시고  현재 사용자가 본인의 사용자 계정임을 확인하시고 오른쪽의 '로그인 항목'을 클릭합니다.

창 아랫쪽 자물쇠 버튼을  눌러 잠금 해제를 해준 후, '+'를 눌러 우리가 만들어 준 'Mount Net Folder' 앱을 등록시켜 줍니다.

이제 재부팅하여 네트워크 폴더가 사용자이름,  암호를  물어보지 않고 잘 마운트 되는지, 링크는  제대로 연결되어 있는지 확인합니다. 특별한 문제가 없다면 이제 부팅하여 로그인할 때마다 우리 네트워크폴더는 자동으로 마운트 될 것입니다.


참고

   암호에 특수문자 (e.g. &, #)가 포함되어 있는 경우  'URL Encoded Characters'로 변환해 주어야 정상적으로 마운트 됩니다.  예를 들어 암호가 123$56&8인 경우 아래와 같이 스크립트를 만들어 주어야 합니다.

1
2
3
try
    do shell script "mount -t smbfs //사용자이름:123%2456%268@서버주소/Share /Mount/Share"
end try
cs

Posted by truerain
l

   지난 토요일에 가을 주말을 맞아 처형네 부부가 저희 집에 와서 저희 가족과 함께 인근 갯골 생태공원에 가을 나들이를 갔습니다. 지난 주말 만큼만 날씨가 화창했으면 좋았겠지만, 어제 짙게 드리워져 있던 미세먼지가 조금은 남아 있어, 약간은 뿌연 느낌이 나는 토요일이었습니다. 정오 무렵에 도착해서인지 아직 사람과 차가 많지는 않았습니다. 주차장 옆에 있는 잔디운동장 한 켠에는 다음주 화요일에 녹화를 진행한다는 KBS 열린음악회의 무대로 보이는 설치 공사가 한창 진행 중이었습니다.

   간단하게 싸간 점심 식사를 마치고 산책에 나섰습니다. 가을 햇살은 따스했고 걸으면 약간은 이마에 땀방울이 맺히는 그런 날씨였습니다.

 

   이런 조형물들은 아이들이 타고 놀기 좋아하는 것들인데 아직 한산하네요.

 

   염전체험과 소금창고를 둘러 볼 수 있는 곳도 있습니다. 이 곳이 예전에는 갯벌지역으로서 염전이 있었다고 하네요. 아래 사진 오른쪽 중간 쯤에 스크류 원통 모양의 구조물이 보이시나요? 바로 공원 전망대라고 합니다. 오늘 산책의 목적지는 저 곳입니다.

 

   옛 갯벌의 흔적을 느낄 수 있는 곳도 남아 있습니다. 마치 바닥을 드러낸 강 같군요.

 

   이런 산책로도 만들어 놓았네요. 나무만 더 우거지면 드라마나 영화 촬영 장소로도 손색 없을 것 같습니다.

 

   생각보다 꽤 넓군요. 헥헥…

 

   드디어 목적지인 전망대가 눈앞에 있습니다. 그런데 사진을 삐뚜루 찍었나? 피사의 사탑처럼 기울어져 보이네…?

 

   전망대 부근에서 드넓게 펼쳐진 갈대밭과 그 너머에 보이는 인천 쪽을 사진에 담아 봤습니다.

 

   전망대 지층(1층)에는 이런 큐브 모양의 작품이 전시되어 있네요.

 

   꼭대기에 올라가 보이는 전망을 사진에 담습니다. 인천 쪽이구요…

 

   장곡동, 장현동 방면…

 

   아까 사진에 담았던 염전 체험장과 소금창고 전경입니다. 앞쪽으로 여름에 수영장으로 쓰이는 곳도 눈에 들어 오네요.

 

   잔디공원 옆으로 흐르는 갯벌이 마치 강물 같습니다.

 

   일행이 있는 곳으로 돌아오면서 눈에 띈 물고기 조형물 사진을 한 컷 더 찍어 봤습니다. 안녕~ 물고기야. 난 이제 아들과 야구놀이, 배드민턴 놀이 하러 가야 한단다. 나중에 또 보자,

Posted by truerain
l

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