728x90

VPN 서버를 로컬에서 운영해야 하는 이유는 (굳이 찾자면) 여러가지가 있겠습니다만, 개인적으로는 OpenVPN Web UI 의 커스터마이징을 위하여 개발 환경이 필요했던 관계로 설치를 하게 되었습니다. 리눅스 환경에서의 설치는 종종 해왔지만 막상 로컬 Mac 환경에 설치하려니 적당한 가이드가 없는 것 같아 시행착오를 하며 내용을 정리해 봅니다. 


Homebrew 를 이용한 패키지 설치

OpenVPN 커뮤니티 버전의 소스를 다운로드 받아 빌드를 할까? 하는 생각을 0.1 초간 한 뒤에 바로 Homebrew 로 돌아섰습니다. 안그래도 지저분한 로컬 환경이라 (도커에 익숙치가 않네요) 더 지저분하게 하지 말자는 생각이 있었고, 빌드 환경 설정에 시간을 쓰지 말자는 생각이 들어 Homebrew 를 사용해 봤습니다. 

% brew install openvpn
Updating Homebrew...
==> Auto-updated Homebrew!
Updated 3 taps (homebrew/core, homebrew/cask and homebrew/services).
...
...
==> Installing dependencies for openvpn: lz4, openssl@1.1 and pkcs11-helper
==> Installing openvpn dependency: lz4
==> Pouring lz4-1.9.3.catalina.bottle.tar.gz
🍺  /usr/local/Cellar/lz4/1.9.3: 22 files, 657.6KB
==> Installing openvpn dependency: openssl@1.1
==> Pouring openssl@1.1-1.1.1h.catalina.bottle.tar.gz
==> Caveats
...
...

 

매번 느끼는 거지만 Homebrew 는 업데이트가 너무 많습니다. 따로 패키지만 올리고 싶어도 일단 필요한 것들을 다 업데이트 하고 시작하니 시간이 꽤 걸립니다. 한참을 지나 OpenVPN 설치를 위해 Dependency 가 있는 패키지들을 쭈욱~ 설치해 나갑니다. 중간에 몇 가지 심볼릭링크 작업이 에러가 나는게 보였지만... 잘 되리라 믿고 진행을 계속 했습니다. 한 15분정도 걸렸던 것 같네요.

 

OpenVPN 바이너리는 어디에!?

리눅스 환경에서는 패키지로 공급되는 프로그램들은 대부분 데몬 설정 파일도 같이 올려주고 systemctl 이나 services 명령으로 활성화, 비활성화를 쉽게 할 수 있습니다. 막상 Mac 환경에서는 그렇게 쓰는 경우가 잘 없다보니... 설치후에 무얼 해야하나 5분정도 멍을 때렸습니다. 이단 설치경로를 찾아보기로 했고 아래의 경로에서 OpenVPN 을 찾을 수 있었습니다. 

% pwd
/usr/local/opt/openvpn

% cd sbin
% ls -al
total 1440
drwxr-xr-x   3 xxx  yyy      96 10 28 16:25 .
drwxr-xr-x  17 xxx  yyy     544 12  1 12:36 ..
-r-xr-xr-x   1 xxx  yyy  735160 12  1 12:36 openvpn

그런데 설정 파일은 어디에 있는걸까요?

 

OpenVPN 설정파일은 여기에!!

OpenVPN 이 설치되고나면 설정파일은 아래의 경로에서 찾아볼 수 있습니다. client.conf 는 VPN 의 클라이언트가 될 머신에서 사용하는 파일이고 server.conf 는 VPN 서버에서 사용하는 파일입니다. 리눅스에서도 그랬었나 기억이 좀 가물거립니다만 친절한 안내 멘트가 같이 들어 있으니 익숙하지 않은 경우에는 내용을 하나씩 살펴보는 것을 추천드립니다. (라고 적으면서 저도 잘 모르는 내용이 많긴 합니다만... ㅎ)

% cd /usr/local/etc/openvpn
% ls -al
total 32
drwxr-xr-x   4 xxx  admin    128 12  1 12:36 .
drwxrwxr-x  20 xxx  admin    640 12  1 12:46 ..
-rw-r--r--   1 xxx  admin   3589 12  1 12:36 client.conf
-rw-r--r--   1 xxx  admin  10784 12  1 12:36 server.conf

 

우리는 성미가 급하니 OpenVPN 이 동작하는지 한번 보겠습니다. 느낌적 느낌으로 인지하셨겠지만 당연히 동작하지 않습니다 ㅎㅎ. 필요한 키생성 등을 해야 하지만 그래도 한번 실행해 보는 맛이 있어야겠죠?

% /usr/local/opt/openvpn/sbin/openvpn --config ./server.conf
2020-12-01 13:06:17 WARNING: --topology net30 support for server configs with IPv4 pools will be removed in a future release. Please migrate to --topology subnet as soon as possible.
2020-12-01 13:06:17 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning.
2020-12-01 13:06:17 Cannot pre-load tls-auth keyfile (ta.key)
2020-12-01 13:06:17 Exiting due to fatal error

네, 그렇습니다. 치명적인 에러가 있어서 실행이 안되었네요 ㅎㅎ DEPRECATED 로 표시된 부분은 server.conf 를 열어서 AES-256-CBC 로 된 부분을 AES-256-GCM 으로 변경해주시면 됩니다. 자, 그러면 tls-auth 를 위한 ta.key 파일을 생성해 보겠습니다

 

각종 Key 생성하기

우선 OpenVPN 용 Static Key 를 만들겠습니다. tls-auth 용 키이며 ta.key 파일을 만들어야 하는데요,  생성하는 것은 간단합니다. OpenVPN 바이너리에서 옵션을 지정하여 키를 생성할 수 있습니다. Configuration 파일이 위치한 경로에 ta.key 파일도 만들어 보도록 하겠습니다. 

% /usr/local/opt/openvpn/sbin/openvpn --genkey tls-auth ta.key
% cat ta.key
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
9b61ceee61da49815108d6703e722d22
3c0f98a075c5476a3189c394274bedb3
...
...
535613076cde018b76a098bd48fbde83
ba2a1259d8df458b15c6f521b7ae0c57
-----END OpenVPN Static key V1----

사용자와 PKI 연결 설정에 사용할 인증서 파일도 생성해 보도록 하겠습니다. 인증서 파일 생성을 하는 방법은 여러가지이지만 easyrsa 를 사용해 보도록 하겠습니다. Dependency 설치시에 같이 설치가 되지 않았던 것 같아 Homebrew 로 설치해 주었습니다. 

% brew install easy-rsa
...
% brew --prefix easy-rsa
/usr/local/opt/easy-rsa

이제 easyrsa 를 이용하여 PKI 를 구성하기 위한 루트 인증서, 비밀키, 공개키 등을 만들도록 하겠습니다. 참고로, easyrsa 는 기본 값으로 /usr/local/etc/pki 경로에 파일들을 생성하도록 되어 있으니 참고하시기 바랍니다. 

