라벨이 보안 그룹인 게시물 표시

두 VPC 연결하기: VPC 피어링 설정과 라우트 테이블 업데이트 완전 가이드

같은 계정, 같은 리전에 VPC가 두 개 있는데 서로 프라이빗 IP로 통신이 안 된다 — 이건 AWS를 처음 쓰는 팀이든 오래 쓴 팀이든 한 번씩은 마주치는 상황이다. VPC 피어링(VPC Peering) 자체는 단순하지만, 라우트 테이블과 보안 그룹까지 세 군데를 동시에 맞춰야 트래픽이 흐른다. 하나라도 빠지면 핑이 안 되고, 어디가 문제인지 찾는 데 시간을 쓰게 된다. TL;DR — VPC 피어링 핵심 요약 단계 작업 주체 핵심 포인트 1. 피어링 연결 요청 Requester VPC 상대 VPC ID 지정, 같은 계정이면 자동 수락 가능 2. 피어링 연결 수락 Accepter VPC 수락 전까지 트래픽 불가 3. 라우트 테이블 업데이트 양쪽 VPC 모두 상대 CIDR → pcx-xxxxxx, 양방향 필수 4. 보안 그룹 업데이트 양쪽 인스턴스 상대 CIDR 또는 SG ID 허용 5. 통신 검증 운영자 VPC Flow Logs 또는 ping/curl 확인 VPC 피어링이 동작하는 방식 VPC 피어링은 두 VPC 사이에 논리적인 1:1 네트워크 경로를 만든다. 인터넷 게이트웨이, NAT, VPN, 별도의 게이트웨이 장비가 전혀 개입하지 않는다. AWS 내부 네트워크를 통해 직접 라우팅되므로 트래픽이 공인 인터넷을 경유하지 않는다. 중요한 제약이 하나 있다. 피어링은 전이적(transitive) 라우팅을 지원하지 않는다. VPC-A ↔ VPC-B, VPC-B ↔ VPC-C가 각각 피어링되어 있어도 VPC-A에서 VPC-C로 VPC-B를 경유해 통신할 수 없다. 세 VPC가 모두 통신해야 한다면 각각 직접 피어링해야 한다. 또한 두 VPC의 CIDR 블록이 겹치면 피어링 자체가 생성되지 않는다. 설계 단계에서 CIDR 충돌을 반드시 확인해야 한다. graph LR subgraph V...

EC2 SSH 연결 시간 초과: 확인해야 할 보안 그룹(Security Group) 규칙

EC2 SSH 연결 시간 초과(Connection timeout)는 새 인스턴스를 시작할 때 가장 흔히 발생하는 장애물 중 하나입니다. 해결 방법은 거의 항상 보안 그룹(Security Group)의 인바운드 규칙이 누락되었거나 잘못 구성된 경우입니다. 요약 — 한눈에 보는 진단 단계 단계 확인할 사항 일반적인 해결 방법 1 보안 그룹(Security Group) 인바운드 규칙 사용자 IP로부터의 SSH (TCP 22) 추가 2 서브넷 라우팅 테이블(Route table) 0.0.0.0/0이 인터넷 게이트웨이(IGW)로 라우팅되는지 확인 3 네트워크 ACL(Network ACL) 규칙 인바운드 TCP 22 및 임시(ephemeral) 반환 포트 허용 4 인스턴스 퍼블릭 IP / 탄력적 IP(Elastic IP) 퍼블릭 IP가 할당되었는지 확인 5 키 페어(Key pair) 및 SSH 사용자 이름 올바른 프라이빗 키 및 AMI 전용 사용자 이름 사용 SSH 연결이 거부(Refused)되지 않고 시간 초과(Timeout)되는 이유 연결 거부(Connection refused) 오류는 TCP 핸드셰이크가 호스트에 도달했으나 대기 중인 서비스가 없음을 의미합니다. 반면 연결 시간 초과(Connection timed out) 오류는 패킷이 도달하지 못했거나 응답이 돌아오지 못했음을 의미합니다. EC2에서 이러한 무응답은 거의 항상 OS 수준의 문제가 아닌 네트워크 계층에서의 차단 때문입니다. 인스턴스 수준의 상태 저장(stateful) 방화벽인 보안 그룹(Security Group)이 가장 먼저 의심해야 할 빈번한 원인입니다. blockquote> 비유: 보안 그룹을 인스턴스 문 앞의 경비원이라고 생각해 보세요. SSH(포트 22)가 게스트 목록에 없으면 패킷은 거부 알림도 받지 못한 채 밖에서...