1. 대시보드에서 나타내야 할 것

- 기간에 따른 사용자 수

- 인기글 리스트

- 유입 경로 및 채널

- 유입 키워드

- 유입자 현황 차트 (척도 : 기간, Refere URL, 컨텐츠, 디바이스)

 

 

2. 추가 구현하고 싶은 것

- 전날 유입자 통계를 카카오톡으로 알림 받기

- 현재 학습하고 있는 OAuth2.0을 이용하여 대시보드 사이트 인증

- 일일 평균 유입자 현황

- 현재 기능별로 레포지토리가 분리되어있고, kafka broker에 다양한 로그들을 수집할 예정이기 때문에 향후 kubernetes를 적용할 예정

 

 

3. 사용할 기술

- DB : DynamoDB or MongoDB (조회성이 많기 때문에 RDB보다 NOSQL이 낫다고 판단) with JPA

- Message Broker : Apache Kafka (Topic은 YYYYmmDD 형식 사용, content는 json형식의 로그데이터 / 일일 배치로 DB BulkUpdate)

- Framework : spring boot with jstl (다른 가벼운 것을 써도 되지만, 학습 차원에서 사용하도록 한다.)

- 언어 : Java1.8

- 인증 : Oauth2.0(Spring Security 사용 예정), jwt

 

 

4. 수집해야할 정보

- 블로그 유입자들이 클릭한 컨텐츠

- 유입 시간대

- 블로그를 조회한 Referer URL

 

 

 

5. 아키텍처 구성도

 

 

6. 참고 문헌

- KISA 고시 및 권고 : www.kisa.or.kr/public/laws/laws2.jsp

- Apache Kafka Documentation : www.kafka.apache.org/documentation/

- RFC6749 : www.tools.ietf.org/html/rfc6749

 

 

7. 수정 로그

2020.05.13 : 최초 작성

2020.05.20 : 아키텍처 다이어그램 추가 완료

2020.06.11 : 아키텍처를 AWS로 옮기는 중, 불필요한 로드밸런서 개수와 외부 노출 서비스의 도메인 연결로 인해 아키텍처 수정중.

2020.06.16 : 서비스별 로드밸런서 아키텍처 적용 및 향후 계획(kubernetes 적용 예정) 추가

2020.06.30 : 운영 환경을 생각하고 설계할 것이기 때문에 kafka와 zookeeper를 분리하는 아키텍처 적용 예정

2020.07.01 : Zookeeper Cluster 구성 완료

1. https://json.geoiplookup.io 오픈소스

   - 위 링크를 통해 가져 올 수 있는 데이터의 목록은 다음과 같다.

(
   {
      "ip":"-",
      "isp":"-",
      "org":"",
      "hostname":"-",
      "latitude":-,
      "longitude":-,
      "postal_code":"",
      "city":"-",
      "country_code":"KR",
      "country_name":"South Korea",
      "continent_code":"AS",
      "continent_name":"Asia",
      "region":"Seoul",
      "district":"-",
      "timezone_name":"Asia\/Seoul",
      "connection_type":"Corporate",
      "asn_number":3786,
      "asn_org":"-",
      "asn":"-",
      "currency_code":"KRW",
      "currency_name":"South Korean Won",
      "success":true,
      "premium":false
   }
);

  - 하지만, 개인정보 보호법에 따르면 특정인을 유추할 수 있는 정보를 수집하여서는 안되므로, ip address, 위도, 경도를 수집하지 않겠다.

  - 최종적으로 위 오픈소스를 통해 가져갈 정보는 "country code", "region"만 가져가겠다.

 

 

 

2. Javascript - document.referrer 

  - document객체의 referrer를 이용하면, 참조한 페이지를 알 수 있다.

  - 실험 결과, 주소창에 직접 친 경우 빈 string을 출력하였으며,

  - 블로그 내부에서 다른 글을 참조하였을 경우, 블로그 도메인을 포함한 url이 출력되었다.

  - 외부 링크를 타고 오는 경우, 그대로 외부 링크를 표시했다.

  - 이를 이용하여 실질적인 블로그 이용자를 추적할 수 있을 것으로 보인다.

 

 

 

 

3. Javascript - Date.now()

  - 티스토리 대시보드에는 어느 시간대에 사람들이 들어왔는지에 대한 정보가 없다.

  - 시간대까지 포함하면, 개발자들이 어느시간대에 가장 공부를 많이하고 참조를 하는지 알 수 있을거같다. (?)

  - 그래서 이 정보 또한 수집하기로 하였다......

 

 

 

 

4. 기타 필요한 정보

  - 블로그 컨텐츠 정보

  - 디바이스 정보

 

 

 

 