//===============================
// 초기화
//===============================
% /usr/local/opt/easy-rsa/bin/easyrsa init-pki

init-pki complete; you may now create a CA or requests.
Your newly created PKI dir is: /usr/local/etc/pki

//===============================
// CA Certificate 생성
//===============================
% /usr/local/opt/easy-rsa/bin/easyrsa build-ca nopass
Using SSL: /usr/local/opt/openssl@1.1/bin/openssl OpenSSL 1.1.1h  22 Sep 2020
Generating RSA private key, 2048 bit long modulus (2 primes)
..........................................................................................................................................+++++
..............................................................................................+++++
e is 65537 (0x010001)
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Common Name (eg: your user, host, or server name) [Easy-RSA CA]:MyLocalPKI

CA creation complete and you may now import and sign cert requests.
Your new CA certificate file for publishing is at:
/usr/local/etc/pki/ca.crt

//===============================
// 서버인증서 생성
//===============================
% /usr/local/opt/easy-rsa/bin/easyrsa build-server-full server nopass
Using SSL: /usr/local/opt/openssl@1.1/bin/openssl OpenSSL 1.1.1h  22 Sep 2020
Generating a RSA private key
..............................................................+++++
...................................................................................................................................+++++
writing new private key to '/usr/local/etc/pki/easy-rsa-38744.0yXv0x/tmp.Xb7eac'
-----
Using configuration from /usr/local/etc/pki/easy-rsa-38744.0yXv0x/tmp.VwN7Lb
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
commonName            :ASN.1 12:'server'
Certificate is to be certified until Mar  6 04:45:50 2023 GMT (825 days)

Write out database with 1 new entries
Data Base Updated

//===============================
// 키 교환 알고리즘용 DH 파라메터 생성
//===============================
% /usr/local/opt/easy-rsa/bin/easyrsa gen-dh
Using SSL: /usr/local/opt/openssl@1.1/bin/openssl OpenSSL 1.1.1h  22 Sep 2020
Generating DH parameters, 2048 bit long safe prime, generator 2
This is going to take a long time
...............................................................................+....................................+......................................
DH parameters of size 2048 created at /usr/local/etc/pki/dh.pem


//===============================
// Client 용 Credential 생성
//===============================
% /usr/local/opt/easy-rsa/bin/easyrsa build-client-full mylocalclient nopass
Using SSL: /usr/local/opt/openssl@1.1/bin/openssl OpenSSL 1.1.1h  22 Sep 2020
Generating a RSA private key
...................................................................................................................................................................+++++
..+++++
writing new private key to '/usr/local/etc/pki/easy-rsa-65143.eROtDW/tmp.haeAUt'
-----
Using configuration from /usr/local/etc/pki/easy-rsa-65143.eROtDW/tmp.EOABaH
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
commonName            :ASN.1 12:'mylocalclient'
Certificate is to be certified until Mar  6 05:03:20 2023 GMT (825 days)

Write out database with 1 new entries
Data Base Updated

뭔가 번잡하니 많네요. 하지만 늘 하던 일이었다고 생각하시고 하나씩 따라오셨으면 특별히 문제 없었을 겁니다. 이제 생성된 파일들이 어디에 있는지 체크해 볼까요?

// 서버 인증서와 클라이언트 인증서
% pwd
/usr/local/etc/pki/issued
% ls
mylocalclient.crt	server.crt

// 서버 비밀키와 클라이언트 비밀키, CA 비밀키
% pwd
/usr/local/etc/pki/private
% ls
ca.key			mylocalclient.key	server.key

// CA 인증서와 DH 파라메터 파일
% pwd
/usr/local/etc/pki
% ls ca.crt dh.pem
ca.crt	dh.pem

3가지 경로에 각 파일이 나뉘어져 있습니다. easyrsa 는 마치 내가 CA (Certificate Authority) 가 된 것처럼 인증서를 발급해주고 만들어주는 역할을 한 것이고, 각각 필요한 키들이 생성되어 적절한 위치에 나뉘어져 있다고 생각하시면 됩니다. 

 

OpenVPN 서버를 다시 시작해보자

간결한 관리를 위하여 앞서 작업했던 /usr/local/etc/openvpn 경로로 서버에서 필요한 파일들을 복사해 오도록 하겠습니다. 파일명은 server.conf 에 기술된 파일명을 기준으로 하고 있으니, 다른 이름으로 생성했다면 이름을 변경해 주셔도 무방합니다. 파일이 복사되었다면 sudo 권한으로 OpenVPN 서버를 실행하도록 하겠습니다. 

% pwd
/usr/local/etc/openvpn
% cp /usr/local/etc/pki/ca.crt .
% cp /usr/local/etc/pki/dh.pem ./dh2048.pem
% cp /usr/local/etc/pki/private/server.key .
% cp /usr/local/etc/pki/issued/server.crt .

% sudo /usr/local/opt/openvpn/sbin/openvpn --config ./server.conf
% sudo /usr/local/opt/openvpn/sbin/openvpn --config ./server.conf
2020-12-01 14:17:01 WARNING: --topology net30 support for server configs with IPv4 pools will be removed in a future release. Please migrate to --topology subnet as soon as possible.
2020-12-01 14:17:01 OpenVPN 2.5.0 x86_64-apple-darwin19.6.0 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] built on Nov 13 2020
2020-12-01 14:17:01 library versions: OpenSSL 1.1.1h  22 Sep 2020, LZO 2.10
2020-12-01 14:17:01 NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x.  Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
2020-12-01 14:17:01 Diffie-Hellman initialized with 2048 bit key
2020-12-01 14:17:01 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2020-12-01 14:17:01 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2020-12-01 14:17:01 Opened utun device utun7
2020-12-01 14:17:01 /sbin/ifconfig utun7 delete
ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address
2020-12-01 14:17:01 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
2020-12-01 14:17:01 /sbin/ifconfig utun7 10.8.0.1 10.8.0.2 mtu 1500 netmask 255.255.255.255 up
2020-12-01 14:17:01 /sbin/route add -net 10.8.0.0 10.8.0.2 255.255.255.0
add net 10.8.0.0: gateway 10.8.0.2
2020-12-01 14:17:01 Could not determine IPv4/IPv6 protocol. Using AF_INET6
2020-12-01 14:17:01 Socket Buffers: R=[786896->786896] S=[9216->9216]
2020-12-01 14:17:01 setsockopt(IPV6_V6ONLY=0)
2020-12-01 14:17:01 UDPv6 link local (bound): [AF_INET6][undef]:1194
2020-12-01 14:17:01 UDPv6 link remote: [AF_UNSPEC]
2020-12-01 14:17:01 MULTI: multi_init called, r=256 v=256
2020-12-01 14:17:01 IFCONFIG POOL IPv4: base=10.8.0.4 size=62
2020-12-01 14:17:01 IFCONFIG POOL LIST
2020-12-01 14:17:01 Initialization Sequence Completed

