AWS-apple-MAC-instance

오오오오오오!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

macOS Catalina 10.15.7 버전을 쓸수있다.

뜨든... 인스턴스 유형은 베어 메탈뿐.. 그렇다고 해서 내가 안만들순없지 가즈아!!!!!

-_-;

전용 호스트가 필요하다....근데 전용 호스트 갯수는 not support 상태다 service quotas를 늘려야한다.

일단 바로 요청 근데 금방 안되나? 아마 지금 전세계에서 생성 중일거다..증가가 되면 바로 더 진행해 보겠다.

Maximum number of running dedicated mac1 hosts.

보류에서 할당량이 요청됨으로 변경됬다.

그리고 오늘 (12월2일) 요청은 허락되지 않고 기본 제공량이 3으로 변경됬다.

일단 전용호스트를 만들고, 인스턴스를 생성했다.

한방에 인스턴스가 전용호스트를 다 차지한다.

ssh -i linuxer.pem ec2-user@IP

ssh는 동일하게 ec2-user 계정으로 접근한다.

SSM을 이용한접근도 가능하다.

먼저 vnc 로 접근하는게 목적이므로brew로 vnc server 를 셋팅해야한다.

sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -allowAccessFor -allUsers -privs -all
sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -clientopts -setvnclegacy -vnclegacy yes 
sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -clientopts -setvncpw -vncpw supersecret
sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -restart -agent -console
sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate

https://gist.github.com/nateware/3915757

귀찮아서 이페이지 복붙했다. 위 명령어를 치면 vnc 가활성화 된다.

sudo dscl . -passwd /Users/ec2-user

명령어로 ec2-user의 패스워드를 설정한다.

그리고 VNC viewer 로 접속한다.

길고긴 여정을 지나 드디어.. 접속했다.

북미라 너무 느리다..-_-; VNC로 접속하기를 마무리한다.

AWS-managed-MQ-RabbitMQ-VPC-review

관리형 RabbitMQ가 나왔다.

짤방백업봇 on Twitter: "놀라울 만큼, 그 누구도 관심을 주지 않았다.… "

놀랄만큼 아무도 관심을 가지지 않았다. 안타깝....

그래서 내가 관심을 주기로 했다.

RabbitMQ VPC 설정을 확인해 보자!

생성모드는 단일과 클러스터 두가지가 있다. 단일구성부터 보자

퍼블릭엑세스는 VPC 내에 속하며 서브넷을 선택할수 있다.

프라이빗 엑세스를 선택해야 보안그룹를 선택할수 있다. 이게 가장 큰 차이점.
그리고 한번 퍼블릭으로 생성한 MQ는 영원히 퍼블릭이다. 프라이빗은 영원히 프라이빗..

그리고 이 포스팅을 시작하게 된 가장 큰 계기..

클러스터 모드에서 퍼블릭 엑세스를 사용한 RabbitMQ 는 VPC 외부에 만들어진다.

그냥 VPC 컨트롤하는 설정이 없다.

프라이빗으로 설정하면 VPC에 생성...

같은 RabbitMQ임에도 VPC 내부 / 외부 / 보안그룹 유 /무 접근제어 방식이 다른것이 인상적이었다. RDS와 같이 VPC 내부에 만들어져서 편리하게 전환할 수 있는 방식이 아니기에 생성 초기부터 명확하게 아키텍처를 구상해야 하는 것이다.

RabbitMQ의 VPC 설정은 변경이 불가능하다!!

읽어주셔서 감사합니다!

terraform-provider-ncloud-review

오늘 하시코프x네이버클라우드 웨비나에서 terraform 과 Vault 에 대한 웨비나를 청취했습니다.

https://github.com/NaverCloudPlatform/terraform-provider-ncloud

이전에 방과후(?) meetup에서 네이버클라우드가 테라폼의 프로바이더로 있다는것을 알았습니다. 그 덕분에 네이버클라우드에서 terraform은 이미 경험이 있는 상태고, Vault도 경험이 있었습니다. 오늘의 주제 중 Secrets Engines이 궁금했습니다.

https://www.vaultproject.io/docs/secrets

Secrets engines are components which store, generate, or encrypt data.

시크릿엔진은 데이터를 저장또는 생성하고 암호화하는 구성요소.

