sehee

도메인 등록을 위한 DNS 서비스를 변경하고 싶은 경우 퍼블릭 호스팅 영역의 이름 서버를 가져온다.

1) Route 53 console의 Hosted zones 내비게이션 바 클릭 > Hosted zone name 클릭

2) Hosted zone details의 Name servers 4개 저장

3) Route 53 console의 Domains - Registered domains 내비게이션 바 클릭

4) Actions - Edit name servers

5) 2)에서 저장한 name servers 입력 후 저장

[1] 퍼블릭 호스팅 영역에 대한 이름 서버 가져오기 - https://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/GetInfoAboutHostedZone.html

1. AWS VPC

VPC를 사용하면 논리적으로 격리된 가상 네트워크에서 AWS 리소스를 시작할 수 있다. 이 가상 네트워크는 AWS의 확장 가능한 인프라를 사용한다는 이점과 함께 고객의 자체 데이터 센터에서 운영하는 기존 네트워크와 유사하다.

서브넷: VPC의 IP 주소 범위, 단일 가용 영역에 상주

라우팅: 라우팅 테이블을 사용해서 서브넷 또는 게이트웨이의 네트워크 트래픽이 전달되는 위치를 결정

게이트웨이 및 엔드포인트: 게이트웨이는 VPC를 다른 네트워크에 연결, 인터넷 게이트웨이를 사용하여 VPC를 인터넷에 연결

피어링 연결: VPC 피어링 연결을 사용하여 두 VPC의 리소스 간 트래픽을 라우팅

VPC 흐름 로그: VPC의 네트워크 인터페이스로 들어오고 나가는 IP 트래픽에 대한 정보를 캡처

2. Security in VPC

보안 그룹: 리소스 수준(예: EC2 인스턴스)에서 특정 인바운드 및 아웃바운드 트래픽을 허용, 인스턴스를 시작할 때 하나 이상의 보안 그룹과 연결할 수 있다. VPC의 각 인스턴스는 서로 다른 보안 그룹 세트에 속할 수 있다.

네트워크 액세스 제어 목록(ACL): 네트워크 ACL은 서브넷 수준에서 특정 인바운드 또는 아웃바운드 트래픽을 허용하거나 거부한다.

흐름 로그: VPC의 네트워크 인터페이스에서 양방향으로 이동하는 IP 트래픽에 대한 정보를 캡처한다. VPC, 서브넷 또는 개별 네트워크 인터페이스에 대한 흐름 로그를 생성할 수 있다.

흐름 로그 데이터는 CloudWatch logs 또는 Amazon S3에 게시되며 과도하게 제한하거나 과도하게 허용하는 보안 그룹과 네트워크 ACL 규칙을 진단하는 데 도움이 된다.

트래픽 미러링: Amazon EC2 인스턴스의 탄력적 네트워크 인터페이스에서 네트워크 트래픽을 복사할 수 있다.

3. VPC Peering

VPC는 사용자의 AWS 계정 전용 가상 네트워크이다. AWS 클라우드에서 다른 가상 네트워크와 논리적으로 분리되어 있다.

VPC 피어링 연결은 프라이빗 IPv4 주소 또는 IPv6 주소를 사용하여 두 VPC 간에 트래픽을 라우팅할 수 있도록 하기 위한 두 VPC 사이의 네트워크 연결이다.

동일한 네트워크에 속하는 경우와 같이 VPC의 인스턴스가 서로 통신할 수 있다. 사용자의 자체 VPC 또는 다른 AWS 계정의 VPC와 VPC 피어링 연결을 만들 수 있으며, VPC는 상이한 리전에 있을 수 있다.

VPC의 기존 인프라를 사용하여 VPC 피어링 연결을 생성한다. 이는 게이트웨이도, VPN 연결도 아니며 물리적 하드웨어 각각에 의존하지 않는다. 그러므로 통신 또는 대역폭 병목에 대한 단일 지점 장애가 없다.

4. VPC Flowlogs

VPC 흐름 로그는 VPC의 네트워크 인터페이스에서 전송되고 수신되는 IP 트래픽에 대한 정보를 수집할 수 있는 기능이다. 흐름 로그 데이터가 게시될 수 있는 위치는 Amazon CloudWatch Logs, Amazon S3 또는 Amazon Data Firehose이다.

흐름 로그를 생성하면 구성한 로그 그룹, 버킷 또는 전송 스트림의 흐름 로그 레코드를 검색하고 볼 수 있다.

5. VPC PrivateLink