이렇게 대략 로컬 설치가 끝났습니다. 사실 이후에 udp4 만 사용하도록 변경, tls-auth 가 생각처럼 동작하지 않아 제외하는 작업등을 진행한 후에 정상적인 기동, 클라이언트의 연결이 가능했습니다. 이 부분은 다음 포스팅에서 정리해 보도록 하겠습니다. 

 

[ NordVPN 크리스마스 할인행사 > bit.ly/39unoRx ]

 

NordVPN: Best VPN Service Provider | #1 Editors' Choice

온라인에서 개인정보를 보호하고 지리적 위치 제약 없이 콘텐츠에 액세스하세요. 60개국 이상에서 1000개 이상의 서버를 사용할 수 있으며, 강력한 암호화와 로그 삭제 정책을 갖추고 있습니다.

nordvpn.com

 

본 포스팅은 제휴마케팅을 통해 소정의 수수료를 받을 수 있습니다.

728x90
728x90

오늘은 go 입니다. <못 먹어도 go> 라는 말이 있지만 golang 은 참 가까이 하기에 쉽지 않은 물건인 느낌입니다. OpenVPN 관련하여 오픈소스로 공개되어 있는 Web UI 가 go X beego 로 구성되어 있어서 간만에 go 환경을 맞추느라 고생을 했습니다.


오늘의 에러를 소개합니다.

beego 환경을 준비하기 위해서는 아래의 두가지 패키지를 설치해야 합니다. 

% go get -u github.com/astaxie/beego
% go get -u github.com/beego/bee

하지만 잘 되었을리가 없겠죠? beego 패키지를 설치하는 동안은 문제가 없었지만 개발도구인 bee 를 올리는 동안 묘한 에러가 발생했습니다. 

% go get -u github.com/beego/bee
# golang.org/x/sys/unix
go/src/golang.org/x/sys/unix/fcntl_darwin.go:11:9: undefined: fcntl
go/src/golang.org/x/sys/unix/fcntl_darwin.go:16:12: undefined: fcntl
go/src/golang.org/x/sys/unix/fcntl_darwin.go:22:12: undefined: fcntl
go/src/golang.org/x/sys/unix/ioctl.go:20:9: undefined: ioctl
go/src/golang.org/x/sys/unix/ioctl.go:29:9: undefined: ioctl
go/src/golang.org/x/sys/unix/ioctl.go:38:9: undefined: ioctl
go/src/golang.org/x/sys/unix/ioctl.go:48:9: undefined: ioctl
go/src/golang.org/x/sys/unix/ioctl.go:60:9: undefined: ioctl
go/src/golang.org/x/sys/unix/syscall_bsd.go:645:10: undefined: mmap
go/src/golang.org/x/sys/unix/syscall_bsd.go:646:10: undefined: munmap
go/src/golang.org/x/sys/unix/ioctl.go:60:9: too many errors

% bee
zsh: command not found: bee

 

문제는 golang 의 버전

여기저기 검색을 해보았지만 딱히 상황에 걸맞는(?) 해결책을 찾기가 어려웠습니다. 그러다 중국어로 된 커뮤니티 한 곳에서 같은 질문을 한 스레드를 찾았고 답변으로 "go 업그레이드 하니까 되던데?" 를 찾았습니다. 네, 재빨리 버전을 확인하니 근래의 버전과 꽤 차이가 나고 있었습니다. 

// 업데이트 전
% go version
go version go1.10.3 darwin/amd64

// 업데이트 후
% go version
go version go1.15.5 darwin/amd64

1.10.3 에서 나던 오류가 1.15.5 로 업그레이드 한 이후에는 깨끗히 사라졌습니다. go get 을 하는 과정에 뭔가 조금 더 친절한 에러 메세지가 나왔다면 좋겠을텐데 하는 생각이 들더군요. 사실 go 로 큰 규모의 개발을 하고 있지는 않아 쉽게 업데이트 했지만, go binary 를 업데이트하면서 다른 문제가 생길수도 있지 않을까? 하는 생각도 들었습니다. 

 

잘 동작하는 bee!

이제 다시 bee 를 설치하고 bee 를 실행해 보았습니다. 네, 잘 돌아가네요! 그런데 bee는 2.0.0 에서 1.12.3 으로 다운그레이드 하라고... 허허... 천천히 해보기로 하고... 포스팅을 마무리 해봅니다. 

% go get -u github.com/beego/bee
lineplus@AL01249083 ~ %
lineplus@AL01249083 ~ % bee
2020/11/30 19:59:33 INFO     ▶ 0001 Getting bee latest version...
2020/11/30 19:59:33 WARN     ▶ 0002 Update available 2.0.0 ==> 1.12.3
2020/11/30 19:59:33 WARN     ▶ 0003 Run `bee update` to update
2020/11/30 19:59:33 INFO     ▶ 0004 Your bee are up to date
Bee is a Fast and Flexible tool for managing your Beego Web Application.

You are using bee for beego v2.x. If you are working on beego v1.x, please downgrade version to bee v1.12.0

USAGE
    bee command [arguments]

AVAILABLE COMMANDS
...
728x90
728x90

 

지난 포스팅에 이어 이번 포스팅에서는 백업한 데이터를 복원하는 방법에 대하여 확인해 보도록 하겠습니다. 백업을 위한 파라메터가 `backup` 이었다면 반대로 복원을 위한 파라메터는 `restore` 입니다. 기억하기 쉽죠? 옵션도 비슷합니다. 백업시 사용한 포맷에 따라 다르겠습니다만 InfluxDB 에서는 신규 포맷을 권장하기 때문에 `-portable` 옵션은 항상 붙인다고 기억하면 편합니다. 


새로운 데이터베이스로 복원하기

백업 파일이 가지고 있는 데이터베이스명, 즉 원본 데이터베이스를 `-db` 옵션에 지정하고 복원시 사용할 데이터베이스의 이름을 `-newdb` 로 지정해 주어야 합니다. 원래의 데이터베이스로 바로 복원하는 것은 제공되지 않고, 약간의 우회 방법을 사용해야 합니다. 우선 새로운 데이터베이스로 복원을 해보겠습니다. 

$ influxd restore -portable -db myreport -newdb myreport_new ./
2020/11/20 15:29:03 Restoring shard 16 live from backup 20201120T062805Z.s16.tar.gz
2020/11/20 15:29:03 Restoring shard 25 live from backup 20201120T062805Z.s25.tar.gz
2020/11/20 15:29:03 Restoring shard 2 live from backup 20201120T062805Z.s2.tar.gz
2020/11/20 15:29:03 Restoring shard 41 live from backup 20201120T062805Z.s41.tar.gz
2020/11/20 15:29:03 Restoring shard 10 live from backup 20201120T062805Z.s10.tar.gz
2020/11/20 15:29:03 Restoring shard 8 live from backup 20201120T062805Z.s8.tar.gz
...
...
2020/11/20 15:29:03 Restoring shard 13 live from backup 20201120T062805Z.s13.tar.gz
2020/11/20 15:29:03 Restoring shard 21 live from backup 20201120T062805Z.s21.tar.gz
2020/11/20 15:29:03 Restoring shard 26 live from backup 20201120T062805Z.s26.tar.gz
2020/11/20 15:29:03 Restoring shard 73 live from backup 20201120T062805Z.s73.tar.gz
2020/11/20 15:29:03 Restoring shard 7 live from backup 20201120T062805Z.s7.tar.gz
$