5. NOSQL Table 초안

   {
      "topic":"kafka broker topic - PK"
      "date":"내 블로그를 조회한 날짜 - SK",
      "content":"조회한 블로그 컨텐츠 정보",
      "referer":"블로그 참조 경로",
      "device":"참조한 디바이스 정보",
      "time":"블로그 글을 조회 한 시간",
      "country":"국가",
      "city":"지역 이름 (시 단위 까지만)"
   }

 

 

 

 

6. 작업 이력

  - 2020.06.09 : 초안 작성 완료.

  - 2020.06.10 : AWS DynamoDB 테이블 생성 완료

1. AWS Site to Stie VPN 구성요소

  • Customer Gateway : Customer측 VPN연결 집신기

  • Virtual Private Gateway : AWS측 VPN연결 집신기

 

 

2. 목표 아키텍처

온프레미스와 AWS간 2중터널을 이용한 site to site VPN을 구성한다.

 

 

3. Hands on LAB

3.1. VPC 및 서브넷 구성

  • test-2SVPN-VPC-A

    • CIDR : 10.0.0.0/16

    • Public Subnet

      • 이름 : test-2SVPN-VPC-A-Public-2a-subnet

      • 가용영역 : ap-northeast-2a

    • IGW 생성 및 VPC에 attaching

  • test-2SVPN-VPC-B (Customer 역할)

    • CIDR : 20.0.0.0/16

    • Public Subnet

      • 이름 : test-2SVPN-VPC-B-Public-2a-subnet

      • 가용영역 : ap-northeast-2a

    • Private Subnet

      • 이름 : test-2SVPN-VPC-B-Public-2a-subnet

      • 가용영역 : ap-northeast-2a

    • IGW 생성 및 VPC에 attaching

    • NAT 생성 및 public subnet(test-2SVPN-VPC-B-Public-2a-1)에 attach

 

 

 

 

3.2. Instance 구성

3.2.1. VPC-A Instance

  • Instance Name : test-2SVPN-VPC-A-Public-2a-1

  • Instance Type : Amazon Linux2, t2.micro

  • Subnet : test-2SVPN-VPC-A-Public-2a-subnet

  • Security Group Name : test-2SVPN-VPC-A-Public-sg

  • Open Port : SSH, tcp 50, tcp 51, udp 500, udp 4500, tcp 4500, icmp를 test-2SVPN-VPC-B-Public-sg의 보안그룹에 대해 모두 열어준다. (SSH의 경우, 내 현재 ip도 추가한다.)

3.2.2. VPC-B Instance

  • Public Instance

    • Instance Name : test-2SVPN-VPC-B-Public-2a-1

    • Instance Type : Amazon Linux, t2.micro

    • Subnet : test-2SVPN-VPC-B-Public-2a-subnet

    • Security Group Name : test-2SVPN-VPC-B-Public-sg

    • Open Port : SSH, tcp 50, tcp 51, udp 500, udp 4500, tcp 4500, ICMP를 “test-2SVPN-VPC-A-Public-2a-1”인스턴스의 private ip“test-2SVPN-VPC-B-Private-2a-1“인스턴스의 private ip에 대해 열어둔다. (SSH의 경우, 내 현재 ip도 추가한다.)

  • Private Instance

    • Instance Name : test-2SVPN-VPC-B-Private-2a-1

    • Instance Type : Amazon Linux2, t2.micro

    • Subnet : test-2SVPN-VPC-B-Private-2a-1

    • Security Group Name : test-2SVPN-VPC-B-Private-sg

    • Open Port : SSH, tcp 50, tcp 51, udp 500, udp 4500, tcp 4500, ICMP를 “test-2SVPN-VPC-A-Public-2a-1“인스턴스의 private ip에 대해 열어둔다, “test-2SVPN-VPC-B-Public-sg”에 대해 SSH를 열어둔다.

 

 

 

3.3. VPN 설정

3.3.1. Customer Gateway 생성

다음과 같이 Public Instance IP와 NAT Gateway IP에 대해 Customer Gateway를 생성한다.

  • 이름 : test-2SVPN-VPC-B-CGW-Public, test-2SVPN-VPC-B-CGW-NAT

  • 라우팅 : 정적

  • IP 주소 : 각각 할당받은 public ip 또는 eip

  • Certificate ARN : Default

 

 

 

3.3.2. Virtual Private Gateway생성 및 라우팅 전파

다음과 같이 Virtual Private Gateway를 생성한다.

  • 이름 : test-2SVPN-VPC-A-vgw

  • ASN : Amazon 기본 ASN