VPC에 인터넷 게이트웨이를 추가하여 인터넷 액세스를 허용하거나 VPN 연결을 추가하여 온프레미스 네트워크 액세스를 허용할 수 있다.

VPC의 클라이언트가 프라이빗 IP 주소를 사용하여 다른 VPCs의 서비스 및 리소스에 연결할 수 있도록 AWS PrivateLink 하려면 해당 서비스 및 리소스가 VPC에서 직접 호스팅된 것처럼 사용한다.

6. NAT Instance

NAT 인스턴스는 Network Address Translation(NAT)을 제공한다. NAT 인스턴스를 사용하면 프라이빗 서브넷의 리소스가 인터넷이나 온프레미스 네트워크와 같은 VPC 외부의 대상과 통신할 수 있다. 프라이빗 서브넷의 리소스는 인터넷으로 향하는 아웃바운드 IPv4 트래픽을 시작할 수 있지만 인터넷에서 시작된 인바운드 트래픽을 수신할 수는 없다.

NAT 인스턴스는 퍼블릭 인터넷에 있어야 하며, NAT 인스턴스에는 퍼블릭 IP 주소 또는 탄력적 IP 주소가 있어야 한다.

7. NAT Gateway

NAT 게이트웨이는 NAT 서비스로, 프라이빗 서브넷의 인스턴스가 VPC 외부의 서브넷에 연결할 수 있지만 외부 서비스에서 이러한 인스턴스와의 연결을 시작할 수 없도록 NAT 게이트웨이를 사용할 수 있다.

퍼블릭 - (기본값) 퍼블릭 서브넷의 인스턴스는 퍼블릭 NAT 게이트웨이를 통해 인터넷에 연결할 수 이지만 인터넷에서 원치 않는 연결을 수신할 수 없다. 퍼블릭 서브넷에서 퍼블릭 NAT 게이트웨이를 생성하고 생성 시 탄력적 IP 주소를 NAT 게이트웨이와 연결해야 한다.

프라이빗 - 프라이빗 서브넷 인스턴스는 프라이빗 NAT 게이트웨이를 통해 다른 VPC 또는 온프레미스 네트워크에 연결할 수 있다.

8. IPv6 migration

IPv4만을 지원하는 기존 VPC와 서브넷에서 IPv4만을 사용하도록 구성된 리소스가 있으면 VPC 및 리소스에 대한 IPv6 지원을 추가할 수 있다.

References: 

1. AWS VPC - http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Introduction.html

2. Security in VPC - http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Security.html
3. VPC Peering - http://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/Welcome.html
4. VPC Flowlogs - http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/flow-logs.html
5. VPC PrivateLink - http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-endpoints.html
6. NAT Instance - http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_NAT_Instance.html
7. NAT Gateway - http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-nat-gateway.html
8. IPv6 migration - http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-migrate-ipv6.html

특정 도메인을 담당하는 적절한 네임 서버로 DNS 쿼리를 전달하는 과정에서 DNS 쿼리를 해결하는 데 필수적인 권한 있는 네임 서버의 이름을 확인하기 위해 NS(네임 서버) 레코드를 참조한다.
이 특정 도메인에 대한 권한은 다른 네임 서버에 위임할 때 도메인의 권한 있는 네임 서버(실제 DNS 레코드를 갖고 있는 서버)인지 확인하기 위해 필요하며, 
해당 도메인이 신뢰할 수 있는지 확인하기 위해 각 도메인마다 DNS 레코드 관리를 담당하는 네임 서버가 존재한다.

예를 들어, 아래와 같이 'example.com'에서 레코드명 'sub.example.com'의 NS 레코드가 생성된 상태에서, 권한 있는 'sub.example.com' 도메인의 호스팅 영역을 찾기 위해 네임 서버가 아래와 같은 'sub.example.com' 호스팅 영역을 조회한다.

이 때, 하위 도메인 'sub.example.com'에 대한 네임 서버 변경이 가능한 경우 도메인의 고유한 권한을 확인할 수 없으므로, 상위 도메인 'example.com'의 'sub.example.com'에 대한 NS 레코드를 일치시켜야 한다.

References:

DNS에서 NS(이름 서버) 레코드의 기능은 무엇입니까? - https://ko.eitca.org/cybersecurity/eitc-is-wsa-windows-server-administration/system-administration-in-windows-server/resource-record-types/examination-review-resource-record-types/what-is-the-function-of-a-name-server-ns-record-in-dns/

Capturing Traffic

$ sudo tcpdump -i eth0 -nn -s0 -v port 80

-i eth0: eth0 인터페이스에서 패킷 캡처