명령 마지막에 지정된 경로에서 백업에 대한 meta 파일과 manifest 파일을 확인한 뒤 복원 작업이 진행됩니다. meta 파일은 바이너리로 되어 있어 어떤 내용이 들어 있는지 확인하기 어렵습니다만 manifest 파일을 열어보면 백업 폴더에 있는 여러 tar.gz 파일들이 어떤 데이터베이스에 대하여 어떤 리텐션 정책으로 백업되었고 각 파일의 Shard ID 를 확인해볼 수 있습니다. 

$ cat 20201120T062805Z.manifest | head -n 20
{
  "meta": {
    "fileName": "20201120T062805Z.meta",
    "size": 1902
  },
  "limited": false,
  "files": [
    {
      "database": "myreport",
      "policy": "autogen",
      "shardID": 3,
      "fileName": "20201120T062805Z.s3.tar.gz",
      "size": 1024,
      "lastModified": 0
    },
    ...
    ...

 

복원한 데이터베이스 확인하기

InfluxDB CLI 를 이용하여 데이터베이스가 잘 복원되었는지 확인해 보겠습니다. 원본 데이터베이스의 Measurement 에 저장된 데이터포인트 수를 확인하고, 복원된 데이터베이스의 Measurement 에 저장된 데이터포인트 수를 확인하면 되겠죠? 터미널에서 `influx` 를 입력하여 CLI 에 진입하고 각 데이터베이스에 대하여 간단한 쿼리를 수행했습니다. 

$ influx
Connected to http://localhost:8086 version 1.8.3
InfluxDB shell version: 1.8.3
> use myreport
Using database myreport
> select count(*) from mydata
name: mydata
time count_ratio
---- -----------
0    1063148
> use myreport_new
Using database myreport_new
> select count(*) from mydata
name: mydata
time count_ratio
---- -----------
0    1063148
>

 

 

원래의 데이터베이스로 복원하는 방법

그런데 원래의 데이터베이스로 복원을 해야할 경우에는 어떻게 해야 할까요? 우선 아무 생각 없이 원래의 데이터베이스로 복원하도록 앞서 살펴본 복원 명령의 `-newdb` 값을 원래의 데이터베이스 이름으로 지정해 보았습니다. 무슨 에러가 나는지 확인해 보시죠. 

$ influxd restore -portable -db myreport -newdb myreport ./
2020/11/20 15:45:18 error updating meta: DB metadata not changed. database may already exist
restore: DB metadata not changed. database may already exist

원래의 데이터베이스로 복원하는 방법도 어렵지 않습니다. 앞서 살펴본 것처럼 우선 1) 새로운 데이터베이스로 복원을 먼저 한 뒤, 2) 새로운 데이터베이스에서 원래의 데이터베이스로 데이터를 옮기는 방법을 써야 합니다. 굳이 이렇게 해야 할 경우가 많이 생기지 않도록 하는 것이 좋겠지만, 방법은 알아두면 피가되고 살이될 것 같습니다. 

$ influxd restore -portable -db myreport -newdb myreport_temp ./

$ influx
> USE myreport_temp
> SELECT * INTO myreport..:MEASUREMENT FROM /.*/ GROUP BY *
> DROP DATABASE myreport_temp

간단한 구문입니다만 한번 설명을 하면 1) 임시 데이터베이스(myreport_temp)를 사용하도록 명령을 하고, 2) select~into 구문을 사용하여 모든 measurement 의 값을 원래의 데이터베이스(myreport) 로 넣습니다. 이 작업은 데이터포인트의 수에 따라 시간이 많이 소요될 수 있습니다. 마지막으로 3) 임시 데이터베이스는 삭제해 줍니다. 


사실 백업과 복원은 지난 포스팅에서 처럼 풀 백업만 하는 것 보다는 증분 백업을 섞어서 해주는 것이 좋습니다. InfluxDB 는 시작과 끝 Timestamp 지정을 통해 일정 기간의 데이터포인트를 백업하는 방법을 제공하고 있습니다. 물론 저장 방식으로 인해 정확히 시작과 끝 시간 구간 내의 데이터만 추출되지는 않습니다. 

그럼에도 불구하고 데이터포인트가 많아지면 처리 속도가 영향을 받을 수 있으니 공식 문서를 참고하여 지정된 시간 범위의 데이터를 백업하고 복원하는 시도, 도전도 해보시기 바라겠습니다! (공식 문서 : docs.influxdata.com/influxdb/v1.8/administration/backup_and_restore/)


>> 지난 포스팅을 안보았다면...

 

InfluxDB, 데이터의 백업과 복원 #1 / 백업의 두가지 방법

InfluxDB 도 데이터베이스이기 때문에 만일의 상황을 대비하여 백업과 복원 방법에 대하여 알아둘 필요가 있습니다. 근래에 클라우드 기반으로 서비스를 제공하고 있다보니 공식 문서에서 설치형

ondemand.tistory.com

 

728x90
728x90

Amazon Linux 를 쓰는 EC2 인스턴스에서 yum 으로 docker-compose 의 설치가 원활하지 않아 github 에서 릴리즈된 버전을 설치해 보기로 했습니다. 구글링을 통해 잘 정리된 명령어를 찾을 수 있었고 다시 한 번 구글님께 감사의 절을 올리고 설치를 진행해 보았습니다.


Github 저장소에서 최신 릴리즈 태그 찾기

먼저 할일은 Github 의 Docker 프로젝트를 들르는 일입니다. 하위에 만들어져 있는 저장소들 중 compose 저장소가 docker-compose 를 만드는 공장입니다. 해당 저장소에 들어간 뒤 우측 사이드바에서 최신 릴리즈 정보를 확인할 수 있습니다. 

compose 저장소를 선택합니다
1.27.4 버전이 최신이군요!

 

 

docker/compose

Define and run multi-container applications with Docker - docker/compose

github.com

 

릴리즈 파일 전송받기

<Releases> 텍스트를 누르면 빌드되어 릴리즈 된 파일들의 목록을 볼 수 있습니다. 플랫폼과 운영체제에 따라 서로 다른 빌드를 사용하게 되는데요, Linux 버전을 받으면 되겠습니다. 구글링으로 찾은 curl 명령 예제는 uname -s 와 uname -m 으로 플랫폼 정보를 가져와서 쓰도록 되어 있어 유용했습니다! 

리눅스 버전을 받아 봅시다