AWS 의 Parameter Store / Secrets Manager 와 비슷한 기능을 한다고 생각이 들었습니다. 다른 벤더에서도 비슷한 서비스들이 있습니다.

https://hackernoon.com/aws-secrets-manager-vs-hashicorp-vault-vs-aws-parameter-store-bcbf60b0c0d1

https://www.cloudjourney.io/articles/security/aws_secrets_manager_vs_hashi_vault-su/

가장 일반적인 사용예라 생각되는것은, access key의 암호화라 생각됩니다. 일반적으로 aws-vault 같은 명령어로 지원합니다.

아직 ncp-vault 가 만들어진게 아니라, ncp 내에서 사용하기엔 좀 불편한 부분이 있으리라 생각됩니다. 현재 npc 는 provider로 등록된 상태고 cli 를 지원하므로 차차 지원하리라 생각됩니다.

https://www.44bits.io/ko/post/securing-aws-credentials-with-aws-vault#%ED%85%8C%EB%9D%BC%ED%8F%BCterraform%EC%97%90%EC%84%9C-%EC%82%AC%EC%9A%A9%ED%95%98%EA%B8%B0

aws 에서의 vault 사용예입니다.

https://www.vaultproject.io/docs/secrets/databases/mysql-maria

mysql-maria db의 user 암호화입니다.

이런 방법이 필요한 이유는 결국 어플리케이션 소스의 탈취로 문제를 방지하기 위함입니다. key의 자동로테이션이나, expire time 을가진 key 발급등을 할 수 있습니다.

Vault 는 근래에 들어서 굉장히 핫한 오픈소스라 테스트 해보시는게 좋을것 같습니다.

마무리를 하자면..

템플릿 소스들이 점점 쌓이고 사용예가 늘면 IaC는 점점 더 일반화 될것입니다.

미리미리 IaC를 준비하고 사용방법을 익히는것도 좋을것 같습니다.

조만간 Secrets Engines 사용하기 위해 자동화 스크립트를 적용하는 고민을 한번 해보려 합니다. 시간이 나면 한번 테스트 해봐야겠습니다.

읽어주셔서 감사합니다!

linux-port-range-reuse

https://www.cyberciti.biz/tips/linux-increase-outgoing-network-sockets-range.html

https://meetup.toast.com/posts/55

http://docs.likejazz.com/time-wait/

tcp port range는 32768에서 61000까지다 대략 28000개의 가용포트가 있다는것이다.

클라이언트로서 28000개의 가용포트를 모두사용하게되면?

더이상의 새로운 TCP 세션을 생성할수 없게된다.

#tcp port range
echo 10240 60999 > /proc/sys/net/ipv4/ip_local_port_range

그래서 일단 10240 - 60999 개의 포트를 사용할수 있도록 수정해줬다.

예약포트들은 포통 10240 아래로 포진되어 있고, 61000 포트위로는 패시브 포트로 사용하는경우가 많으므로 일단 10240-61000포트를 사용할수 있도록 수정했다. 50000개 가량의 포트를 사용가능하도록 수정한거다.

그래도 해결이안되는듯 했다.

[root@linuxer ~]# netstat -an | grep TIME_WAIT | wc -l
51314

두배 이상의 port range 에도 처리가 불가능한 수준이었던것..

#tcp_timestamps 기본으로 이미 적용되어있음
$ sysctl -w ipv4.tcp_timestamps="1" 
#tcp reuse
$ sysctl -w net.ipv4.tcp_tw_reuse="1"

그래서 두가지 방법중 tw_reuse / tw_recycle 둘중 하나를 사용하려했다. reuse 옵션은 소켓재활용, recycle 은 강제로 TIME_WAIT인 포트를 종료하는거다. 좀 더 시스템에 영향을 덜주는 방법인 reuse를 선택했다.

-홀스님의 첨언

tw_recycle은 서버입장에선 문제가 생길수있으니 설정에는 반드시 주의가 필요하다.

일단은 처리를 했고, 서비스의 동작을 모니터링중이다.

모든옵션을 켜는 방법이다. 참고하길..tcp_tw_recycle옵션은 사용할때 꼭 주의 해야한다