-nn: 호스트명, 포트 번호를 DNS 리졸빙하지 않고 숫자로 표시

-s0: 패킷의 전체 내용을 캡처 (스냅샷 길이 제한 없음)

-v: 상세 출력 모드

port 80: HTTP 트래픽(80번 포트)만 캡처

$ sudo tcpdump -i eth0 -s0 -w test.pcap

-i eth0: eth0 인터페이스에서 패킷 캡처

-s0: 패킷의 전체 내용 캡처

-w test.pcap: 캡처한 패킷을 test.pcap 파일로 저장

$ sudo tcpdump -i eth0 -w /var/tmp/rotate.pcap -W 3 -C 10 -s 150 &

-i eth0: eth0 인터페이스에서 패킷 캡처

-w /var/tmp/rotate.pcap: 캡처 파일 저장 경로

-W 3: 최대 3개의 파일로 순환 저장

-C 10: 각 캡처 파일 크기를 10MB로 제한

-s 150: 각 패킷당 캡처할 바이트 수를 150으로 제한

&: 백그라운드에서 실행

터미널에서 pcap 내용 조회

tcpdump -r test.pcap -v

Create and Applying Filters

Statistics > Conversations - DisplayFilters

필터링하고 싶은 패킷 - Prepare as Filter

A → B 클릭 시

> ip.src==10.40.7.87 && tcp.srcport==58690 && ip.dst==17.57.145.151 && tcp.dstport==5223

Advanced Feature Color Traffic

View > Coloring Rules...

Decode

패킷 우측 Decode As..: Wireshark에서 패킷을 다른 프로토콜로 강제 해석(디코딩)하도록 하는 기능

- 비표준 포트 사용 시 (예: HTTP가 기본 80 포트가 아닌 8080 포트를 사용할 때)

Expert Information

Analyze > Expert Information

네트워크 트래픽을 분석하여 잠재적인 문제나 이상 징후를 감지

- Error (빨간색): 심각한 문제, TCP 재전송, 손상된 체크섬 등

- Warning (노란색): 잠재적 문제, TCP 윈도우 크기 0, 중복 ACK 등

- Note (파란색): 비정상적이지만 문제는 아닌 상황, TCP 윈도우 업데이트, 비표준 포트 사용 등

- Chat (회색): 일반적인 정보, TCP 연결 시작/종료 등

Interpret TCP Graphs

Statistics > I/O Graphs

시간에 따른 네트워크 트래픽을 그래프로 시각화하는 도구

Statistics > TCP Stream Graphs > Throughput

TCP 연결의 처리량을 시각화하여 보여주는 도구

Window Scaling

Win=1024

VPC DNS resolver 우선 순위

0. DNS firewall (R53 전용 Network Firewall)

1. Route 53 Resolver 규칙
   - 명시적으로 정의된 Outbound 규칙
   - 도메인 기반 포워딩 규칙

2. Private Hosted Zone
   - VPC와 연결된 프라이빗 호스팅 영역

$ dig example.com

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.13.9 <<>> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63355
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;saraheee.site.                 IN      A

;; AUTHORITY SECTION:
saraheee.site.          900     IN      SOA     ns-1536.awsdns-00.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

;; Query time: 1 msec
;; SERVER: 192.168.0.2#53(192.168.0.2)
;; WHEN: Thu Feb 06 07:15:42 UTC 2025
;; MSG SIZE  rcvd: 129

3. Default VPC Resolver
   - VPC의 기본 .2 리졸버

$ cat /etc/resolv.conf
options timeout:2 attempts:5
; generated by /usr/sbin/dhclient-script
search anycompany.corp
nameserver 192.168.2.250
nameserver 192.168.0.2

4. Public DNS resolve 시도 (Route 53 Public Hosted Zone 포함)

$ dig example.com
; <<>> DiG 9.18.28 <<>> example.com;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6753
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;saraheee.site.                 IN      A

;; ANSWER SECTION:
saraheee.site.          30      IN      A       8.8.8.8

;; Query time: 1610 msec
;; SERVER: 10.0.0.2#53(10.0.0.2) (UDP)
;; WHEN: Thu Feb 06 07:15:47 UTC 2025;; MSG SIZE  rcvd: 58

아웃바운드 엔드포인트가 구성된 Resolver 규칙이 있는 경우, 프라이빗 호스팅 영역과 동일한 VPC에 연결되어 있을 때 리졸버 규칙이 우선적으로 적용될 수 있다.