// 최신 릴리즈 버전에 맞게 "1.27.4" 부분을 바꿔줍니다
// Root 권한이 아니라면 sudo 를 사용해야겠죠?
// 보통 기본 Path 로 잡혀 있는 /usr/local/bin 에 파일을 저장했습니다
//
$ sudo curl -L "https://github.com/docker/compose/releases/download/1.27.4/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   651  100   651    0     0  27125      0 --:--:-- --:--:-- --:--:-- 27125
100 11.6M  100 11.6M    0     0  3053k      0  0:00:03  0:00:03 --:--:-- 3630k

// 받은 파일의 퍼미션을 변경하여 실행 가능하게 바꿉니다
//
$ sudo chmod +x /usr/local/bin/docker-compose

// 설치된 docker-compose 의 버전을 확인합니다. 
//
$ docker-compose --version
docker-compose version 1.27.4, build 40524192

 

728x90
728x90

InfluxDB 도 데이터베이스이기 때문에 만일의 상황을 대비하여 백업과 복원 방법에 대하여 알아둘 필요가 있습니다. 근래에 클라우드 기반으로 서비스를 제공하고 있다보니 공식 문서에서 설치형 InfluxDB 인 InfluxDB OSS 로 문서를 찾아보아야 합니다. OSS 버전이 2.0 까지 출시되었지만 사용중인 1.8 버전을 기준으로 내용을 정리해 보겠습니다. 

 


데이터 백업과 복원 절차의 InfluxDB 버전 호환성

SaaS 혹은 PaaS 형 서비스인 InfluxDB Cloud 를 제외하면 우리가 선택할 수 있는 옵션은 두가지 입니다. 하나는 InfluxDB OSS 이고 다른 하나는 InfluxDB Enterprise 입니다. 전사에서 InfluxDB 를 도입해서 쓰는 경우가 아니라면 대부분 OSS 버전이겠습니다만, 중요한 것은 이 두가지 종류간에는 백업 데이터의 상호 호환이 된다고 합니다. 

다만, 공식 문서에서 버전에 대한 언급이 있는데요, 메이저 버전이 같아야 상호 백업, 복원이 가능하다고 합니다. 현재 OSS 의 2.0 버전과 1.8 버전 간에는 데이터 호환이 되지 않을 수 있다는 이야기입니다. 문제가 없는 예시로 들고 있는 것은 1.7.3 버전과 1.8.2 버전인데요, 이런 경우에는 문제가 없다고 합니다. 다른 메이저 버전간의 백업, 복원은 그런 상황이 오면 확인해 보도록 하겠습니다 ^^;;

 

백업 파일은 두가지 포맷이 존재한다!?

InfluxDB 를 백업할 때 사용할 수 있는 포맷은 두가지입니다. 하나는 Enterprise 버전과 호환되는 포맷으로 CLI 에서 백업시 -portable 옵션을 사용해야 합니다. -portable 옵션 없이 백업을 하는 경우 이전 세대의 포맷인 Legacy 버전으로 백업됩니다. Enterprise 버전을 당장 사용할 일이 없다고 하더라도 -portable 옵션을 이용하는 것이 좋아보입니다.

백업된 데이터를 복원할 때도 백업 파일의 버전을 지정해 주어야 합니다. 복원시 -portable 옵션을 주게 되면 Enterprise 버전과 호환되는 포맷의 백업파일을 복원한다는 의미가 됩니다. 백업때와는 달리 Legacy 버전의 데이터를 복원할때는 -online 옵션을 지정해 주어야 합니다. 

어쨋든 새로운 포맷을 추천하는 InfluxData 의 안내


백업#1 - InfluxDB 로컬에서 백업 수행해보기

기본적인 InfluxDB 의 백업, 복원에 대한 특징과 주의사항을 살펴보았으니 실제로 백업을 해보겠습니다. InfluxDB 를 백업하는 방법은 1) 해당 머신에서 직접 백업하는 방법과, 2) 리모트 접근 포인트를 열어서 백업하는 방법의 두가지가 있습니다. 간단한 것이 1번의 방법이니 로컬에서 백업을 먼저 해보도록 하겠습니다.

$ influxd backup -portable -database myreport ./
2020/11/18 16:22:12 backing up metastore to meta.00
2020/11/18 16:22:12 backing up db=myreport
2020/11/18 16:22:12 backing up db=myreport rp=autogen shard=3 to myreport.autogen.00003.00 since 0001-01-01T00:00:00Z
...
...
2020/11/18 16:22:13 backup complete:
2020/11/18 16:22:13     20201118T072212Z.meta
2020/11/18 16:22:13     20201118T072212Z.s3.tar.gz
...
...
2020/11/18 16:22:13     20201118T072212Z.manifest

가장 간단한 방식으로 명령을 만들어 보았습니다. 터미널로 InfluxDB 가 구동되는 서버에 접근하여 CLI 로 명령을 내리시면 됩니다. 첫번째 인자로 backup 을 지정하여 백업 작업의 수행을 알려줘야 합니다. 앞서 살펴본 것처럼 새로운 버전의 포맷을 쓰기 위해 -portable 옵션을 넣었고, 특정한 데이터베이스만 백업하기 위하여 -database 로 데이터베이스 이름(제 경우는 myreport)을 지정해 주었습니다. 데이터베이스가 여러개 생성되어 있고 전체 백업을 진행하려면 -database ##DB명## 을 제외하고 명령을 내리시면 됩니다. 

마지막 인자는 백업 파일이 저장될 경로입니다. 명령을 실행하는 디렉토리에 백업 파일을 만들기 위하여 ./ 를 넣었습니다만 각자의 상황에 맞게 경로를 지정해 주면 문제 없을겁니다. 이렇게 명령을 내리고 나면 지정된 경로에 아래와 같이 백업 파일이 생성됩니다. 뭔가 복잡하지만 자세히 알아보지는 않겠습니다 ^^

 

백업#2 - 리모트에서 InfluxDB 백업해보기

리모트에서 InfluxDB 를 백업하기 위해서는 두가지 작업이 필요합니다. 1) 작업을 진행하는 컴퓨터에서 influxd 를 실행할 수 있도록 바이너리가 설치되어 있어야 하며, 2) InfluxDB 장비 설정에 원격지에서 접근을 허용하도록 주소와 포트가 지정되어 있어야 합니다. 우선 2) 번의 작업을 진행해 보겠습니다.

2번의 작업을 위해 InfluxDB 의 설정 파일인 influxdb.conf 를 열겠습니다. 패키지 관리자를 이용하여 설치했다면 아마도 /etc/influxdb/influxdb.conf 정도의 경로에서 설정 파일을 찾아보실 수 있을 겁니다. vim 등의 에디터로 파일을 열고 bind-address 항목을 찾아보도록 하겠습니다. 주석 처리된 부분을 해제하면 기본적으로 서버의 모든 IP 의 지정된 포트로 influxd 가 액세스 할 수 있게 됩니다. 

