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/216 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이 조금 난이도가 있는거 같습니다.

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

읽어주셔서 감사합니다.

k8s-cmd

yum install bash-completion -y
source <(kubectl completion bash)
echo "source <(kubectl completion bash)" >> ~/.bashrc

kubectl apply -f 파일명
kubectl apply -k ./경로

kubectl create -f 파일

kubectl get node
kubectl get pods
kubectl get pods --all-namespaces
kubectl get service
kubectl get events
kubectl get pv
kubectl get pvc
kubectl get pc

kubectl delete -f 파일명
kubectl delete -k 파일명

k8s-Centos7-install

#!/bin/sh
setenforce 0
sed -i --follow-symlinks 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/sysconfig/selinux
swapoff -a
modprobe br_netfilter
echo '1' > /proc/sys/net/bridge/bridge-nf-call-iptables
yum install -y yum-utils device-mapper-persistent-data lvm2
yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
yum install -y docker-ce
cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF

yum install -y kubelet kubeadm kubectl
systemctl enable docker
systemctl enable kubelet
sed -i 's/cgroup-driver=systemd/cgroup-driver=cgroupfs/g' /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf

K8s centos7 base install

userdate 등에 넣고 쓸수있다.

#Master 에서 작업

kubeadm init --pod-network-cidr=사용하려는 pod cidr
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

kubeadm join token 이 나오면 cluster node 에서 join 해준다

AWS-CloudFront-custom-header-ALB-filter

https://www.notion.so/CloudFront-ALB-f0086dec48b64f0883e0c6de5fd9da4c

Noah.Seo 님의 이야기를 받아서 다른방법을 테스트하게 되었다.

4번째 방법이 번득 떠오른탓.

그럼 내가 생각하는 부분은 이렇다.

CloudFront -> ALB

끝...3번 방법은 WAF에서 X-Origin-Verify Custom Header 를 필터링 한다. ALB에서도 비슷한 기능이 있는바. 나는 이전부터 ALB에서 내 블로그 도메인이 아닌 ALB 도메인이나 IP로 접근하는것을 제한한 바가 있다.

이 규칙이 바로 그것이다. Host 조건에 따라 Host가 다르면 아무 대상이 없는 blackhole 로 전달하게 된다. 그렇다. Custom Header를 ALB에서 필터링 할거다.

CloudFront 에서 Origin 을 수정한다.

단점은 ALB의 부하가 올라간다는것. 규칙에 의해 LCU 사용량이 증가할수 있다는 점이다.

그럼 셋팅해 보자.

X-Origin-Verify 헤더 네임을 추가하고 Value 로 test를 추가한다.

그리고 ALB의 규칙을 추가한다. 도메인 기반하여 http 헤더가 일치하면 라우팅. 그렇지않으면 두번째 규칙에 의해 blackhole로 전달한다. 지금 현재 정상적으로 헤더가 일치하여 사이트가 뜨는 상태다.

https://www.linuxer.name/

로 접근해보면 503에러가 발생하는것을 볼수있다.

재미있는 테스트 거리를 주신 Noah.Seo 님께 감사를 드린다.

Amazon CloudFront Origin Shield-Review

Origin Shield 가 출시 되었다.

Origin 에 전달되는 리퀘스트의 횟수를 줄여 관리비용을 줄인다고 한다.

먼저 캐싱율을 보자.

70%대다.

개판이다..이게 어떻게 변할까?

Origin Shield Region 으로 서울리전을 선택했다.

설정자체는 어려울게 하나도 없고 일단....

기다려 봐야겠다.

그리고 하루정도 지난상태로 포스팅 쓰는것을 이어간다.

먼저 어제의 히트율

21 ~ 22일의 히트율.

22 ~ 23일 오? 효과가 있다.

더 모니터링 이후 내용을 추가하겠다.

오후에 추가한 내용 오...히트율이 엄청올라간다. 만세! 유효한 효과가 있음을 확인하였다.

DNS-spf-google

spf 레코드는 RFC 4408 의해서 255 characters으로 제한된다.

하나의 레코드가 255 characters 라는 이야기다.

그래서 255 characters 이상을 쓰려면 어떻게 해야할까? 그것을 구글의 사용 예를 들어서 설명하고자 한다.

google.com text = "v=spf1 include:_spf.google.com ~all"

_spf.google.com 도메인을 include 하고 _spf.google.com 도메인을 쿼리하면

_spf.google.com text = "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"

_netblocks.google.com
_netblocks2.google.com
_netblocks3.google.com

세개의 도메인을 알려준다. 세개의 도메인은 각각의 역할에 따라 ipv4나 ipv6를 응답한다.

_netblocks.google.com text = "v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all"