다만 Private hosted zone이 VPC 내부에서만 작동하는 DNS라, dig +trace 시 공개적인 DNS 해석 과정이 포함된 root DNS와는 독립적으로 작동한다.

# 최대 홉 수 조정

traceroute -m 255 google.com

$ traceroute -m 255 google.com         
traceroute to google.com (172.217.161.206), 255 hops max, 40 byte packets
 1  10.40.6.2 (10.40.6.2)  9.359 ms  4.503 ms  4.032 ms
 2  10.40.240.0 (10.40.240.0)  4.312 ms  7.856 ms  4.707 ms
 3  10.40.0.11 (10.40.0.11)  7.454 ms  4.417 ms  5.650 ms
 4  10.128.2.139 (10.128.2.139)  6.526 ms  4.745 ms  6.370 ms
 5  15.248.4.57 (15.248.4.57)  8.095 ms  7.118 ms  5.761 ms
 6  * * *
 7  * * *
 8  * * *
 9  99.82.179.80 (99.82.179.80)  33.133 ms  33.374 ms  33.518 ms
10  99.82.179.81 (99.82.179.81)  34.269 ms  33.815 ms
    99.82.179.83 (99.82.179.83)  30.787 ms
11  192.178.108.209 (192.178.108.209)  35.272 ms  34.049 ms
    216.239.59.149 (216.239.59.149)  27.305 ms
12  108.170.235.5 (108.170.235.5)  34.331 ms
    108.170.235.7 (108.170.235.7)  38.985 ms
    108.170.235.5 (108.170.235.5)  34.198 ms
13  kix07s03-in-f14.1e100.net (172.217.161.206)  33.920 ms  33.770 ms  33.259 ms

# 패킷 크기 조정

traceroute google.com 70

$ traceroute google.com 70
traceroute to google.com (172.217.161.206), 64 hops max, 70 byte packets
 1  10.40.6.2 (10.40.6.2)  11.566 ms  5.021 ms  5.796 ms
...

# 패킷 테스트 횟수 조정

traceroute -q1 google.com

$ traceroute -q1 google.com
traceroute to google.com (172.217.161.206), 64 hops max, 40 byte packets
 1  10.40.6.2 (10.40.6.2)  5.512 ms
...

# DNS 역방향 조회 건너뛰기

traceroute -n google.com

$  traceroute -n google.com
traceroute to google.com (172.217.161.206), 64 hops max, 40 byte packets
 1  10.40.6.2  7.717 ms  2.673 ms  3.887 ms
 2  10.40.240.0  5.463 ms  2.376 ms  3.898 ms
 3  10.40.0.11  4.332 ms  6.298 ms  4.902 ms
 4  10.128.2.139  4.251 ms  5.431 ms  3.800 ms
 5  15.248.4.57  7.327 ms  6.855 ms  5.558 ms
 6  * * *
 7  * * *
 8  * * *
 9  99.82.179.82  28.092 ms  28.069 ms
    99.82.179.80  33.980 ms
10  99.82.179.81  33.186 ms
    99.82.179.83  29.556 ms
    99.82.179.81  32.288 ms
11  192.178.108.209  36.233 ms
    216.239.59.149  27.248 ms
    192.178.110.61  27.490 ms
12  108.170.235.7  35.891 ms
    108.170.235.5  35.220 ms
    108.170.235.7  34.109 ms
13  172.217.161.206  33.306 ms  34.519 ms  32.720 ms

format:

hop_number host_name (IP_address) packet_round_trip_times

hop_number: 경유 순서

host_name: 호스트 이름 (역방향 조회 결과)

IP_address: IP 주소

packet_round_trip_times: 왕복 시간 (기본 3회 측정)

asterisks (*): 경로상 문제가 없음을 의미

Tutorial: Troubleshooting with Traceroute

https://www.youtube.com/watch?v=WL0ZTcfSvB4

How To Use Traceroute and MTR to Diagnose Network Issues

https://www.digitalocean.com/community/tutorials/how-to-use-traceroute-and-mtr-to-diagnose-network-issues

$ mtr google.com

$ mtr --report google.com

Layer 4: https://www.youtube.com/playlist?list=PLelEzczSdJkCukp60g0DOGr7aruKyS6Rs
Layer 5:
why TLS and SSL - https://www.youtube.com/watch?v=SJJmoDZ3il8
How the negotiation works - https://www.youtube.com/watch?v=n_d1rCXNrx0
RE:Invent talk about TLS - https://www.youtube.com/watch?v=8AODa_AazY4

1. Connection

1. run in the server mode

nc -l 2389

서버가 2389 포트에서 연결 대기 시작