설정이 반영되도록 systemctl restart influxdb.service 명령으로 InfluxDB 를 재기동 하겠습니다. 참고로 InfluxDB 의 기본 포트가 8086 이기 때문에 제어를 위한 HTTP 서비스 포트는 8086 이 아닌 다른 포트를 사용해야 합니다. 공식 문서에서는 8088 포트를 쓰고 있는데 각자의 사정에 맞추어 포트를 지정해주시면 되겠습니다. 참고로 위와 같이 설정하면 서버의 모든 IP 로 8088 번 접근이 가능해집니다.

원격으로 백업 작업을 수행하기 위해서는 -host 옵션을 추가로 지정해 주어야 하고 ##influxdb_IP_주소##:8088 을 지정해 주어야 합니다. 다른 장비에서 아래와 같은 명령으로 8088번 포트로 접근하여 백업을 정상적으로 수행할 수 있었습니다. 

[다른장비]$ influxd backup -portable -database myreport -host ##서버주소##:8088 ./
2020/11/18 17:23:48 backing up metastore to meta.00
2020/11/18 17:23:48 backing up db=myreport
2020/11/18 17:23:48 backing up db=myreport rp=autogen shard=3 to myreport.autogen.00003.00 since 0001-01-01T00:00:00Z
2020/11/18 17:23:48 backing up db=myreport rp=autogen shard=4 to myreport.autogen.00004.00 since 0001-01-01T00:00:00Z
...

 


이번 포스팅에서는 InfluxDB 백업시 알아두어야 할 점과 InfluxDB 가 제공하는 두가지 백업 방법을 살펴보았습니다. 다음 포스팅에서는 이렇게 백업한 파일을 복원하는 방법에 대해서 살펴보겠습니다. 

>>> 이어지는 복원 방법 포스팅은 이쪽입니다!

 

InfluxDB, 데이터의 백업과 복원 #2 / 백업 파일 복원하기

지난 포스팅에 이어 이번 포스팅에서는 백업한 데이터를 복원하는 방법에 대하여 확인해 보도록 하겠습니다. 백업을 위한 파라메터가 `backup` 이었다면 반대로 복원을 위한 파라메터는 `restore`

ondemand.tistory.com

 

728x90
728x90

시계열 데이터베이스는 기본적으로 다량의 데이터 포인트를 수집하여 보관하고, 시각화 도구를 이용하여 필요한 메트릭을 만드는 과정을 거치게 됩니다. 하지만 데이터 포인트가 지속적으로 쌓이게 되면 데이터를 조회하는 속도가 느려질 뿐만 아니라 스토리지의 공간 문제도 발생할 수 밖에 없습니다.

이 때 사용하는 것이 대용량의 데이터 포인트를 일정한 주기로 다시 요약하여 가공된 데이터로 만드는 것인데요, 롤업 혹은 리텐션이라는 용어로 많이 부릅니다. 처음 사회 생활을 시작했을 때는 RDBMS 에 쿼리를 만들어 배치 작업으로 주단위, 월단위 등의 리텐션 작업을 했던 기억이 새록새록 납니다 (아재 인증...)

InfluxDB 는 패키지를 이용하여 기본 값으로 제품을 설치했을 때, 리텐션 주기에 대한 설정이 켜져 있지 않습니다. 이 상태에서 데이터베이스를 생성하면 리텐션 주기에 맞추어 데이터를 롤업, 리텐션 하지 않고 라인 프로토콜을 통해 입력된 그대로 쌓아두게 됩니다. 시간이 흐름에 따라 데이터의 조회 속도가 느려지고 스토리지 문제의 영향이 생길 수 밖에 없겠죠?

출처 : wikipedia

InfluxDB 의 리텐션 자동 활성화 옵션 켜기

리텐션을 활성화 하고 리텐션 주기를 설정하기 위해서는 아래의 단계로 작업을 해야 합니다. 이미 데이터베이스를 생성해서 사용하고 있는 경우와 처음 생성하는 경우로 나뉘어 질텐데요, InfluxDB 설정 파일의 변경 이전에 만든 DB 인가, 이후에 만든 DB 인가로 설정 값이 적용되게 됩니다. 

InfluxDB 의 설정 파일은 CentOS 기준으로 /etc/influxdb/influxdb.conf 로 저장되어 있습니다. 이 파일을 열어서 초반부를 살펴보면 `retention-autocreate=true` 라는 옵션이 주석 처리 되어 있는걸 볼 수 있습니다. 데이터 베이스 생성시 자동으로 리텐션을 사용하도록 하기 위해서 주석문을 풀어야겠죠?

// CentOS 기준
$ vim /etc/influxdb/influxdb.conf

###
### [meta]
###
### Controls the parameters for the Raft consensus group that stores metadata
### about the InfluxDB cluster.
###

[meta]
  # Where the metadata/raft database is stored
  dir = "/var/lib/influxdb/meta"

  # Automatically create a default retention policy when creating a database.
  # retention-autocreate = true

  # If log messages are printed for the meta service
  # logging-enabled = true

리텐션 작업이 필요한지 확인하는 설정 항목은 조금 더 아랫쪽에 있습니다. vim 을 쓰고 있다면 슬래시를 눌러 키워드를 검색하여 위치를 빠르게 찾아가도록 하겠습니다. 주석처리 되어 있는 두가지 옵션을 활성화 해야 합니다. `enabled=true` 는 주기적인 점검시 정의된 리텐션 정책을 적용의 On, Off 역할이고, `check-internal` 은 점검을 수행하는 간격을 지정하는 값입니다. 

(vim 에서 /[retention] 을 입력하면 빠르게 찾을 수 있습니닷!)

###
### [retention]
###
### Controls the enforcement of retention policies for evicting old data.
###

[retention]
  # Determines whether retention policy enforcement enabled.
  # enabled = true

  # The interval of time when retention policy enforcement checks run.
  # check-interval = "30m"

 

리텐션 자동 활성화 확인하기

위의 옵션들의 주석 처리를 해제한 후 InfluxDB 를 재기동 했습니다. 재기동을 했으니 새로운 변경 사항이 반영되었겠죠? InfluxDB CLI 에 접근하여 새로운 DB 를 생성하여 설정 변경전에 생성한 DB 와 리텐션 정책이 어떻게 차이가 나는지 확인해 보도록 하겠습니다. 

// InfluxDB 재기동 (CentOS 7.x 이후 기준)
$ systemctl restart influxdb.service

// 리텐션 자동 생성 활성화 전에 만든 DB 의 정보
$ influx
Connected to http://localhost:8086 version 1.8.3
InfluxDB shell version: 1.8.3
> use encreport
Using database encreport
> show retention policies
name    duration shardGroupDuration replicaN default
----    -------- ------------------ -------- -------
autogen 0s       168h0m0s           1        true

// 리텐션 자동 생성 활성화후 DB 생성 및 정보 확인
>
> create database test
> use test
> show retention policies
name    duration shardGroupDuration replicaN default
----    -------- ------------------ -------- -------
autogen 0s       168h0m0s           1        true

