🔹 DHCP란?
Dynamic Host Configuration Protocol
동적 호스트 구성 프로토콜
TCP/IP 네트워크의 모든 장치는 통신하기 위해 IP 주소가 필요하다.
과거에는 IP 주소를 각 장치에 수동으로 할당해야 했다.
오늘날에는 DHCP를 사용하여 DHCP 서버에 의해서 동적 및 자동으로 각 장치에 IP 주소가 할당된다.
DHCP 서버를 사용하여 IP 주소 및 관련된 기타 구성 세부 정보를 네트워크의 DHCP 사용 클라이언트(장치 또는 호스트를 의미)에게 동적으로 할당하는 방법을 제공한다.
EC2 인스턴스에서 실행되는 Application은 필요에 따라 Amazon DHCP 서버와 통신하여 IP 주소 임대 또는 기타 네트워크 구성 정보(Amazon DNS 서버의 IP 주소, VPC에 있는 라우터의 IP 주소 등)를 검색할 수 있다.
DHCP option set를 사용하여 Amazon DHCP 서버가 제공하는 네트워크 구성을 지정할 수 있다.
Application이 Amazon IPv6 DHCP 서버에 직접 요청해야하는 VPC 구성이 있는 경우 다음 사항에 유의해야한다.
dual-stack subnet의 EC2 인스턴스는 IPv6 DHCP 서버에서만 IPv6 주소를 검색할 수 있다.
DNS 서버 이름이나 도메인 이름과 같은 추가 네트워크 구성은 IPv6 DHCP 서버에서 검색할 수 없다.
IPv6 전용 서브넷의 EC2 인스턴스는 IPv6 DHCP 서버에서 IPv6 주소를 검색할 수 있으며 DNS 서버 이름 및 도메인 이름과 같은 추가 네트워킹 구성 정보를 검색할 수 있습니다.
Amazon DHCP 서버는 접두사 위임을 사용하여 VPC의 네트워크 인터페이스에 전체 IPv4 또는 IPv6 접두사를 제공할 수도 있다.
DHCP 응답에는 IPv4 접두사 위임이 제공되지 않습니다. 인터페이스에 할당된 IPv4 접두사는 IMDS를 사용하여 검색할 수 있다.
🔹 AWS DHCP options set
이제부터 편의상 DHCP Option Set을 DHCP라고 부르겠다.
AWS Root 계정을 생성하면 Default 리소스가 생성되어있는 서비스들이 있다.
DHCP도 마찬가지로 각 Region 당 하나의 DHCP가 생성되어있다.
이 DHCP를 Default DHCP라고 부르겠다.
Default DHCP
- 사용자가 생성한 DHCP가 아니라 AWS에서 자동으로 생성한 DHCP
- 설정은 아래와 같음
| 속성 | 값 |
| domain-name-servers | AmazonProvidedDNS |
| domain-name | 리전.compute.internal |
- Default DHCP를 삭제할 수 있는가?
- Yes - Default DHCP를 삭제해버렸습니다. 새로 생성하려면?
- VPC를 하나 생성하면 자동으로 생성된다.
- 사용자가 Default 설정과 동일하게 생성해도 Default DHCP라고 인식하지 않는다.
DHCP의 작동 방식
DHCP의 구성은 어디에 어떻게 영향을 미칠까?
DHCP 구성은 VPC 내 생성되는 서버들의 네트워크 정보에 영향을 준다.
EC2를 예로 들어보겠다.
예시1
- 가정
- Default DHCP를 사용하는 VPC에 EC2 생성한다.
- Default DHCP 구성은 아래와 같다.
: domain-name: ap-northeast-2.compute.internal
: domain-name-servers: AmazonProvidedDNS- 확인
- EC2의 /etc/resolv.conf 파일을 열어보면 아래와 같음nameserver 172.31.0.2 search ap-northeast-2.compute.internal
예시2
- 가정
- 사용자가 생성한 Custom DHCP를 사용하는 VPC에 EC2 생성한다.
- Custom DHCP 구성은 아래와 같다.
: domain-name: intns.example.co.kr
: domain-name-servers: 165.1.1.1- 확인
- EC2의 /etc/resolv.conf 파일을 열어보면 아래와 같음nameserver 165.1.1.1 search intns.example.co.kr
예시를 보면 알 수 있듯이 DHCP 구성은 EC2 내 /etc/resolv.conf 파일 내용에 영향을 준다.
그렇다면 /etc/resolv.conf가 뭔지 알아야하는데 /etc/resolv.conf를 알아보자를 보고 오길 바란다.
/etc/resolv.conf를 알아보자 글을 읽고 왔다면 DHCP와 resolv.conf 간 관계가 이해가 됐을 것이다.
MWAA도 마찬가지이다.
MWAA는 Airflow라는 오픈소스를 AWS에서 Managed Service로 내놓은 서비스이다.
MWAA를 생성할 때, VPC를 선택하게되는데 선택한 VPC에 네트워크 및 컴퓨팅 리소스가 생성된다.
VPC 내부에 리소스가 생성되기 때문에 해당 리소스들도 DHCP에서 설정한 네트워크 설정을 따른다.
따라서 Custom DHCP를 사용하는데 Nameserver를 이상하게 지정할 경우, VPC 내에 있는 여러 서비스들에 Nameserver 관련 장애를 유발할 수 있다.
🔹 Q&A
1. VPC에서 사용중인 DHCP를 삭제할 수 있나요?
No. VPC에서 사용중인 DHCP는 삭제할 수 없다.
DHCP를 삭제하기 위해서 모든 VPC에서 해당 DHCP를 사용하지 않도록 조치해야한다.
2. 사용자가 EC2에 접속하여 /etc/resolv.conf를 변경했다. 이러면 DHCP와 값이 달라지는데 어떻게 되나요?
재부팅을 하지 않아도 일정 시간이 지나면 DHCP와 일치하도록 원복된다.
참고로 systemctl restart systemd-resolved.service와 같은 명령어를 실행하면 바로 원복된다.
재부팅을 해도 바로 원복된다.
3. 특정 서버만 DHCP와 다르게 구성하고 싶은데 가능할까요?
자세히 읽어보지는 않아서 잘 모르겠는데 가능한 것 같다.
아래 문서 확인해보길.
고정 DNS 서버로 EC2 인스턴스 구성 | AWS re:Post (repost.aws)
🔹 조언 및 시행착오
특별한 이유가 없다면 Default DHCP를 사용하자!
Default DHCP에서 사용하는 Name Server인 AmazonProvidedDNS가 참 중요하다.
해당 Name Server를 이용해야만 AWS에서 제공하는 Private DNS를 사용할 수 있다.
AWS에서 인프라를 구축하다보면 보안상의 이유로 VPC endpoint를 사용하여 인터넷망을 거치지 않고 AWS 내부망을 사용하여 통신하도록 구축한다.
이때, Custom DHCP를 사용할 경우 VPC Endpoint로 통신하도록 구성하고 관리하기 쉽지 않다.
따라서 AWS를 이용한다는 장점을 극대화하기 위해서라도 굳이 Custom DHCP를 써야하나 싶다.
특수한 경우가 아니라면 Default DHCP를 사용할 것을 권장한다.
예를들어 VPC에서 CodeCommit 서비스에 Private하게 접근하기 위해서 Interface 타입의 VPC Endpoint를 생성했다.
그러면 VPC에서 이전에는 Public DNS를 사용했었는데 AWS에서 제공하는 Private DNS를 사용하게된다.
Private DNS는 AmazonProvidedDNS Name Server를 통해서 Private IP를 받을 수 있게된다.
그런데 AmazonProvidedDNS를 사용하지 않고 사용자가 별도로 구축한 Custom DNS를 사용하게되면
Custom DNS에서는 AWS에서 제공하는 Private DNS의 정보를 모른다.
결국 VPC 내 서버들은 Private DNS에대한 정보가 있는지 모르기 때문에 기존과 동일하게 Public DNS를 사용하게된다.
즉, VPC Endpoint가 생성되더라도 Private하게 통신하지 않고, 인터넷 구간을 통해서 통신을 하게된다.
사실 Interface 타입의 VPC Endpoint를 생성할 때, Custom DNS 관리자가 노가다로 입력하면 어찌저찌 잘 굴러갈지도 모른다. 하지만 Private DNS를 사용하는 서비스가 VPC Endpoint 외에도 더 있을 수 있고, 주기적으로 IP가 변동될지도 모른다. VPC Endpoint를 삭제했다가 다시 재생성하기라도하면 IP 변경되는데 그것도 관리해줘야한다. DNS 관리자가 어떻게 변경을 감지하고 동기화할 것이며, 프로그램을 만들어서 자동 감지를 한다고하더라도, 변경하는 찰나에 시스템에 영향을 줄 수 있기 때문에 권장하지 않는다.
AWS Support 문의 당시 DNS 서버에서 Conditional forwarding 설정을 하고, AWS Account에서 inbound Route 53 resolver를 생성해서 해결할 수 있다고하는데...
아래는 시스템 구축 당시 AWS DHCP를 잘 모르던 상태였고, 고객사에서 다른 AWS 환경 시스템에서도 Custom DHCP 사용을 표준으로 가져가고 있으니 제공해드린 값과 똑같이 설정해달라고해서 제공받은 값으로 똑같이 설정했다가 네트워크 문제가 발생해서 AWS Support에 문의를 올렸던 내용이다. 실제 구축 당시 결국 AmazonProvidedDNS를 사용하기로 결정해서 상세 구축은 어떻게 해야할지는 모르겠다. 참고 정도로 보면 좋을 것 같다.
문의 내용
나는 DHCP Option set을 새로 생성했고, Nameserver, search 값을 우리 회사에서 구축한 네임 서버와 도메인을 사용하도록 설정했습니다. VPC는 새로 생성한 DHCP Option set을 사용합니다.
VPC 엔드포인트를 생성했는데 트래픽이 VPC 엔드포인트(=Private IP)가 아닌 인터넷(=Public IP)으로 라우팅는 것을 확인하였습니다.
Default DHCP Option set으로 변경해보니 이번에는 VPC 엔드포인트로 라우팅되었습니다.
AWS에서 제공하는 Name Server(=AmazonProvidedDNS)를 사용하지 않으면 자동으로 VPC 엔드포인트로 라우팅되지 않나요?
엔지니어와 채팅
(요약/번역)(E:엔지니어 / 나:글쓴이)
E: 귀하의 사례 메모를 검토한 결과 귀하가 자체 DNS 서버를 사용할 때 VPC 인터페이스 엔드포인트로 향하는 트래픽이 인터넷으로 전달되고 AmazonProvidedDNS를 사용할 때 트래픽이 예상대로 VPC 인터페이스 엔드포인트로 전달되는 것을 확인했습니다. 맞나요?
나: 맞습니다.
E: VPC 인터페이스 엔드포인트를 생성하면 프라이빗 IP를 사용하여 네트워크 인터페이스가 생성되고 DNS 정보는 AmazonProvidedDNS에서만 사용할 수 있습니다. 예를 들어 DHCP 옵션 세트에서 AmazonDNS를 사용하는 경우 EC2는 VPC 엔드포인트 이름을 프라이빗 IP로 확인하고 트래픽은 로컬 경로를 사용하여 VPC 인터페이스 엔드포인트로 직접 라우팅됩니다. Custom DNS 서버를 사용하는 경우 VPC 인터페이스 엔드포인트 ENI가 존재하는지 모르므로 호스트 이름(예: git-codecommit)을 확인하면 퍼블릭 엔드포인트 IP로 확인되고 트래픽이 인터넷으로 라우팅됩니다.
E: 해결책은 다음과 같습니다. DHCP 옵션 세트에서 자체 DNS 서버를 사용하려면 git-codecommit.ap-norteast-2.amazonaws.com에 대한 요청을 AmazonProvidedDNS(VPC CIDR의 .2)로 전달하려면 DNS 서버에서 DNS
forwarder rule을 생성해야 합니다. 이를 Conditional forwarding이라고 합니다. 당신은 DNS Server 관리팀에 Conditional forwarding 구성을 요청해야합니다.
나: Conditional forwarding이란 것은 DNS 서버쪽에 설정하는 것인가요? AWS 계정에서도 추가 작업이 필요합니까? VPC와 네임서버는 DX를 통해 연결되며 네임서버는 온프레미스에 있습니다.
E: Conditional forwarding은 DNS 서버쪽에서 설정해야하고, AWS 계정에서는 AWS VPC에서 inbound Route 53 resolver를 생성해야 합니다.
참고: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-forwarding-inbound-queries.html
VPC 내에 인바운드 엔드포인트를 생성하고 온프레미스 DNS 서버가 DNS 요청을 전달할 프라이빗 IP 주소를 생성해야합니다. 구성되면 VPC 인터페이스 엔드포인트를 프라이빗 IP로 성공적으로 확인할 수 있습니다.
나: 네임서버가 온프레미스에 있는데도 inbound Route 53 resolver를 생성해야하나요?
E: 예, DNS 서버가 온프레미스 네트워크에 있는 경우 DX 연결을 통해 AWS의 인바운드 엔드포인트에 연결할 수 있습니다. 이미 DX를 통한 네트워크 연결이 있으므로 온프레미스의 Conditional forwarding와 AWS VPC의
inbound Route 53 resolver 엔드포인트만 있으면 됩니다.
나: S3 게이트웨이 유형 엔드포인트가 이름 서버와 관련이 있습니까?
E: No, it does not
나: S3 엔드포인트는 라우팅 테이블에 추가되므로 문제가 되지 않는 것 같습니다.
E: 네 맞습니다
채팅 종료 후 엔지니어의 요약 정리 답변(번역)
고객님께서 VPC의 DHCP 옵션 세트에서 자체 DNS 서버를 사용하실 때 DNS 해결과 관련된 쿼리에 관해 문의해 주셨습니다. 자체 DNS 서버를 사용하는 경우 VPC 인터페이스 엔드포인트로 향하는 트래픽이 인터넷으로 전달되고 AmazonProvidedDNS를 사용하는 경우 트래픽이 예상대로 VPC 인터페이스 엔드포인트로 전달됩니다.
채팅 중에 VPC 인터페이스 엔드포인트를 생성하면 프라이빗 IP로 네트워크 인터페이스가 생성되고 DNS 정보는 AmazonProvidedDNS에서만 사용할 수 있다는 점을 알려드렸습니다.
예를 들어, DHCP 옵션 세트에서 AmazonProvidedDNS를 사용하고 호스트 이름 'git-codecommit.ap-northeast-2.amazonaws.com'을 확인하려고 하면 EC2 인스턴스가 AmazonProvideDNS(.2)로 DNS 쿼리를 보냅니다. ) 그리고 .2 해석기는 VPC 인터페이스 엔드포인트 정보를 인식하므로 VPC 엔드포인트 이름을 프라이빗 IP로 확인하고 트래픽은 로컬 경로를 사용하여 EC2에서 VPC 인터페이스 엔드포인트로 직접 라우팅됩니다.
예를 들어, DHCP 옵션 세트에서 AmazonProvidedDNS를 사용하고 호스트 이름 'git-codecommit.ap-northeast-2.amazonaws.com'을 확인하려고 하면 EC2 인스턴스는 AmazonProvideDNS(.2) 에 DNS 쿼리를 보내고 '.2' resolver는 VPC 인터페이스 엔드포인트 정보를 인식하므로 , VPC 엔드포인트 이름을 프라이빗 IP로 확인하고 트래픽은 로컬 경로를 사용하여 EC2의 VPC 인터페이스 엔드포인트로 직접 라우팅됩니다.
자체 DNS 서버를 사용하는 경우 VPC 인터페이스 엔드포인트 ENI가 존재하는지 여부를 알 수 없으므로 호스트 이름(예: 'git-codecommit.ap-northeast-2.amazonaws.com')을 확인하면 퍼블릭 엔드포인트로 확인됩니다. IP와 트래픽은 인터넷으로 라우팅됩니다.
DHCP 옵션 세트에서 자체 DNS 서버를 사용하려면 다음 단계를 따라야 합니다.
1단계. VPC에 Route 53 resolver inbound endpoint[1]를 생성합니다. 인바운드 엔드포인트는 네트워크의 DNS 해석기가 DNS 쿼리를 전달할 IP 주소(VPC에 사용 가능한 IP 주소 범위 중)를 지정합니다.
2단계. 온프레미스 네트워크와 AWS VPC 간에 프라이빗 연결이 필요합니다. (이미 DX 연결이 있으므로 이 단계를 건너뛸 수 있습니다.)
3단계. 온프레미스 DNS 서버에서 Conditional forwarding[2]을 생성하고 hotsname 'git-codecommit.ap-northeast-2.amazonaws.com'에 대한 DNS 요청을 1단계에서 생성된 인바운드 엔드포인트 IP 주소로 전달합니다.
위 단계를 수행하면 EC2 또는 온프레미스 네트워크의 프라이빗 IP 주소에 대한 VPC 인터페이스 엔드포인트를 확인할 수 있습니다.
References:
[1] https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-forwarding-inbound-queries.html
[2] https://www.readandexecute.com/how-to/server-2016/dns/configure-dns-forwarders-windows-server-2016/
참고로 위에서 언급된 것처럼 S3 Gateway 타입의 VPC Endpoint는 Interface를 생성하지 않고, prefix list를 생성하고 라우팅 테이블에 prefix list를 규칙으로 추가하여 라우팅하기 때문에 DHCP Nameserver 구성과 관련이 없는 것으로 보인다.
🔹 참고
- AWS DHCP Option set 공식 문서
https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/DHCPOptionSetConcepts.html
- Window 서버에서 Conditional forwarding 참고 자료
https://www.readandexecute.com/how-to/server-2016/dns/configure-dns-forwarders-windows-server-2016/