-l: 리스닝 모드로 실행

2. used in client mode

nc localhost 2389

클라이언트가 서버의 2389 포트로 연결 시도, localhost (or 서버IP)

서버IP 확인

# private ip
ifconfig
ip addr

# public ip
curl ifconfig.me
wget -q0- ifconfig.me
(whatismyip.com)

# ipv6
curl -6 ifconfig.me

3. 통신 테스트

# at client side
HI, server
# displayed at server side
HI, server

클라이언트가 메시지 전송, 서버 측에서 동일한 메시지 수신 확인

특징: 양방향 통신, 텍스트 기반, 간단한 소켓 통신 테스트에 유용, 실시간 메시지 전송/수신

2. File Transfer

1. initial setup

# client side - Create source file
$ echo "hello test" > testfile
$ cat testfile
hello test

# server side - Empty destination file
$ touch test

클라이언트 측 testfile이라는 파일이 있고, 내용은 hello test

서버 측 빈 test 파일이 존재

수신된 데이터를 test 파일로 리다이렉션, 서버 측의 test 파일에서는 클라이언트가 보낸 "hello test" 내용이 저장됨

3. Timeout

-w 플래그를 통해 연결 타임아웃을 설정할 수 있음

# server side
nc -l 2389

# client side
nc -w 10 localhost 2389

4. IPv6 connect

-4 또는 -6 플래그는 netcat 유틸리티가 어떤 유형의 주소를 사용해야 하는지 지정한다.

(-4 없이 IPv4 주소를 적을 경우 연결 가능)

# server side
nc -4 -l 2389

# client side
nc -4 localhost 2389

5. Disable reading from STDIN

1) -d 플래그: stdin(표준 입력)에서 읽기를 비활성화

클라이언트에서 서버로 데이터 전송을 막음

(연결 수립 이후 텍스트 입력해야 함, 마지막 hi는 -d와 관계없이 무시됨)

2) -k 플래그: (keep listening) 서버 측 옵션, 클라이언트가 연결을 종료해도 서버는 계속 실행되어 새로운 클라이언트 연결 대기 상태 유지

→ 다중 클라이언트 연결 가능, 서버 수동 종료 전까지 계속 실행

3) -q 플래그: EOF(파일이나 데이터 스트림의 끝, 데이터 전송이 완료되었음을 알리는 시그널) 수신 후 5초간 대기

→ -w 플래그로 대체됨

# server side
nc -l 2389 > received_file.txt

# client side
 date; cat file.txt | nc -w 5 localhost 2389; date

4) -u 플래그: UDP 옵션 (서버와 클라이언트 모두 설정)

$ netstat -an | grep 2389
udp4 0 0 127.0.0.1.61430 127.0.0.1.2389
udp4 0 0 127.0.0.1.2389 127.0.0.1.61430

본인 IP 조회

curl ifconfig.me

1. 데이터베이스 계정에 RDS DB 인스턴스 및 RDS 프록시 생성

2. RDS Proxy 엔드포인트에 할당된 IP 주소 식별

- dig (proxy endpoint arn) 의 Answer section

3. 데이터베이스 계정에 PrivateLink 엔드포인트 서비스 생성

1) 데이터베이스 계정에 타겟 그룹 생성

2) 데이터베이스 계정에 Network Load Balancer 생성

3) 데이터베이스 계정에 VPC 엔드포인트 서비스 생성

4. 고객 계정에서 VPC 엔드포인트 생성

5. 연결 테스트

psql -h <db-endpoint> -p <port-number> -d <db-name> -U <username> -W

psql -h nlbdb-database-ee.cluster-c78suu4aug2x.us-east-1.rds.amazonaws.com -p 5432 -d nlbdb-database-ee -U postgres

References:

[] Connect to an AWS RDS PostgreSQL database using PSQL - https://onticdani.medium.com/connect-to-an-aws-rds-postgresql-database-using-psql-750c00b5ceb2

[] Access Amazon RDS across AWS accounts using AWS PrivateLink, Network Load Balancer, and Amazon RDS Proxy - https://aws.amazon.com/ko/blogs/database/access-amazon-rds-across-aws-accounts-using-aws-privatelink-network-load-balancer-and-amazon-rds-proxy/
[] Use Amazon RDS Proxy and AWS PrivateLink to access Amazon RDS databases across AWS Organizations at American Family Insurance Group - https://aws.amazon.com/blogs/database/use-amazon-rds-proxy-and-aws-privatelink-to-access-amazon-rds-databases-across-aws-organizations-at-american-family-insurance-group/