어랏..? 생각과는 좀 다릅니다. 리텐션 자동 활성화를 선택 하건 하지 않건 변화가 보이지 않습니다. 자동 생성 되었음을 알려주는 이름인 `autogen` 을 가진 정책이 각 데이터베이스에 이미 존재합니다. 도대체 무슨일이 일어나는지 알수가 없어서 가장 처음에 나온 설정인 `retention-autocreate=false` 로 명시적으로 끈 뒤에 데이터베이스를 생성해 보겠습니다. 당연히 리로딩도 해주셔야 합니다!

> create database test2
> use test2
Using database test2
> show retention policies
name duration shardGroupDuration replicaN default
---- -------- ------------------ -------- -------

아하... 이런 것이었습니다. 설정의 주석을 풀던 풀지 않던 일단 기본 값은 `autogen` 정책을 만드는 것이었습니다. 어렵게 주석을 묶고 풀고 할 이유가 없었던 것 같은 느낌적 느낌입니다. 여튼, 기본 정책은 자동으로 잘 생성되니 다음 포스팅에서는 실제 정책을 만들어서 데이터베이스에 적용하는 방법을 살펴보도록 하겠습니다!

 


오늘의 교훈 : 기본 문서를 잘 읽자

 

Configure InfluxDB OSS | InfluxDB OSS 1.8 Documentation

Configure InfluxDB OSSThe InfluxDB open source (OSS) configuration file contains configuration settings specific to a local node.ContentConfiguration overviewInfluxDB is configured using the configuration file (influxdb.conf) and environment variables. If

docs.influxdata.com

 

728x90
728x90

iOS 의 경우 Mac 과 함께 디버깅 하기 위한 궁합 및 도구가 편리하게 제공되고 있어서 어렵지 않게 Wireshark 로 기기의 패킷을 캡쳐할 수 있었습니다. 하지만 안드로이드 운영체제는 가상 인터페이스로 붙이는 방법이 없는 것처럼 보였고, 단말을 루팅하여 tcpdump 를 돌리는 것과 같은 방식들이 제안되고 있었습니다.

시험 기기로 확보한 기기가 삼성의 단말이고 제 소유가 아니다보니 루팅을 하는 것도 좀 꺼려지더군요. 그래서 찾아본 것이 바로 NOX Player 였습니다. 게임을 즐기는 사람들이면 안써본 사람이 없다는 NOX Player. 저는 게임을 하기 위해서도 아니고 안드로이드 기기의 패킷을 확인하기 위해서 NOX Player 를 처음 사용하게 되다니...


adb 를 통해 구동중인 NOX Player 의 안드로이드에 연결하기

우선 NOX Player 를 이용하여 적당한 안드로이드 이미지를 구동시킵니다. 기본적으로 Virtual Box 이지만 구동할 수 있는 이미지와 안드로이드 버전이 제한적인 것 같아 좀 아쉬웠습니다. API 버전이 안드로이드 운영체제 버전마다 차이가 있고, 이 차이가 실제 앱 구동에도 영향을 주는 것으로 알고 있습니다.

여튼, 안드로이드 운영체제가 잘 구동되면 NOX Player 로 62001 포트를 이용하여 연결이 가능해 집니다. 터미널에서 adb 를 이용하여 로컬호스트의 62001 포트로 연결을 맺어보겠습니다. 아래와 같은 명령을 사용하시면 되며, 정상적으로 연결된 경우 connected to 127.0.0.1:62001 이라는 메세지를 볼 수 있습니다. 

% adb connect 127.0.0.1:62001
adb server version (32) doesn't match this client (41); killing...
* daemon started successfully
connected to 127.0.0.1:62001

물론 iOS X Mac 과 달리 이렇게 연결했다 하여 바로 쉽게 Wireshark 로 직접 패킷을 볼 수 있는 것은 아닙니다. NOX Player 를 통해 TCP 덤프를 캡쳐해 줄 tcpdump 와 네트워크로 파일 내용을 전송해줄 netcat 을 복사하여 사용해야 합니다. 이 파일들을 이용하여 1) 파일로 떨군뒤 로컬 환경으로 복사하여 분석하거나 2) netcat 으로 전송 포트를 열어 adb 를 경유하여 wireshark 로 실시간으로 덤프를 보는 방법의 두가지 옵션을 쓸 수 있게 됩니다. 

 

안드로이드 기기로 tcpdump 와 netcat 파일 전송

우선 안드로이드 기기에서 구동되는 tcpdump 와 netcat 바이너리를 찾아야 합니다. 유통되는 왠만한 버전을 사용하는 것은 별 문제 없을거라 생각합니다. tcpdump 와 netcat 은 아래의 각 사이트에서 최근 버전을 다운로드 받으시기 바랍니다. (TCPDUMP : www.androidtcpdump.com/android-tcpdump/downloads, netcat : 실행파일만 받는게 좋은데... 경로를 잊어버렸습니다 ;; 찾는대로 다시 업데이트 해두겠습니다. )

안드로이드에서 사용할 유틸리티 2종이 준비되면 adb 의 push 명령을 이용하여 바이너리 파일을 NOX Player 의 안드로이드로 전송하도록 하겠습니다. 아래와 같이 가상 sdcard 의 경로 하위의 Download 폴더로 파일을 전송했습니다. 

% adb push netcat /sdcard/Download && adb push tcpdump /sdcard/Download
netcat: 1 file pushed. 27.1 MB/s (92156 bytes in 0.003s)
tcpdump: 1 file pushed. 48.3 MB/s (1889632 bytes in 0.037s)

/sdcard/Download 폴더로 전송한 파일을 다시 /system/xbin 경로로 이동시키도록 하겠습니다. 이 작업을 위해서는 adb 를 이용해 안드로이드 쉘에 접근해야 합니다. 아래와 같이 adb shell 명령을 입력하면 62001 포트를 통해 안드로이드 쉘에 접근할 수 있습니다. 일반적인 터미널에서처럼 cp 명령으로 파일을 옮기고, chmod 를 통해 실행 권한을 부여하도록 하겠습니다. chmod u+x 해도 무방합니다.

% adb shell
dream2lte:/ # cp /sdcard/Download/netcat /system/xbin/
dream2lte:/ # cp /sdcard/Download/tcpdump /system/xbin/
dream2lte:/ #
dream2lte:/ # chmod 755 /system/xbin/netcat
dream2lte:/ # chmod 755 /system/xbin/tcpdump

 

tcpdump 를 실행하여 pcap 파일로 패킷을 캡쳐하자

이제 패킷 덤프를 뜰 준비가 되었습니다. 일반적으로 사용하는 tcpdump 명령들을 대부분 사용할 수 있기 때문에 필요에 따라 옵션을 조합하시면 되겠습니다. 안드로이드의 모든 인터페이스로 들어오는 패킷을 캡쳐하여 /sdcard/Download 경로에 pcap 파일로 떨구는 명령의 예제는 아래와 같습니다. 캡쳐를 중지하려면 ctrl-c 등으로 중지 시그널을 보내시면 됩니다. 참 쉽죠?