_netblocks2.google.com text = "v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all"

_netblocks3.google.com text = "v=spf1 ip4:172.217.0.0/19 ip4:172.217.32.0/20 ip4:172.217.128.0/19 ip4:172.217.160.0/20 ip4:172.217.192.0/19 ip4:172.253.56.0/21 ip4:172.253.112.0/20 ip4:108.177.96.0/19 ip4:35.191.0.0/16 ip4:130.211.0.0/22 ~all"

이렇게 2단계의 include를 거쳐서 255 characters 이상의 레코드를 구성한다.

그렇다면 A recode로 spf 를 관리하려면 어떻게해야 할까?

https://spam.kisa.or.kr/filemanager/download.do?path=spam/customer/archive/&filename=SPF%EA%B8%B0%EC%88%A0%EB%AC%B8%EC%84%9C.pdf

linuxer.name text = "v=spf1 a:_1.linuxer.name ~all"

바로 이런식이다 include: 부분을 a: 로 변경하는것이다.

그리고.. spf 레코드는 사용하는 대역이나 ip를 알려주는것 외에 정책을 정하는 역할을 하는데 다음과 같은 규칙이 적용된다.

Neutral (?) 출판된 데이터에 근거해 판단을 내릴 수 없음
Pass (+) 가 인가되어진 발송서버로 확인됨
Fail (-) 가 인가되어지지 않은 발송서버로 확인됨
Softfail (~) 는 인가되지 않은 발송서버이나 “Fail” 정책의 적용은 유보함.

linuxer.name text = "v=spf1 a:_1.linuxer.name +all"

이런식이면 _1.linuxer.name a 레코드로 등록된 IP는 인가된 발송서버로 확인된다는 의미다.

오랜만에 spf 레코드를 다시 복습하면서 정보진흥원의 문서를 보며 감탄 또 감탄했다.

위의 문서를 꼭 보시라!

시작하는 엔지니어를 위해


먼저 제소개를 하자면, 시스템엔지니어로 10년차, AWS를 다룬지는 3년이 됐습니다.

요즘 시스템 엔지니어로 시작을 꺼리는 분들이 많습니다.

이유는 클라우드가 급 부상 하고 있기 때문입니다. 물어보면 대부분 클라우드 엔지니어를 하고싶다. 말합니다. 그런데 클라우드 엔지니어는 뭐고, 시스템 엔지니어는 뭐길래 이렇게 이야기가 많을까요?

그럼 두 직군의 차이부터 한번 이야기해봐야 할거 같습니다.

시스템 엔지니어는 클라우드가 생기기 이전부터 시스템 전반을 책임지는 역할로, 주로 셋팅과 구성 그리고 트러블슈팅을 맡아서 하던 직군입니다.

클라우드 엔지니어는 클라우드를 가지고 인프라를 구성하고 트러블 슈팅을 합니다.

어? 뭐가 다른거죠? 궁금하실 텐데요. 사실 별반 다르지 않습니다. 시스템 엔지니어가 클라우드를 사용해서 시스템을 구축할수도 있는거고 클라우드 엔지니어가 지원을 위해 온프렘의 서버를 보기도 해야합니다.

사실 이 두 직군의 차이는 시작 지점이 어디에 있냐의 차이일 뿐 하는일의 근본적인 차이는 없습니다. 그렇다면 뭘 배워야 하고, 뭘해야 할지가 중요할텐데요.

먼저 리눅스가 중요합니다. 정말 중요합니다.

클라우드 엔지니어로 시작하게 되면 리눅스를 깊게 다루지 않게 됩니다. 이유는 클라우드 플랫폼 내에서 기술지원을 하기때문에 중점적으로 배우는것은 플랫폼의 사용법과 구성인것입니다. 거기에 lock-in 이 발생하게 됩니다. 보통 lock-in 이라 하면 다른 플랫폼으로 떠날수 없는 서비스나 사이트를 말하는것인데, 이 문제점이 사람에게도 발생하는 것입니다. 이부분이 나쁘다는건 아닙니다. 저도 AWS를 정말 좋아하니까요. 하지만, 제공되는 서비스만 사용해서는 사용자 이상으로 나아갈 수 없게됩니다. 그래서 언제든, 탈 플랫폼을 하기위해선 유연하게 여러 솔루션을 사용하고 배우는 기반이 있어야 합니다.

그것이 바로 엔지니어 에겐 리눅스입니다. 그럼 리눅스로 뭘해야 할까요?

일단 명령어에 익숙해 져야 합니다. 리눅스의 상태를 확인하고, 프로세스의 상태를 확인할수 있는 방법을 알아야 합니다.