다음과 같이 생성한 Virtual Private Gateway를 VPC-A에 Attach한다.

Attach 적용 후, Routing Table에 서브넷에 속한 인스턴스에 대해 Routing Propagation을 적용한다.

 

 

 

3.3.3. Site to Site VPN Connection 생성 및 VPN 설정 다운로드

 

VPN Connection이 완전히 생성될때까지 5분정도 소요됩니다.

사용가능한 상태가 되기 전까지 3.4를 수행하는 것을 권장합니다.

다음과 같이 2개의 Customer Gateway에 대해 VPN Connection을 생성한다.

  • 이름 : test-2SVPN-public-to-public, test-2SVPN-public-to-private

  • Target Gateway Type : Virtual Private Gateway

  • 가상 프라이빗 게이트웨이 : 생성한 게이트웨이 선택

  • 고객 게이트웨이 : 기존

  • Customer Gateway ID : test-2SVPN-CG, test-2SVPN-NAT

  • 라우팅 옵션 : 정적

  • 정적 IP 접두사 : Customer측 VPC CIDR(이 Hands on LAB을 따라 하였으면 20.0.0.0/16 입력)

 

 

 

3.4. VPC-B instance에 VPN설정 공유

3.4.1. VPN 구성 다운로드

다음과 같이 2개의 connection에 대해 VPN 구성 정보를 다운로드 한다.

  • 공급 업체 : Generic

  • 플랫폼 : Generic

  • 소프트웨어 : Vendoe Agnositc

 

 

 

3.4.2. Customer 측 인스턴스 sysctl.conf 수정

다음과 같이 /etc/sysctl.conf파일을 수정한다.

스크립트는 다음을 참조한다.

net.ipv4.ip_forward = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.default.send_redirects = 0

작성 후 , sudo service network restart를 이용하여 sysctl.conf를 적용시킨다.

 

 

 

3.4.3. OpenSwan 설치 및 환경 변수 세팅

 

환경 변수는 [3.4.1. 구성 다운로드 섹션]의 다운로드 받은 구성 정보가 필요합니다.

진행하기 전 필히 구성 정보를 다운로드 받아주세요.

다음과 같이 Openswan을 설치한다.

OpenSwan을 설치하고 난 후, 다음과 같이 /etc/ipsec.conf 파일과 /etc/ipsec.d 디렉토리가 생성되어 있을 것이다.

다운로드 받은 VPN 구성파일을 열어보면 2개의 터널에 대해 정보가 명시가 되어있다.

IPSec Tunnel #1
================================================================================
#1: Internet Key Exchange Configuration

Configure the IKE SA as follows:
Please note, these sample configurations are for the minimum requirement of AES128, SHA1, and DH Group 2.
Category "VPN" connections in the GovCloud region have a minimum requirement of AES128, SHA2, and DH Group 14.
You will need to modify these sample configuration files to take advantage of AES256, SHA256, or other DH groups like 2, 14-18, 22, 23, and 24.
Higher parameters are only available for VPNs of category "VPN," and not for "VPN-Classic".
The address of the external interface for your customer gateway must be a static address.
Your customer gateway may reside behind a device performing network address translation (NAT).
To ensure that NAT traversal (NAT-T) can function, you must adjust your firewall !rules to unblock UDP port 4500. If not behind NAT, we recommend disabling NAT-T.
  - IKE version              : IKEv1 
  - Authentication Method    : Pre-Shared Key 
  - Pre-Shared Key           : <YOUR PSK>
  - Authentication Algorithm : sha1
  - Encryption Algorithm     : aes-128-cbc
  - Lifetime                 : 28800 seconds
  - Phase 1 Negotiation Mode : main
  - Diffie-Hellman           : Group 2


  -- 중략 --


  The Customer Gateway inside IP address should be configured on your tunnel
interface. 

Outside IP Addresses:
  - Customer Gateway                 : 52.79.125.78 
  - Virtual Private Gateway            : 13.125.105.72

Inside IP Addresses
  - Customer Gateway                 : 169.254.49.50/30
  - Virtual Private Gateway             : 169.254.49.49/30


  -- 중략 --


  IPSec Tunnel #2
================================================================================
#1: Internet Key Exchange Configuration