sysctl -w ipv4.tcp_timestamps="1"
sysctl -w net.ipv4.tcp_tw_reuse="1"
sysctl -w net.ipv4.tcp_fin_timeout="10"

일단 이 방법은 좀 임시방편이고, 좀 더 확장성있는 방법으로 가기위해선 scale out을 해야한다.

또 추가하자면..

FIN_WAIT2 / TIME_WAIT 두가지의 TCP 파라미터가 60초의 기본시간을 가지게 되어서 총 2분의 대기시간을 가지게 된다. 컨트롤 할수있는 파라미터는 FIN_WAIT2 상대의 파라미터를 수정 하는경우도 있다고 한다. 수정할수 있는파라미터는 대부분 /proc/sys/net/ipv4 경로에 위치하니 하나씩 확인해 보자.

글을 다쓰고 추가로 내용을 덕지덕지 붙인거라 깔끔하지 않다.

하지만 도움이 되길 바란다!

마지막으로 php-mysql은 커넥션풀이 없다고 알고있었는데 라이브러리가 있었다.

https://bkjeon1614.tistory.com/216

아직테스트는 해보지 않은 상태고, 슬슬 해보겠다.

AWS-Load-balance-Failover-time-test

로드벨런서의 사용용도는 뭘까?

말그대로 부하분산을 위한 장치이다.

부하분산을 위해선 기본적으로 헬스체크가 되어야 하고 헬스체크 간격과 인터벌이 중요하다.

예를들어 인터벌30초에 헬스체크2회 라고하면 Failover 의 기대 시간은 59초인것이다.

시작 점 0초 에서 헬스체크를 성공후에 1초부터 어플리케이션이 문제가 생기게 되면 총59초의 간격동안 마지막 헬스체크가 실패하여야 Failover가 발생한다.

이론상으로 그런데.......이게 좀 이상했다.

기대시간에 NLB가 전혀 미치지 못했다. 나열해 보자면..

ALB의 최소 상태검사 시간이다. 인터벌5초 임계값2 총 9초안에 인스턴스의 unhealthy를 감지하고 트래픽의 라우팅을 멈춘다. ALB는 기대스펙과 동일하게 작동했다.

proxy 방식이라 당연히 그러하리라 생각했다. 문제가 생긴것은 NLB 였다.

NLB는 헬스체크 방식이 여러가지다. NLB의 대상그룹을 만들기 위해선 HTTP/HTTPS 가 아닌 프로토콜로 대상그룹을 생성하면 된다. 예를 들기 위해서 TCP를 사용했다.

상태 검사 프로토콜이 TCP 일 경우 인터벌 30초 임계값2가 최소 스펙이다. ALB에 비해 엄청나게 느린것이다. 이것을 짧게 수정하고 싶다면 상태검사 프로토콜을 HTTP로 해야한다. 대상그룹의 대상 프로토콜은 TCP로 하되 상태검사는 HTTP로 하는것이다. 대상과 상태검사의 프로토콜을 별도로 사용할수 있는것이다.

이제 10초의 인터벌 2회의 임계값을 가지게 되므로 19초에 페일오버가 되어야 한다.
그런데 이게 잘 안됬다.

!/bin/sh
date +"%y%m%d%H" >> $(date +"%y%m%d%H").txt
while true