그 다음은 로그를 보고 서비스를 확인할 수 있어야 합니다. 이전의 엔지니어가 여기까지 했다면 요즘의 엔지니어는 로그를 가공하고 지표로서 사용할 수 있는 능력까지 길러야 합니다.

너무 두루뭉실 했나요? 그럼 기업에서 요구하는 사항으로 예를 들어볼까요?

https://bighit.recruiter.co.kr/app/jobnotice/view?systemKindCode=MRS2&jobnoticeSn=29431

선호 자격 요건입니다.

Tomcat, Nginx, IIS, DB, Mail, DNS 등 구축 및 운영 관리 경험을 보유한 분
Shell Script & Query 사용 경험이 있는 분
네트워크, 방화벽, VPN등 네트워크 및 보안에 대한 이해도가 높은 분
IaC (Infra as a code)등의 구축 경험 및 OSS 등의 솔루션 사용 경험이 있는 분

사실 선호 자격이라 적었지만, 선호자격이라기 보단 10년차 IT 인프라 운영 직무에 있는 사람에겐 반드시 겪었어야 하는 과정의 요건일 겁니다.

그럼 정리해볼까요.

클라우드 엔지니어와 시스템 엔지니어는 시기상의 문제입니다.
결국 엔지니어는 IT 인프라를 다루는 포지션이 될것입니다.

배워야하는 순서라면 시스템의 코어인 리눅스부터 네트워크까지를 전체로 다우는 교육이 좋습니다.

기본이 튼튼하면 클라우드도 금방 배울수 있습니다.

그럼 빅히트의 요강을 보고 배워야 하는 우선 순서를 알아볼까요.

  1. Tomcat, Nginx, IIS, DB, Mail, DNS 등 구축 및 운영 관리
  2. Shell Script
  3. 네트워크, 방화벽, VPN등 네트워크 및 보안
  4. EC2, RDS, Aurora, CF, Cloudformation 등 다양한 클라우드 인프라 서비스
  5. IaC (Infra as a code)등의 구축 경험 및 OSS 등의 솔루션

이정도 순서로 배워야할것들을 정할수 있습니다. 서비스부터 점점 인프라까지 배우는것이죠.

한번에 모두를 다할순 없으니 시간이 될때마다 개념이라도 알아두시는게 좋습니다.

그럼 이만 시작하는 엔지니어를 위한 짧은 글을 마치겠습니다.

linux-lsof

사이트 확인중 이상 증상이 있는 고객이 있었다.

사용량이 많아지면 mysql.sock 에러가 발생하는 것이었다.

apache 에서 mysql 접속시 socket을 생성한다는건 일반적으로 접속을 Localhost 로 설정해야 하는데, local의 database를 사용하지 않는 상태였다.

socket을 사용하는 에러를 찾기위해 lsof 를 먼저 사용했다.

lsof | grep sock
httpd 15233 apache 5u sock 0,7 0t0 658393448 can't identify protocol
httpd 15250 apache 3u sock 0,7 0t0 658393444 can't identify protocol
httpd 15250 apache 5u sock 0,7 0t0 658393448 can't identify protocol
httpd 15258 apache 3u sock 0,7 0t0 658393444 can't identify protocol
httpd 15258 apache 5u sock 0,7 0t0 658393448 can't identify protocol
httpd 15312 apache 3u sock 0,7 0t0 658393444 can't identify protocol
httpd 15312 apache 5u sock 0,7 0t0 658393448 can't identify protocol
httpd 15314 apache 3u sock 0,7 0t0 658393444 can't identify protocol
httpd 15314 apache 5u sock 0,7 0t0 658393448 can't identify protocol

can't identify protocol mysql.sock 문제가 아니라 apache 의 sock 문제가 발생하고 있었다.

can't identify protocol 는 소켓이 완전히 닫히지 않거나 누수가 있다고 판단되는데, 확인이 필요했다. 요인은 openfile 갯수나 여러가지 요인이 있을거라 생각해서 먼저 openfile을 확인했다.

ulimit 로 확인한 openfile 갯수는 1024와 일단 수정해 줬다.

echo "* soft nofile 65535" >> /etc/security/limits.conf
echo "* hard nofile 65535" >> /etc/security/limits.conf
ulimit -Hn 65536
ulimit -Sn 65536

cat /proc/net/sockstat
sockets: used 261
TCP: inuse 17 orphan 0 tw 44811 alloc 54 mem 49
UDP: inuse 5 mem 15
UDPLITE: inuse 0
RAW: inuse 0
FRAG: inuse 0 memory 0

sockstat 를 확인시에 현재는 문제가 되는 상태는 아니었다.

이 조치 이후 추가적인 모니터링을 진행할 것이다.