dream2lte:/ # tcpdump -i any -n -s 0 -w /sdcard/Download/1557.pcap
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
^C73886 packets captured
88490 packets received by filter
1864 packets dropped by kernel

 

캡쳐한 pcap 파일을 로컬로 전송하여 분석해보자

이제 adb 의 옵션중 pull 을 이용하여 파일을 안드로이드 환경에서 로컬 환경으로 복사해 오도록 하겠습니다. . 소스, 목적지의 순서로 파라메터를 넣으면 되겠죠? 아래는 그 예제입니다. 캡쳐를 오랫동안 하지 않았지만 포트에 상관없이 모든 패킷을 캡쳐하다보니 양이 많습니다.

안드로이드 시뮬레이터의 성능에 영향을 줄 수 있으니 로컬 환경에서와 달리 tcpdump 를 사용할 때는 포트와 같은 조건을 꼼꼼히 넣어주시는 것이 좋습니다. 캡쳐된 pcap 파일이 로컬 환경으로 복사가 완료되면 wireshark 를 이용하여 파일을 열고 패킷을 분석하시면 됩니다. 

% adb pull /sdcard/Download/1557.pcap ./
/sdcard/Download/1557.pcap: 1 file pulled. 22.1 MB/s (96239260 bytes in 4.150s)

 

netcat 을 이용하여 실시간으로 패킷 분석하기

파일로 이용하여 패킷을 분석하는 것은 왠지 절차가 좀 복잡해 보입니다. 그리고 실시간으로 변화를 관찰할 수 없어 캡쳐가 잘못된 경우 다시 동일한 과정을 반복해야 합니다. 정상적인 사람인 우리들은 이런 불편함을 참을수가 없습니다 ㅎㅎ 이때는 netcat 을 이용해서 캡쳐되는 파일들을 특정 포트로 노출시켜 wireshark 가 받도록 하는 방법을 사용할 수 있습니다. 

1) 우선 터미널을 두개 띄웁니다. 하나는 adb shell 로 안드로이드에서 tcpdump 를 실행하는 목적이고, 다른 하나는 adb forward 로 로컬 환경의 wireshark 로 데이터를 보내는 목적입니다.

2) 1번 터미널 - 조금전과 마찬가지로 안드로이드 쉘에서 tcpdump 를 실행해야 합니다. 이때, 캡쳐된 내용을 파일로 떨구지 말고 파이프(|)를 사용하여 netcat 이 내용을 전달 받도록 하겠습니다. netcat 는 특정 포트 (아래에서는 12345) 로 전달 받은 내용을 전송하게 됩니다. tcpdump 에서 이 포트의 트래픽은 캡쳐하지 않도록 not port 12345 를 파라메터에 넣었다는 점도 참고해 주세요!

2) 2번 터미널 - 이제 로컬 쉘에서 adb forward 명령을 이용해 시뮬레이터의 프로토콜:포트를 로컬의 프로토콜:포트로 전달하겠습니다. 맥 환경에서의 netcat 인 nc 명령으로 해당 포트를 수신하고, 파이프를 통해 wireshark 로 수신된 내용을 전달하는 명령입니다. 

// 터미널 #1 (안드로이드 쉘에 접근) - tcpdump 로 패킷 떠서 netcat 으로 내보내기
% adb shell
% # tcpdump -i any -n -s 0 -w - not port 12345 | netcat -l -p 12345
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
^C2606396 packets captured
2779150 packets received by filter
164234 packets dropped by kernel

// 터미널 #2 (로컬 쉘) - netcat 이 내보내는 것 받아서 wireshark 로 넘기기
% adb forward tcp:12345 tcp:12345 && nc 127.0.0.1 12345 | wireshark -k -S -i -

다소 번거롭지만 NOX Player 를 이용하여 안드로이드 기기의 패킷을 캡쳐하고 로컬의 wireshark 로 전달하여 분석하는 두가지 방법을 살펴보았습니다. 기기를 루팅하지 않고 패킷을 캡쳐할 방법이 없기 때문에 시뮬레이터로 부담 없이 패킷을 분석해 보시기 바랍니다. 

 

728x90
728x90

개발을 하던 다른 트러블 슈팅을 하던 기기의 패킷을 추출해야 하는 경우들이 많습니다. Mac 을 사용하는 경우 rvi (Remote Virtual Interface) 를 이용해서 기기를 연결해서 쉽게 와이어샤크 Wireshark 같은 물건으로 패킷을 캡쳐할 수 있습니다. 말 그대로 가상 네트워크 인터페이스로 iOS 기기를 설정하기 때문이죠.

개인 기기로 아이폰을 쓰다보니 안드로이드는 샤오미 홍미4 이후 오랫동안 쓴적이 없었습니다. 그나마도 딸래미 학교 들어가면서 비상연락용 겸 슬랙 서적 집필할 때 화면 캡쳐용으로 산거라 진심을 다해서 써보지도 않았습니다. 허나, 현실에서는 안드로이드 환경의 패킷을 확인해야 하는 일이 종종 생기더군요.


ADB, 안드로이드 디버그 브릿지

이유는 잘 기억나지 않지만 제 Mac 에도 안드로이드 스튜디오 Android Studio 가 이미 설치되어 있었습니다 -_-;; ADB 는 Android SDK 개별 설치 혹은 Android Studio 설치시 SDK 에 딸려서 설치되는 디버그 툴인 것 같습니다. 패킷을 뜨기 위해 기기를 연결할 필요가 있었는데요 (사실은 NOX 로 기기 에뮬레이션해서...) ADB 가 그냥 실행이 되지는 않더군요.

Android Studio 가 정상적으로 동작하고 있다면 ADB 는 어딘가에 잘 설치가 되어 있는 상태입니다. 제 경우에는 아래의 Path 에서 해당 내용을 확인할 수 있었습니다. 아마 대부분 비슷한 경로에 설치가 되어 있을거라 생각합니다. 

% pwd
/Users/nopd/Library/Android/sdk/platform-tools

 

Path 로 경로 잡아주기

보통 SDK 가 설치되면 자동으로 Path 를 설정해 주는 경우가 많은데 Android SDK 는 그러지 않나 봅니다. (혹은 제가 영어로 나온 메세지를 놓친 것일지도... 속닥속닥...) 제 경우 필요한 터미널 환경 설정을 .bash_profile 에 하고 있어서 아래와 같이 Android SDK 의 Platform tools 경로를 추가해 주었습니다. 이렇게 해주고나니 어디서든 adb 를 실행할 수 있게 되었습니다 ㅎㅎ 

# Setting PATH for Android Platform Tools (esp for ADB)
export PATH="${PATH}:/Users/nopd/Library/Android/sdk/platform-tools"

그럼! 즐거운 디버깅 되시길 기원합니다. 이제 저는 NOX 와 씨름하러...

728x90

+ Recent posts