VPC: 망분리 그리고 테스트
Last updated
Last updated
서브넷을 잘 구성 했는지 확인 하려면 어떻게 해야할까?
Port를 대상으로 테스트할 때는 "서버가 현재 정상적으로 구동 되고 있는지"를 확인한다.
"Port 는 한 개만 열었는데 어떻게 다수의 사용자가 연결할 수 있는걸까?"
소켓 은 file descriptor
, local ip
, local port
, remote ip
, remote port
등 5가지 정보를 활용하여 생성 된다.
이중 우리가 할당하는 포트인 local port
의 경우, 프로세스가 구동될 때 할당하기도 하고, /etc/services 를 보면 이미 known port로 지정되어 있기도 한다.
특정 프로세스 (가령, 8080 포트번호의 톰캣 서버)에 보내는 클라이언트의 요청은 remote port
를 제외하고 모두 동일하다.
remote port
는 client의 브라우저에서 요청 보낼 시 랜덤으로 지정하는 unknown port
이며 이로인해 요청을 구분할 수 있게 된다.
"하나의 프로세스(서버)에서 몇 개의 클라이언트와 연결이 가능할까?"
위 이미지 처럼 해당 프로세스에 별다른 제약이 없다면 기본적으로 생성할 수 있는 파일의 갯수가 제한되어 있다.
"소켓을 하나 더 두어 요청을 다른 포트 번호로 전달할 수는 없을까?"
192.168.0.1:80 포트로 요청을 전달 받아 192.168.0.1:8080 포트로 전달하여 프로세스가 처리할 수 있는데, 이를 "포트 포워딩" 이라고 한다.
주로 컨테이너 환경에서 많이 사용된다.
"Port 테스트가 실패하는 경우는 어떻게 해야할까?"
해당 테스트는 특정 URL에 대한 API 이상 유무를 확인할 수 있다.
example
"도메인 주소를 IP로 변환하는 과정 알아보기"
우선 /etc/hosts 파일에 정적으로 설정한 정보를 확인한다.
해당 파일은 사용자가 직접 등록할 수 있기 때문에 최우선으로 사용되며 해당 파일에 도메인 주소가 존재한다면 이를 그대로 활용한다.
로컬의 DNS Cache 를 확인해봅니다.
/etc/resolv.conf 에 설정된 정보를 기반으로 DNS 서버 에 질의합니다.
DNS 서버는 정보가 있으면 반환하고, 없으면 본인의 상위 DNS 서버 에게 질의하여 정보를 알아옵니다.
도메인에 해당하는 IP를 알게되면 DNS Cache 에 추가합니다.
Cache에 등록하게 되면 이후 요청부터 캐시를 활용해서 DNS 서버에 다시 질의하지 않는다
HTTP Status Code
를 기반으로 클라이언트에서 에러가 발생했는지, 서버에서 에러가 발생했는지 확인하고 디버깅하여 트러블 슈팅을 한다.
OSI 7Layer를 바탕으로 패킷이 네트워크 각 구간을 돌아다니는 것을 머릿 속으로 상상하는 습관을 들이면 여러 상황에서 트러블 슈팅 할 때 유리함
VPC 구성
192.168.0.0/24 (C Class)
서브넷 구성
192.168.0.0/26 public-a
192.168.0.64/26 public-c
192.168.0.128/27 internal-a
192.168.0.160/27 internal-c
IGW 구성
생성 및 미션을 위해 구성 된 VPC Attatch
NAT Gateway 구성
서브넷 연결(외부망 public a)
EIP 할당
VPC 연결
public-a 서브넷 연결
Prod EC2 인스턴스 프로비전
스펙: T2.Medium
보안그룹
내 IP SSH 포트 오픈
HTTPS Allow any 오픈
ICMP IPv4 Allow any 오픈
Public 라우팅 테이블과 인터넷 게이트웨이 연결
외부망 통신을 위해 0.0.0.0 대역으로 인터넷 게이트웨이 연결
내 IP로 접근이 가능하게 설정 된 운영 인스턴스 상태 체크
결과: 성공
VPC 연결
internal-a 서브넷 연결
DB EC2 인스턴스 프로비전
스펙: T2.micro
보안그룹
내 IP SSH 포트 오픈
외부망 SSH 포트 오픈
ICMP IPv4 Allow any 오픈
Elastic IP 할당
내 IP -> 외부망 접근 Ping 테스트
결과: 성공
외부망 -> 내부망 Ping 테스트
결과: 성공
외부망 라우팅 테이블 서브넷 설정
IGW 연결(외부망 통신)
public subnet 2개 연결
내부망 라우팅 테이블 생성 및 서브넷 설정
internal subnet 2개 연결
내부망 서버 공인 IP Ping 체크
결과: 실패
내부망 -> 인터넷망 접근 체크
결과: 실패
외부망 -> 내부망 telnet 테스트
결과: 성공
Internal 라우팅 테이블에 NAT GW 연결
내부망이 외부망과 통신을 위해 0.0.0.0 대역으로 NAT 게이트웨이 연결
내부망에서 라이브러리 업데이트를 통해 인터넷망 사용 여부 체크
외부망 443 Port listen 후 접근 확인
socket listen
sudo socket -s 443
테스트
telnet {IP} 443
내부망 서버의 공인 IP로 접근 테스트
내부망의 공인 IP Ping 테스트