☰

문제

tag-icon • tag-icon vpn bind internal-dns ufw wireguard
문제

문제

프라이빗 FQDN을 사용하여 서버에 액세스해야 하는 VPC가 있습니다. VPC는 와이어가드 VPN을 통해 액세스할 수 있습니다. VPN 서버는 BIND9를 실행하는 DNS 서버 역할도 합니다. 이에 따라 개인 영역으로 DNS 서버를 설정했습니다.지도 시간. VPC 내부에서 DNS는 예상대로 작동하며 DNS 영역에 정의된 FQDN을 통해 서버에 연결할 수 있습니다.

VPN 터널을 통해 VPC에 연결할 때 개인 DNS 서버를 사용하도록 VPN 클라이언트를 설정했지만 해당 FQDN을 확인할 수 없습니다. VPN 클라이언트가 내 개인 DNS 서버를 사용한다는 것을 알고 있습니다. 실행하면 nslookup google.com아래 결과를 볼 수 있듯이 내 DNS의 IP 주소가 표시되기 때문입니다.

Server:     10.118.0.2
Address:    10.118.0.2#53
...

VPN 터널을 통해 VPC에 연결된 시스템에서 를 실행하면 nslookup myprivate.domain.comNXDOMAIN을 수신하고 에서도 마찬가지이며 ping오류와 함께 실패합니다 Name or service not known. 그러나 VPC의 프라이빗 IP 주소에 대해 ping을 실행하면 작동합니다. 따라서 가 myprivate.domain.com서버의 에서 호스팅되는 경우 10.118.0.3IP 주소에서는 ping이 성공하지만 FQDN에서는 실패합니다.

또한 VPC 내부에 있을 때와 VPN을 통해 연결된 머신에 있을 때의 발굴 결과를 확인하세요. dig dev.myprivatedomain.com ns: FROM VPC:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51703
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 9dccc02158dee7f70100000061a7e0a1ce2597e377b9c301 (good)
;; QUESTION SECTION:
;dev.myprivatedomain.com.       IN  NS

;; AUTHORITY SECTION:
nabuinternal.com.   604800  IN  SOA ns1.myprivatedomain.com. ...

;; Query time: 0 msec
;; SERVER: 10.118.0.2#53(10.118.0.2)
;; WHEN: Wed Dec 01 20:52:49 UTC 2021
;; MSG SIZE  rcvd: 93

VPN에서:

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 57158
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;dev.myprivatedomain.com.       IN  NS

;; AUTHORITY SECTION:
com.            900 IN  SOA a.gtld-servers.net. nstld.verisign-grs.com. 1638392201 1800 900 604800 86400

;; Query time: 44 msec
;; SERVER: 10.118.0.2#53(10.118.0.2)
;; WHEN: Wed Dec 01 15:57:05 EST 2021
;; MSG SIZE  rcvd: 122

둘 다 동일한 DNS 서버를 사용하지만 VPN에서 요청하면 개인 도메인에 대한 권한이 반환되지 않습니다.

결론적으로, 몇 시간 동안 조사한 후에도 VPN을 통해 VPC에 연결하는 클라이언트가 내 프라이빗 DNS에서 정의한 FQDN을 확인할 수 있도록 누락된 것이 무엇인지 파악하기가 부족했습니다.

추가 정보

  • 서버는 우분투 20.04 LTS입니다.
  • 바인드 9:BIND 9.16.1-Ubuntu (Stable Release)
  • wireguard: wireguard-tools v1.0.20200513wirespeed를 통해 설치됨
  • UFW 활성화

VPC의 VPN 및 DNS 서버 IP는 입니다 10.118.0.2.

VPN 주소 풀은 10.99.0.0/16다음과 같은 방식으로 BIND9 구성을 설정했습니다.

acl "trusted" {
    10.118.0.2;    # the vpn and dns server
    ...
    10.99.0.0/16;  # vpn address pool
    
};
options {
    directory "/var/cache/bind";
    listen-on-v6 { any; };
    recursion yes;
    allow-recursion { trusted; };
    listen-on { 10.118.0.0/20; 10.99.0.0/16; };  
    allow-transfer { none; };
    forwarders {
            8.8.8.8;
            8.8.4.4;
    };
};

영역은 다음과 같이 구성됩니다.

$TTL    604800
@       IN      SOA     ns1.myprivatedomain.com. admin.myprivatedomain.com. (
                              9         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;                         
; name servers - NS records
    IN      NS      ns1.myprivatedomain.com.

; name servers - A records
ns1.myprivatedomain.com.          IN      A       10.118.0.2

; 10.118.0.0/20 - A records
dev.myprivatedomain.com.            IN      A      10.118.0.4
staging.myprivatedomain.com.         IN      A      10.118.0.3

그리고 역방향 영역 파일:

$TTL    604800
@       IN      SOA     ns1.myprivatedomain.com. admin.myprivatedomain.com. (
                              7         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
; name servers - NS records
    IN      NS      ns1.myprivatedomain.com.

; PTR Records
2.0   IN      PTR     ns1.myprivatedomain.com.         ; 10.118.0.2
4.0   IN      PTR     dev.myprivatedomain.com.         ; 10.118.0.4
3.0   IN      PTR     staging.myprivatedomain.com.      ; 10.118.0.3

UFW는 TCP와 UDP 모두에 대해 포트 53을 허용하도록 설정되어 있습니다.

또한 UFW에는 VPN의 트래픽을 허용하는 이전 규칙이 있습니다.

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.99.0.0/16 -o eth1 -j MASQUERADE

이전 규칙은 클라이언트가 VPN 터널에 연결하고 개인 DNS 서버를 사용할 수 있도록 설정되었습니다. 이 규칙이 없으면 DNS 주소를 Google과 같은 공개 주소로 설정하지 않으면 인터넷에 액세스할 수 없습니다. 나는 조사 중에 이 규칙을 발견했지만 아직 방화벽 구성에 대해 잘 알지 못하며 그 의미를 완전히 이해하지 못합니다. 이는 내 목표에 더 가까워지는 데 도움이 되었지만 이에 대해 더 읽어볼 필요가 있습니다.

다음은 Wireguard VPN 클라이언트 구성입니다.

[Interface]
...
DNS = 10.118.0.2
Address = 10.99.0.2/16

[Peer]
...
AllowedIPs = 10.99.0.0/16, 10.118.0.0/20

업데이트: 해결 방법

Wireguard 서버는 이를 패키지화하고 추가 서비스(웹 인터페이스, 간편한 설정)를 제공하는 다른 소프트웨어를 통해 설치되었습니다. 단점은 Wireguard 서버 구성을 거의 제어할 수 없다는 것입니다.

결과적으로 소프트웨어를 제거하고 Wireguard를 수동으로 설치하게 되었고, 이를 통해 특히 라우팅 규칙이 내 VPC 설정과 작동하도록 VPN을 올바르게 설정할 수 있었습니다. VPN 터널의 트래픽을 VPN 인터페이스에서 퍼블릭 인터페이스 대신 VPC 프라이빗 인터페이스로 라우팅해야 했습니다. 이로 인해 DNS 서버 및 영역 구성을 수정하지 않고도 문제가 해결되었습니다.

관련 정보