Configure the IKE SA as follows:
Please note, these sample configurations are for the minimum requirement of AES128, SHA1, and DH Group 2.
Category "VPN" connections in the GovCloud region have a minimum requirement of AES128, SHA2, and DH Group 14.
You will need to modify these sample configuration files to take advantage of AES256, SHA256, or other DH groups like 2, 14-18, 22, 23, and 24.
Higher parameters are only available for VPNs of category "VPN," and not for "VPN-Classic".
The address of the external interface for your customer gateway must be a static address.
Your customer gateway may reside behind a device performing network address translation (NAT).
To ensure that NAT traversal (NAT-T) can function, you must adjust your firewall !rules to unblock UDP port 4500. If not behind NAT, we recommend disabling NAT-T.
  - IKE version              : IKEv1 
  - Authentication Method    : Pre-Shared Key 
  - Pre-Shared Key           : <YOUR PSK>
  - Authentication Algorithm : sha1
  - Encryption Algorithm     : aes-128-cbc
  - Lifetime                 : 28800 seconds
  - Phase 1 Negotiation Mode : main
  - Diffie-Hellman           : Group 2


  -- 중략 --


  The Customer Gateway inside IP address should be configured on your tunnel
interface. 

Outside IP Addresses:
  - Customer Gateway                 : 52.79.125.78 
  - Virtual Private Gateway            : 52.78.178.100

Inside IP Addresses
  - Customer Gateway                 : 169.254.101.166/30
  - Virtual Private Gateway             : 169.254.101.165/30

위 텍스트에서 필요한 부분은 각 터널에 대한 Pre-Shared Key와 각 Tunnel의 Outside IP Address이다. 이 정보를 ipsec.d/ 디렉토리 안에 명시 할 것이다.

sudo su를 입력하여 root권한으로 다음과 같이 두개의 파일을 작성해야 한다.

 

 

 

---------------------------------------------------------------------------------------------------------------------------

20191202 트러블슈팅

VPN Connection에 대해 기본적으로 2개의 터널이 제공됩니다. 단일 터널로 실행했을 때는 문제가 없었으나, 2개의 터널을 모두 사용할 때 터널 status는 모두 on임에도 불구하고 ping이 제대로 되지 않던 문제가 있었다.

해당 문제에 대한 로그는 다음과 같다.

"2SVPN2" #4: cannot install eroute -- it is in use for "2SVPN1" #3

"2SVPN1" #4: cannot install eroute -- it is in use for "2SVPN2" #3
"2SVPN1" #4: deleting state (STATE_QUICK_I1) and NOT sending notification
"2SVPN1" #4: ERROR: netlink response for Del SA esp.b5b1185b@15.164.153.107 included errno 3: No such process
"2SVPN1" #1: next payload type of ISAKMP Hash Payload has an unknown value: 31 (0x1f)
"2SVPN1" #1: malformed payload in packet

이미 먼저 연결이 성립된 customer gateway가 사용중이었고, 사용중이므로, 다른 연결 요청에 대해서는 응답을 하지 않게 된다. 키가 다르면 응답을 하지 않기 때문에 서버는 인증 요청이 잘못되어 에러가 난것으로 최종 간주하였다.

이를 해결하기 위해 구글링 한 결과, overlapip라는 다중 터널 구성시, 같은 customer ip를 사용할 수 있도록 하는 설정이 있었다. 이를 설정해주니 2중 터널 구성이 정상적으로 작동하였다.

---------------------------------------------------------------------------------------------------------------------------

 

 

VPN 구성 정보 (vi /etc/ipsec.d/2SVPN.conf)

conn 2SVPN1                       # Tunnel 1
        authby = secret
        auto = start
        left = %defaultroute
        leftid = 15.164.118.208   # Public Customer Gateway IP Address
        right = 15.164.153.107    # Public Virtual Private Gateway IP Address
        type = tunnel
        ikelifetime = 8h
        keylife = 1h
        phase2alg = aes128-sha1;modp1024
        ike = aes128-sha1;modp1024
        keyingtries = %forever
        keyexchange = ike
        leftsubnet = 20.0.0.0/16  # Customer Side VPC CIDR
        rightsubnet = 10.0.0.0/16 # AWS Side VPC CIDR
        dpddelay = 10
        dpdtimeout = 30
        dpdaction = restart_by_peer
        overlapip=yes            


conn 2SVPN2                        # Tunnel 2
        authby = secret
        auto = start
        left = %defaultroute
        leftid = 15.164.118.208    # Public Customer Gateway IP Address
        right = 15.164.186.29      # Public Virtual Private Gateway IP Address
        type = tunnel
        ikelifetime = 8h
        keylife = 1h
        phase2alg = aes128-sha1;modp1024
        ike = aes128-sha1;modp1024
        keyingtries = %forever
        keyexchange = ike
        leftsubnet = 20.0.0.0/16
        rightsubnet = 10.0.0.0/16
        dpddelay = 10
        dpdtimeout = 30
        dpdaction = restart_by_peer
        overlapip=yes

 

 

 