do
STATUS=$(curl -# -o /dev/null -I -w %{http_code} -s -XGET http://test11-26d09f1385549f3c.elb.ap-northeast-2.amazonaws.com)

if [ $STATUS -eq 200 ]; then
echo 성공 >> $(date +"%y%m%d%H").txt
else
count=$(($count+1))
echo 실패 >> $(date +"%y%m%d%H").txt
fi
count=$(($count+1))
echo $count >> $(date +"%y%m%d%H").txt
sleep 1

done

위 스크립트로 1초마다 사이트를 호출해서 상태코드가 200이면 성공 그외엔 실패를 찍게된다. 그리고 1번 돌때마다 카운트를 1씩 더 한다.

1차 테스트 - 71초

6
실패
.
.
77
실패

2차 테스트 - 53초

6
실패
.
.
59
실패

이후 테스트들은 대부분 비슷한 시간 50~79초 사이에 페일오버 되었다.

전환시간은 최대 79초 까지 걸렸다. 여기서 NLB의 TTL을 확인해 봤다.

[root@linuxer home]# nslookup -type=cname -debug http://test11-26d09f1385549f3c.elb.ap-northeast-2.amazonaws.com
Server:         10.0.0.2
Address:        10.0.0.2#53

------------
    QUESTIONS:
        http://test11-26d09f1385549f3c.elb.ap-northeast-2.amazonaws.com, type = CNAME, class = IN
    ANSWERS:
    AUTHORITY RECORDS:
    ->  elb.ap-northeast-2.amazonaws.com
        origin = ns-679.awsdns-20.net
        mail addr = awsdns-hostmaster.amazon.com
        serial = 1
        refresh = 7200
        retry = 900
        expire = 1209600
        minimum = 60
        ttl = 33
    ADDITIONAL RECORDS:
------------

nslookup -type=cname -debug http://test11-26d09f1385549f3c.elb.ap-northeast-2.amazonaws.com

명령어로 확인시에 TTL 이 minimum = 60으로 페일오버될때 까지 ttl 이 모두 소모될때까지 기다려야 페일 오버가 가능하다. 조금 이해가 안가는 부분이 있는데..이부분은 AWS 내부로직이라 추측을 했다.

https://aws.amazon.com/ko/about-aws/whats-new/2018/02/network-load-balancer-now-supports-cross-zone-load-balancing/

Network Load Balancer relies on Domain Name System (DNS) to distribute requests from clients to the Load Balancer nodes deployed in multiple Availability Zones.

이내용을보면 DNS round robin 방식으로 여러개의 노드에 연결해주고 노드에선 다시 인스턴스에 연결해준다. 노드는 헬스체크에 따라 라우팅 하게되는데 노드의 TTL은 알수없으니 어느곳의 TTL로 인하여 페일오버의 지연이 발생하는지 알수없으나,

내가 원한 시간에 NLB는페일오버를 할수 없었다.

3rd party 의 LB 등 고민을 해봤으나 비용과 현실적인 문제로 페일오버의 기준을 맞추기 어려웠다. 그러던중 CLB 로 눈길이 갔다.

CLB는 http ~ tcp 까지 지원하는 이전 형식의 로드벨런서다.

CLB는 TCP 지원에 인터벌5초 임계값2로 9초로 페일오버가 되어야한다.

테스트 결과를 남기지 않아 아쉽지만 CLB는 기대치대로 동작하였다.

이 테스트 과정에서 얻은것이 몇가지 있다.

참고자료
  1. 우리는 ELB의 성능을 모두 알 수 없다. 어디서도 ELB의 max limite 를 공식적으로 발표한 자료가 없다.
  2. NLB 와 CLB의 성능적인 차이는 있다.
  3. 최저 헬스체크 타임은 ALB9초=CLB9초>NLB19초 순이다.

결론: CLB또한 쓸데가 있었다.

AI-speaker-identification-with-clovanote

오늘 클로바 노트 어플을 출시한걸 보고 사용해봤습니다.

클로바노트-아이폰

클로바노드-안드로이드

기능을 설명하자면 음성을 텍스트로 변환한다 ~ 이건 근래에 매우 일반화된 기능입니다.Speech Recognition 이라 합니다.
그런데, 이 어플은 음성->텍스트 변환 속도가 엄청나게 빠른것과 화자 구분기능이 있습니다. 화자 구분은 하나의 음성파일에서 각각 다른사람의 대화를 구분해주는 기능이죠.

이기능이 좋은이유는 장시간의 대화록에서 누가 어떤말을 했는지 각각 구분해 주므로 엄청난 편리성이 가미된것이죠.

위와같이 여러사람의 목소리를 구분해서 보여줍니다.

각각 벤더를 사용하시는 주변분들이 서비스에 대해 알려주셔서 찾아봤습니다.

NaverCloud

https://www.ncloud.com/product/aiService/clovaSpeech

Azure

https://azure.microsoft.com/ko-kr/services/cognitive-services/speaker-recognition/

GCP

https://cloud.google.com/speech-to-text/docs/multiple-voices?hl=ko

AWS

https://aws.amazon.com/ko/transcribe/

제가 AI의 트랜드와 기술력에 대해서 너무 몰랐다는 생각이 들었습니다.

각 벤더들마다 각자의 기술력으로 음성을 텍스트로 변환하고 화자구분기능을 모두 가지고있었습니다.

그러나, 이 아이디어 실제로 구현한다는건 많은 고민과 테스트가 필요할것으로 보입니다.

또한 번역API를 예로들면 파파고나 구글번역기의 정확도나 번역방식이 다르듯이 각나라의 음성을 텍스트로 변환하는 방식에서 쌓인 데이터에 의해 정확도가 다를것입니다.

그렇기에 현재는 네이버클로바의 정확도가 한글에 대해선 가장높지 않을까 예상됩니다.

어플덕분에 AI의 현기술의 변곡점과 치열한 벤더들간의 차이를 이해하게된 계기였습니다.

클로바노트의 건승을 기원합니다.

감사합니다.

naver-clovnote

https://apps.apple.com/gb/app/%ED%81%B4%EB%A1%9C%EB%B0%94%EB%85%B8%ED%8A%B8-ai-%EC%9D%8C%EC%84%B1%EA%B8%B0%EB%A1%9D/id1530010245

클로바노트앱 광고를 보고 바로 깔았다.

쓰자마자 생각이 들었다.

이거....미친거아냐?

와....................................할말이 없을정도로 대단한 어플이다.

그냥 단순히 음성녹음 -> 텍스트 변환이아니라

사용자마다 목소리를 확인해서 각자다른 사람으로 인식한다.

그래서

이런식으로 말한사람을 분리하여준다...그저 기술의 혁명이 쩐다..............................

진짜 엄청나네

K8s-CNI-정리

https://cloud.google.com/kubernetes-engine/docs/concepts/network-overview?hl=ko

오리뎅이 님의 쿠버네티스 네트워킹 PPT 자료입니다.

오리뎅이 님의 쿠버네티스 네트워킹 PPT 자료입니다.

두가지 URL로 CNI와 iptables의 연관 관계를 이해하고 정리 해보려한다.

CNI는 L2 / L3 / overlay 를 구성 및 k8s 의 네트워크을 관리한다.
이 때 k8s의 라우팅은 kube-proxy를 이용해서 iptables 룰을 관리한다.

iptables는 netfilter의 라우팅 룰을 편리하게 사용할수 있도록 만들어진 인터페이스고, 실제로는 패킷을 필터링하고 라우팅하는 역할은 netfilter가 맡게된다.

-_-;

ipvs 모드는 또 다시 생각해보자.

https://docs.projectcalico.org/networking/enabling-ipvs

일단 k8s 의 iptables_mode가 굉장히 비 효율적인 방법이라는건 알 수 있었다.

NCP-to-AWS-IPsec-multi-Cloud

NCP와 AWS 의 IPsec VPN을 연결해 보았습니다. Site to Site VPN을 연결하는 것입니다.

아직 NCP에서는 VPC 모드에서 IPsec VPN을 지원하지 않아서 Classic 모드에서 만 연결이 가능합니다.

NCP IPsec VPN Gateway 를 먼저 만들어야 AWS Customer Gateway 를 생성할수 있습니다.

NCP IPsec VPN Gateway 를 생성하기 위해선 Private Subnet 을 먼저 생성해야 합니다.
저는 192.168.1.0/24 로 생성했습니다.

Encryption : aes


D-H Group 은 NCP 에선 1/2/5만 지원합니다.

hash 는 sha 입니다.

확인 버튼을 누르면 생성됩니다.

확인된 IP는 49.236.139.115 입니다. 이 IP를 Customer Gateway에서 사용하시면 됩니다.

다음과 같이 CGW를 만들어 줍니다. 그다음 VGW를 생성해 줘야 합니다.
Virtual Private Gateway 는 VPC 에 붙이는 가상의 게이트 웨이로 CGW- tunnel -VGW 구성으로 통신하게 됩니다.

VGW는 생성하면 VPC에 Attach 해야 합니다.

VPN으로 사용하려는 VPC에 연결해 주세요.

이제 터널을 생성해야 합니다.

Site to Site VPN 메뉴에서 터널을 생성하면 됩니다.

미리 생성한 VPG와 CGW를 잘 넣어주시고 라우팅 옵션을 static 으로 설정합니다. BGP는 지원하지 않습니다.

정적라우팅 대역을 미리 추가해 주는게 편합니다.
Local IPv4 Network Cidr 는 NCP의 대역을 넣어주셔야 합니다.
Remote IPv4 Network Cidr cidr은 AWS 의 대역입니다.

Edit Tunnel 1 Options 을 체크해서 터널 옵션을 넣어줍니다.

Pre-Shared Key for Tunnel 1 에서 key 라고 표기하지만 VPN 인증시에 사용하는 값이라 패스워드처럼 취급되기도 하므로..저는 rkskekfk 로 설정했습니다.

위 옵션은 NCP IPsec VPN의 옵션에 맞춰서 체크한 옵션입니다. 모두 체크해도 문제는 없을듯합니다.

AWS는 DPD 옵션을 ikev2에서만 지원하므로 AWS VPN 자체에서 터널을 시작하는 기능은 NCP 와의 IPsec VPN 설정에선 사용할수 없는 설정입니다. 이유는 NCP의 IPsec VPN은 ikev1만 지원하기 때문입니다.

지금 설정에선 단일터널만 사용하려기에 tunnel 1만 설정해주려 합니다.

버튼눌러서 생성후엔 NCP의 IPsec VPN을 추가해야 합니다.

NCP 콘솔로 이동해서 AWS 의 터널 IP를 이용해서 터널링을 맺어줘야 합니다.

AWS 콘솔에서 VPN Tunnel Details 를 보면 Tunnel 1 의 IP를 확인할 수 있습니다.

이 아이피로 Peer IP로 사용해 연결할겁니다.

NCP 에서 Local Network 는 NCP의 Private Subnet Cidr입니다.

Remote Network 는 172.31.0.0/16 으로 AWS 의 네트워크 입니다.

위 이미지대로 선택해주세요.

사실 설명이 필요한 부분이 좀 있는데..과감히 생략합니다.
이유는 터널시작과 터널통신은 각각 인증방식을 사용하는데 이부분이 NCP는 나누어져서 설정하고 AWS 는 같이 설정합니다....그래서 그냥 따라서 해보시고 어려우면 댓글 남겨주세요.

생성하시면 굉장히 빠른속도로 생성됩니다. 아직 터널을 개시한 상태가 아니기 때문에 inactive 로 보일겁니다. 이때 터널의 상태를 확인할수 있는 방법이 있습니다.

메뉴에서

현재 상태를 확인할 수 있습니다.

인터페이스 / 라우팅 / IPsec VPN Tunnel 상태를 확인할수 있습니다.

There are no ipsec sas
There are no IKEv1 SAs

두줄의 메시지를 확인할수 있으며, 아직 터널이 UP상태가 아니기 때문입니다.

이제 인스턴스가 필요합니다.

네트워크 인터페이스에서 서버에 인터페이스를 붙이고 아이피를 부여해주세요.

다음과 같이 글로벌 비공인 IP와 추가한 Private Subnet IP가 보입니다.

인스턴스 내부에서 인터페이스를 설정해주세요.

cat <<EOF > /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
BOOTPROTO=static
ONBOOT=yes
#Private Subnet IP로 변경해주세요.
IPADDR=192.168.1.13
EOF
ifup eth1

이제 라우팅을 추가해야 합니다.

ip route add 172.31.0.0/16 via 192.168.1.1 dev eth1

추가 명령어 입니다.

 ip route del 172.31.0.0/16 via 192.168.1.1

라우팅을 잘못 넣게 되면 ip route del 명령어로 라우팅을 삭제할수 있습니다.
라우팅이 정상적으로 잘 연결되면 이제 AWS 에도 라우팅 테이블을 추가해야 합니다.

맨아랫 줄에 추가된 라우팅 테이블은 제일 먼저 만들었던 VGW 입니다.
이제 양방향으로 통신할 라우팅이 모두 만들어 졌고, 서로 통신할수 있도록 NCP 의 ASG와 AWS 의 SG를 열어주세요.

그리고 NCP의 인스턴스에서 ping 을 날려줍니다. AWS ikev1 은 DPD를 이용할수 없기 때문에 상태방에서 터널을 개시해야 합니다.

[root@s17596a9a6e6 ~]# ifconfig | grep inet
        inet 10.41.151.70  netmask 255.255.254.0  broadcast 10.41.151.255
        inet 192.168.1.13  netmask 255.255.255.0  broadcast 192.168.1.255
        inet 127.0.0.1  netmask 255.0.0.0
[root@s17596a9a6e6 ~]# ping 172.31.36.10
PING 172.31.36.10 (172.31.36.10) 56(84) bytes of data.
64 bytes from 172.31.36.10: icmp_seq=1 ttl=62 time=3.93 ms
64 bytes from 172.31.36.10: icmp_seq=2 ttl=62 time=3.45 ms
64 bytes from 172.31.36.10: icmp_seq=3 ttl=62 time=3.33 ms
64 bytes from 172.31.36.10: icmp_seq=4 ttl=62 time=3.44 ms

정상적으로 Site to Site VPN이 연결된것을 확인할수 있습니다.

이렇게 정상적으로 VPN이 연결 되면 AWS 콘솔에선 터널이 UP 상태가 되고,
NCP 콘솔에선 active 로 표시됩니다. 그리고 마지막으로 정상적으로 터널링이 맺어져서 통신이 되면 NCP 콘솔에서 아래와 같이 확인할수 있습니다.

KEv1 SAs:

Active SA: 1
Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1

1 IKE Peer: 3.34.211.29
Type : L2L Role : initiator
Rekey : no State : MM_ACTIVE
interface: outside
Crypto map tag: outside_map, seq num: 1, local addr: 49.236.139.115

access-list outside_cryptomap_1 extended permit ip 192.168.1.0 255.255.255.0 172.31.0.0 255.255.0.0
local ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (172.31.0.0/255.255.0.0/0/0)
current_peer: 3.34.211.29


#pkts encaps: 827, #pkts encrypt: 827, #pkts digest: 827
#pkts decaps: 764, #pkts decrypt: 764, #pkts verify: 764
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 827, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#TFC rcvd: 0, #TFC sent: 0
#Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
#send errors: 0, #recv errors: 0

local crypto endpt.: 49.236.139.115/0, remote crypto endpt.: 3.34.211.29/0
path mtu 1500, ipsec overhead 74(44), media mtu 1500
PMTU time remaining (sec): 0, DF policy: copy-df
ICMP error validation: disabled, TFC packets: disabled
current outbound spi: C7CCEEBF
current inbound spi : E2B83FD5

inbound esp sas:
spi: 0xE2B83FD5 (3803725781)
SA State: active
transform: esp-aes esp-sha-hmac no compression
in use settings ={L2L, Tunnel, PFS Group 2, IKEv1, }
slot: 0, conn_id: 264200192, crypto-map: outside_map
sa timing: remaining key lifetime (sec): 108
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
spi: 0xEED2584F (4006762575)
SA State: active
transform: esp-aes esp-sha-hmac no compression
in use settings ={L2L, Tunnel, PFS Group 2, IKEv1, Rekeyed}
slot: 0, conn_id: 264200192, crypto-map: outside_map
sa timing: remaining key lifetime (sec): 0
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
outbound esp sas:
spi: 0xC7CCEEBF (3352096447)
SA State: active
transform: esp-aes esp-sha-hmac no compression
in use settings ={L2L, Tunnel, PFS Group 2, IKEv1, }
slot: 0, conn_id: 264200192, crypto-map: outside_map
sa timing: remaining key lifetime (sec): 108
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
spi: 0xC47BC9E1 (3296446945)
SA State: active
transform: esp-aes esp-sha-hmac no compression
in use settings ={L2L, Tunnel, PFS Group 2, IKEv1, Rekeyed}
slot: 0, conn_id: 264200192, crypto-map: outside_map
sa timing: remaining key lifetime (sec): 0
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001

이 포스팅은 과정 자체만 설명하고 자세한 프로토콜이나, 인증방식은 설명하지 않았습니다.

사용자의 레벨에서 따라만 해도 VPN 터널링이 가능한 수준의 포스팅을 하려했으나, VPN이 조금 난이도가 있는거 같습니다.

진행하다가 궁금하신 부분은 댓글남겨주세요.

읽어주셔서 감사합니다.