堆栈内存溢出
  简体   繁体   English

GCP：在应用 DNS 出站转发策略后，无法让 Compute Engine VM 联系特定的公共 DNS 名称服务器

[英]GCP: Can't get Compute Engine VMs to contact a specific public DNS name server after applying a DNS outbound forwarding policy

 原文  2022-04-26 12:20:29  4   1    google-cloud-platform/ dns/ google-cloud-dns

问题描述

TL;DR SOLUTION: DIG CANNOT BE USED TO VERIFY DNS FORWARDING POLICIES AS THE DNS RESOLUTION IS PERFORMED BY THE ROOT SERVERS TL;DR 解决方案：DIG 不能用于验证 DNS 转发策略，因为 DNS 解决方案由根服务器执行

I am trying to create a DNS outbound forwarding policy for forwarding DNS requests to a specific name server.我正在尝试创建一个 DNS 出站转发策略，用于将 DNS 请求转发到特定名称服务器。 It is going to be implemented in an on-prem setup, but I am currently just testing it with public DNS servers such as 1.1.1.1.它将在本地设置中实施，但我目前只是使用公共 DNS 服务器（例如 1.1.1.1）对其进行测试。 I have created the DNS outbound policy, but every request from inside VMs still uses the metadata server: 169.254.169.254我已经创建了 DNS 出站策略，但是来自 VM 内部的每个请求仍然使用元数据服务器：169.254.169.254

CURRENT SETUP: I have created a VPC, defined a su.net, and created a VM connected to this su.net.当前设置：我已经创建了一个 VPC，定义了一个 su.net，并创建了一个连接到这个 su.net 的 VM。

resource "google_compute_network" "vpc-hub" {
  name = "vpc-hub"

  depends_on = [
    google_project_iam_member.assign-roles,
    google_project_service.enable_apis
  ]
}

resource "google_compute_subnetwork" "vpc-subnet-hub" {
  name          = "vpc-subnet-hub"
  ip_cidr_range = "10.0.0.0/16"
  region        = "europe-west1"
  network       = google_compute_network.vpc-hub.id
  
  depends_on = [
    google_compute_network.vpc-hub
  ]
}

resource "google_compute_instance" "hub-vm" {
  name         = "hub-vm"
  machine_type = "e2-medium"
  zone         = "europe-west1-b"

  depends_on = [
    google_compute_subnetwork.vpc-subnet-hub
  ]

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-9"
    }
  }
  network_interface {
    subnetwork = google_compute_subnetwork.vpc-subnet-hub.name
    
    access_config {
    }
  }
  metadata_startup_script = file("${path.module}/startup_install.sh")
}

The startup-script installs dnsutils.启动脚本安装 dnsutils。 Additionally, I have defined a firewall rule to be able to connect to it via SSH:此外，我已经定义了一个防火墙规则，以便能够通过 SSH 连接到它：