VPN Tunnel PSK 설정 (vi /etc/ipsec.d/2SVPN.secrets)

psk설정 파일의 이름은 확장자를 제외하고 구성정보를 명시한 파일의 이름과 같아야한다.

15.164.118.208 15.164.153.107: PSK "<YOUR TUNNNEL1 PSK>"
15.164.118.208 15.164.186.29: PSK "<YOUR TUNNEL2 PSK>"

위같이 2개의 파일에 대해 작성하고 저장한 다음,

_sudo service network restart, sudo service ipsec restart_를 터미널에 입력하여 ipsec서비스를 실행시킨다.

실행 시키고 난뒤, sudo service ipsec status를 입력하여 다음과 같은 메시지가 출력되면 제대로 VPN Tunnel이 설정 된 것이다.

"2SVPN2" #2: STATE_MAIN_I2: sent MI2, expecting MR2
"2SVPN2" #2: STATE_MAIN_I3: sent MI3, expecting MR3
"2SVPN1" #1: Peer ID is ID_IPV4_ADDR: '15.164.153.107'
"2SVPN1" #1: STATE_MAIN_I4: ISAKMP SA established {auth=PRESHARED_KEY cipher=aes_128 integ=sha group=MODP1024}
"2SVPN1" #3: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP+OVERLAPIP+IKEV1_ALLOW+IKEV2_ALLOW+SAREF_T...MODP1024}
"2SVPN2" #2: Peer ID is ID_IPV4_ADDR: '15.164.186.29'
"2SVPN2" #2: STATE_MAIN_I4: ISAKMP SA established {auth=PRESHARED_KEY cipher=aes_128 integ=sha group=MODP1024}
"2SVPN2" #4: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP+OVERLAPIP+IKEV1_ALLOW+IKEV2_ALLOW+SAREF_T...MODP1024}
"2SVPN1" #3: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP/NAT=>0x5f303410 <0x8d8726...D=active}
"2SVPN2" #4: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP/NAT=>0x03158d89 <0x8f026e...D=active}

 

 

 

 

3.5. Ping, SSH 테스트

 

Virtual Private Gateway는 단일 연결만 지원하기 때문에 Virtual Private Gateway를 통해 2쌍 이상의 연결을 할 수 없습니다. 하나의 연결이 성립된 상태에서 다른 VPN Connection을 요청할 경우, 기존 VPN Connection이 disconnect됩니다. 동시다발적으로 연결을 원할 경우, Transit Gateway를 사용해야한다.

필자는 VPC-A public === VPC-B public VPN연결이 성립된 상태에서

VPC-A public === VPC-B private 연결을 추가 요청하니 전자의 연결이 끊기고 후자의 연결이 성립되었다.

ping명령어를 통하여 private ip로 응답이 있는지 확인한다.

 

 

 

Customer → AWS

 

 

AWS → Customer

마찬가지로 SSH 접속이 되는지 확인한다.

 

 

Customer → AWS

 

 

AWS → Customer

 

 

 

또한, 2개의 터널이 정상적이라면 다음과 같이 터널의 상태가 UP을 출력할 것이다.

 

  1. rain 2020.04.09 19:10

    똑같이 따라했는데 ipsec status가
    Apr 09 10:07:26 ip-20-0-20-209.ap-northeast-2.compute.internal pluto[9989]: "test_VPN1" #46: STATE_MAIN_I1: retransmission; will wait 4 seconds for response
    Apr 09 10:07:26 ip-20-0-20-209.ap-northeast-2.compute.internal pluto[9989]: "test_VPN2" #45: STATE_MAIN_I1: retransmission; will wait 4 seconds for response
    Apr 09 10:07:30 ip-20-0-20-209.ap-northeast-2.compute.internal pluto[9989]: "test_VPN1" #46: STATE_MAIN_I1: retransmission; will wait 8 seconds for response

    이렇게 뜨면서 연결이 안되는 무엇일까요.. sg는 올오픈

    • JeongHyeongKim 2020.04.10 00:29 신고

      먼저 환경 변수 세팅(ip address, key 등등)이 제대로 되어있는지 확인해주시면 감사드려요!
      예전에 환경 변수를 잘못 세팅하니 서로 패킷을 주고받지 못하여, 패킷트레이서를 보면서 저 문제를 해결하였던 기억이 있습니다!
      만약 그래도 해결이 되지 않으신다면,
      괜찮으시다면 로그 일부분이 아닌 풀 로그를 정중하게 요청드립니다...!
      댓글이나 maladroit1@likelion.org로 캡쳐본을 보내주시면 함께 고민해보겠습니다 :)

+ Recent posts