resource "google_compute_firewall" "ssh-rule-hub" {
  name = "demo-ssh"
  network = google_compute_network.vpc-hub.name
  allow {
    protocol = "tcp"
    ports = ["22"]
  }

  source_ranges = ["REDACTED]

  depends_on = [
    google_compute_network.vpc-hub
  ]
}

ISSUE: I have created a DNS forwarding policy by specifying the public name server 1.1.1.1:问题：我通过指定公共名称服务器 1.1.1.1 创建了 DNS 转发策略：

resource "google_dns_policy" "dns-policy" {
  name                      = "dns-policy"
  enable_inbound_forwarding = false

  enable_logging = false

  alternative_name_server_config {
    target_name_servers {
      ipv4_address    = "1.1.1.1"
      forwarding_path = "default"
    }
  }

  networks {
    network_url = google_compute_network.vpc-hub.id
  }

  depends_on = [
    google_compute_network.vpc-hub
  ]
}

When I SSH into the VM and attempt to use dig to send a DNS request to any domain.当我 SSH 进入 VM 并尝试使用 dig 向任何域发送 DNS 请求时。 It always uses the internal metadata server within the compute engine - And thus does not use 1.1.1.1 to retrieve the IP. Instead the answer is always provided by the metadata server: 169.254.169.254.它始终使用计算引擎中的内部元数据服务器——因此不使用 1.1.1.1 来检索 IP。元数据服务器始终提供答案：169.254.169.254。 Why is this the case?为什么会这样？ Output from Dig can be seen below:来自 Dig 的 Output 如下所示：

bash command: dig google.com bash 命令：挖 google.com

; <<>> DiG 9.10.3-P4-Debian <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60323
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             300     IN      A       64.233.184.101
google.com.             300     IN      A       64.233.184.139
google.com.             300     IN      A       64.233.184.102
google.com.             300     IN      A       64.233.184.100
google.com.             300     IN      A       64.233.184.113
google.com.             300     IN      A       64.233.184.138

;; Query time: 18 msec
;; SERVER: 169.254.169.254#53(169.254.169.254)
;; WHEN: Tue Apr 26 12:09:53 UTC 2022
;; MSG SIZE  rcvd: 135

EDIT: output from bash command dig google.com +trace编辑：output 来自 bash 命令 dig google.com +trace

; <<>> DiG 9.10.3-P4-Debian <<>> google.com +trace
;; global options: +cmd
.                       510859  IN      NS      a.root-servers.net.
.                       510859  IN      NS      b.root-servers.net.
.                       510859  IN      NS      c.root-servers.net.
.                       510859  IN      NS      d.root-servers.net.
.                       510859  IN      NS      e.root-servers.net.
.                       510859  IN      NS      f.root-servers.net.
.                       510859  IN      NS      g.root-servers.net.
.                       510859  IN      NS      h.root-servers.net.
.                       510859  IN      NS      i.root-servers.net.
.                       510859  IN      NS      j.root-servers.net.
.                       510859  IN      NS      k.root-servers.net.
.                       510859  IN      NS      l.root-servers.net.
.                       510859  IN      NS      m.root-servers.net.
;; Received 239 bytes from 169.254.169.254#53(169.254.169.254) in 22 ms

com.                    172800  IN      NS      k.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
com.                    172800  IN      NS      l.gtld-servers.net.
com.                    172800  IN      NS      i.gtld-servers.net.
com.                    172800  IN      NS      e.gtld-servers.net.
com.                    172800  IN      NS      j.gtld-servers.net.
com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      f.gtld-servers.net.
com.                    172800  IN      NS      g.gtld-servers.net.
com.                    172800  IN      NS      d.gtld-servers.net.
com.                    172800  IN      NS      c.gtld-servers.net.
com.                    172800  IN      NS      m.gtld-servers.net.
com.                    172800  IN      NS      h.gtld-servers.net.
com.                    86400   IN      DS      30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com.                    86400   IN      RRSIG   DS 8 1 86400 20220510050000 20220427040000 47671 . hGerEs3N471ZCOosNSuakxBfxXh8H+qPP9UxVBakXvVfgLofu40+aNyw X9tfaNxmyFP7LUJDRBrURhNjN1cOdJhbTqa54AXvTlPbd31N5MRF3ZHT seJJLCe8Hv2UYLrnLSzAArpD2M+N0XI+3A6wR8/fE4/q0NULX0gpKxS9 Y/zHpr/Mu/2I8DLmI8sE411vSlK2MFxWj2LfQ0TAocjnmqkZQK9GfqQ4 IEDjcc2OV41JlxSKYtAy9OI3HJPfXcIrmo4aO9Qvoe1ZKn1fu46IUYpo zx1n5NgX4Ou8kOgjePMkpGMlvjLVY2KMxYdln7v4FCRB7mb1WsBp5H+3 3Sv7vQ==
;; Received 1170 bytes from 192.33.4.12#53(c.root-servers.net) in 10 ms

google.com.             172800  IN      NS      ns2.google.com.
google.com.             172800  IN      NS      ns1.google.com.
google.com.             172800  IN      NS      ns3.google.com.
google.com.             172800  IN      NS      ns4.google.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20220503042354 20220426031354 37269 com. vPwsL+I4ptKlrtrsZXrs/Z3/1Ebd3eBCm5f73FcuoljLz9RHDPdxfGCd rHmK3oWXZIErmCLYy6NgcpiMEM+JiqTQm/mNFhVfoFTGicCB9JwGgA3p XfgAB6w/hsNvtqTVuFsszhq4+CjXf1+ky0hFzTHACJ3bPmEeMa80ASwX EHu+vpL9LdLSZrtS68G2ieGvjrwcn6EZfmfJIly3i8UU9g==
S84BKCIBC38P58340AKVNFN5KR9O59QC.com. 86400 IN NSEC3 1 1 0 - S84BUO64GQCVN69RJFUO6LVC7FSLUNJ5 NS DS RRSIG
S84BKCIBC38P58340AKVNFN5KR9O59QC.com. 86400 IN RRSIG NSEC3 8 2 86400 20220504051944 20220427040944 37269 com. G/tnTZRrBZApHzz+bWDsUrDBa6PcH5O15adPaWvIlvIMe1FQUYFRJeMm pzJ586JzBfz5bE+5IjU0uAh6AnWrDVtryUig0CUpMVDn8mm8Axa9QTu/ 1h3hwE6HbKx/4d7hNpZIuKGH98iMKJLaYdfJHFLRV85/AOT9HdL2ihtF t2wOZ3Px0Wo6QVxpwth2hO2iLw0k/tszErnHw6BqxEAebQ==
;; Received 836 bytes from 192.41.162.30#53(l.gtld-servers.net) in 8 ms

google.com.             300     IN      A       142.251.5.101
google.com.             300     IN      A       142.251.5.113
google.com.             300     IN      A       142.251.5.100
google.com.             300     IN      A       142.251.5.138
google.com.             300     IN      A       142.251.5.102
google.com.             300     IN      A       142.251.5.139
;; Received 135 bytes from 216.239.32.10#53(ns1.google.com) in 1 ms

1 个解决方案

解决方案1
 3 已采纳  2022-04-27 07:38:26

The SERVER address 169.254.169.254 does not mean the server that responded. SERVER地址 169.254.169.254 并不表示响应的服务器。 That address is the metadata server that knows how to forward internal (project specify) and global domain names to the correct DNS server.该地址是元数据服务器，它知道如何将内部（项目指定）和全球域名转发到正确的 DNS 服务器。 That address is a virtualized service that provides a number of services such as DNS, DHCP, and NTP.该地址是一项虚拟化服务，可提供多种服务，例如 DNS、DHCP 和 NTP。

暂无
暂无

声明:本站的技术帖子网页，遵循CC BY-SA 4.0协议，如果您需要转载，请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

相关问题 通过公共 IP 地址获取 Azure FQDN（DNS 名称） - Get Azure FQDN (DNS Name) by Public IP Address GCP Compute Engine 全盘未在公共映像上调整文件系统大小 - GCP Compute Engine full disk not resized file system on public image 使用 CDK 创建 AWS EC2 实例后如何获取公共 DNS？ - How do I get public DNS after creating AWS EC2 instance with CDK? AWS Fargate 无法通过公共 DNS 名称访问应用程序 - AWS Fargate cannot access application over Public DNS name 无法从 EC2 公共 DNS 地址访问我的 HTTP 网站 - Can't access my HTTP website from EC2 Public DNS Address EC2 t2.micro 实例没有公共 DNS - EC2 t2.micro instance has no public DNS AWS 上的自定义 DNS 服务器 - Custom DNS server on AWS GCP Compute Engine 不会显示 memory 指标 - GCP Compute Engine won't show memory metrics AWS中如何让新主机继承私有dns域名自动形成FQDN？ - How can I get new hosts to inherit the private dns domain name to automatically form an FQDN in AWS? AWS 网络负载均衡器：为什么内部 NLB 会有公共 DNS 名称？ - AWS Network Load Balancer: why would an Internal NLB have a public DNS name?
相关标签
 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM