Ubuntu 18.04.4를 실행하는 컴퓨터가 있습니다. 두 개의 LAN 인터페이스 enp3s0과 eno1이 있습니다. 전자는 LAN 네트워크의 3G 모뎀에 연결되고 후자는 다른 네트워크의 위성 모뎀에 연결됩니다. 네트워크 관리자는 구성 파일의 연결 확인 설정을 통해 인터페이스의 우선 순위를 설정하는 일을 담당합니다. 예를 들어 3G 적용 범위가 없으면 eno1 인터페이스 메트릭은 기본값에 20000을 추가하여 저하됩니다. 위성 enp3s0도 마찬가지입니다. eno1의 기본 우선순위가 더 높습니다(두 연결 모두 활성화됨). DNS는 systemd-resolved로 처리되고 systemd-networked 두 인터페이스는 3G 및 위성 모뎀 주소 및 DNS에서 실행되는 DHCP 서비스에서 IP를 얻습니다. : IP 192.168.200.101 (DNS/GW: 192.168.200.101) - 이 주소는 MAC 주소 할당을 통해 영구적으로 할당됩니다. eno1: IP 192.168.55.xxx (DNS/GW: 192.168.55.1)
어쨌든 첫 번째 인터페이스에 제공된 DNS 서버 주소는 두 번째 인터페이스보다 우선합니다. 예를 들어 enp3s0에 인터넷이 연결되어 있지 않고 인터넷 트래픽이 192.168.55.1로 라우팅되는 경우 이름 확인은 여전히 192.168.200.1을 통해 시도되지만 분명히 실패합니다. eno1의 동적으로 할당된 DNS를 /etc/systemd/network/eno1.network에 추가된 정적 DNS로 교체해 보았습니다.
[Match]
Name=eno1
[Network]
DNS=8.8.8.8
DNS=8.8.4.4
그러나 시스템은 여전히 이름 확인을 위해 192.168.200.1을 사용하는 것을 선호합니다. /etc/systemd/resolved.conf에 전역 폴백 DNS를 추가했지만 이를 고려하더라도 도움이 되지 않는 것 같습니다.
[Resolve]
#DNS=
FallbackDNS=8.8.4.4
#Domains=
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
#Cache=yes
#DNSStubListener=yes
내가 달성하고 싶은 것은 192.168.200.1을 DNS 서버로 사용하는 것뿐만 아니라 두 번째 인터페이스와 연결된 DNS 서버를 사용하면 작동하지 않지만 방법을 찾을 수 없는 경우에 대비하는 것입니다. 제가 이해한 바는 이것이 첫 번째 DNS가 구성된 방식과 관련이 있다는 것입니다. 도메인 할당에서 이를 얻었고 인터넷에서 이름의 주요 소스로 만드는 것으로 의심되지만 제가 꿈꾸는 것일 수도 있습니다. 이에 대한 조언을 주시면 감사하겠습니다. 기본적으로 두 DNS를 모두 작동시키려면 어떻게 해야 합니까? 다음은 ~(두 번째 iface에 할당된 Google DNS)가 표시된 해결 상태 출력입니다.
Global
DNSSEC NTA: 10.in-addr.arpa
16.172.in-addr.arpa
168.192.in-addr.arpa
17.172.in-addr.arpa
18.172.in-addr.arpa
19.172.in-addr.arpa
20.172.in-addr.arpa
21.172.in-addr.arpa
22.172.in-addr.arpa
23.172.in-addr.arpa
24.172.in-addr.arpa
25.172.in-addr.arpa
26.172.in-addr.arpa
27.172.in-addr.arpa
28.172.in-addr.arpa
29.172.in-addr.arpa
30.172.in-addr.arpa
31.172.in-addr.arpa
corp
d.f.ip6.arpa
home
internal
intranet
lan
local
private
test
Link 15 (tun0)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 14 (veth2e5ae19)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 12 (veth5b411fa)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 10 (br-b950c350c024)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 9 (docker0)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 8 (can0)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 7 (wlp1s0)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 6 (wwp0s20u6i10)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 5 (wwp0s20u6i8)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 4 (enp3s0)
Current Scopes: DNS
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 192.168.200.1
DNS Domain: ~.
rig
Link 3 (enp2s0)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 2 (eno1)
Current Scopes: DNS
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 8.8.8.8
8.8.4.4
답변1
용어 상 systemd-resolved
DNS 도메인 필드에 접두사가 붙은 도메인은 ~
"이 도메인을 시스템 전체 기본 DNS 서버에 직접 쿼리합니다. 이 도메인에 대해 링크별 DNS 서버를 사용하지 마십시오."를 의미합니다. 조합은 ~.
동일하지만 루트 DNS 도메인의 경우 .
모든 DNS 도메인에 대한 암시적 접미사입니다.
그러나 문제는 시스템 전체의 기본 DNS 서버가 없는 것 같습니다. 링크별 DNS 서버만 구성합니다. FallbackDNS=
예다른 DNS 서버 정보가 알려지지 않은 경우에만 사용됩니다.resolved.conf(5)
, 매뉴얼 페이지 에 따르면 . eno1
와 는 모두 enp3s0
각 링크에 대한 DNS 서버를 정의 하므로 FallbackDNS
전혀 사용되지 않습니다.
귀하의 게시물에 네트워크 구성이 enp3s0
다음과 같이 나와 있습니다.
enp3s0: IP 192.168.200.101 (DNS/GW: 192.168.200.101)
인터페이스를 자체 게이트웨이로 만드는 것은 의미가 없기 때문에(네트워크 세그먼트 외부에 연결이 없고 일부 구성 도구에서 게이트웨이를 구성해야 한다고 주장하는 경우 해결 방법으로 사용되기도 하지만) DNS/GW 부분의 오타입니다. "DNS/GW:192.168.200.1"을 의미합니다. 이는 상태에 표시된 내용과 일치합니다 resolved
.
따라서 3G 모뎀의 IP 주소가 192.168.200.1인 경우 근본 원인은 3G 모뎀이 인터넷에 연결되어 있지 않더라도resolved
모뎀 자체에 접속하는 것은 여전히 가능합니다. 따라서 resolved
3G 링크가 끊어지더라도 192.168.200.1이 여전히 유효한 DNS 서버라고 생각할 수도 있습니다. 3G 모뎀의 DNS 서버/프록시 기능이 제대로 작성되지 않은 경우 SERVFAIL로 응답하지 않거나 링크 없이 요청 시간이 초과될 수 있습니다. 이로 인해 사람들이 resolved
3G 모뎀이 유효한 DNS 서버라고 생각 하도록 오해할 수 있습니다. 인터넷에 대한 활성 링크가 전혀 없습니다.
이와 같은 3G 모뎀의 DNS 프록시는 나가는 인터넷 연결이 하나만 있을 때 네트워크 구성을 단순화할 수 있지만 대체 연결이 있으면 상황이 복잡해질 수 있습니다. 그런 다음 하나가 필요합니다.
/etc/systemd/resolved.conf
대신 DNS=
정적 DNS를 지정하는 데 사용하는 것이 좋습니다 FallbackDNS=
. resolved.conf(5)
매뉴얼 페이지 에는 다음과 같은 설명이 DNS=
나와 있습니다.
도메인 이름 확인 =
시스템의 DNS 서버로 사용할 공백으로 구분된 IPv4 및 IPv6 주소 목록입니다. DNS 요청은 나열된 DNS 서버 중 하나뿐만 아니라 systemd-networkd.service(8)에서 얻거나 외부 애플리케이션에 의해 런타임에 설정된 각 링크에 대한 적절한 DNS 서버로 전송됩니다. 호환성상의 이유로 이 설정을 지정하지 않으면 /etc/resolv.conf에 나열된 DNS 서버가 대신 사용됩니다(해당 파일이 존재하고 여기에 서버가 구성된 경우). 이 설정의 기본값은 빈 목록입니다.
따라서 DNS 서버 DNS=
의 설정은 resolved.conf
각 링크의 사용을 결코 방해하지 않습니다.
문제를 해결하려면 다음을 제안합니다.
192.168.200.1이 3G 모뎀의 IP 주소인 경우 이는 단순히 3G 네트워크 사업자의 DNS 서버에 대한 프록시 역할을 합니다.이 서버의 실제 IP 주소를 알아보세요(링크가 있지만 3G 모뎀 자체의 인터넷 측 네트워크 설정을 확인하면 될 것 같습니다.) 그런 DNS=
다음 /etc/systemd/resolved.conf
.
DNS=
그 후, DNS 요청은 3G 네트워크의 DNS 서버( 행과 같이 resolved.conf
)와 해당 링크별 DNS 서버로 병렬로 전송되어야 합니다 . 이제 시스템 전체 DNS 서버를 구성했으므로 이제 도메인에서 이름을 쿼리할 때 3G 모뎀에 내장된 DNS 서비스만 사용해야 합니다 *.rig
. 이것이 바로 DNS Domain:
설정의 enp3s0
의미이기 때문입니다.
3G 네트워크 링크가 실패하면 이제 3G 네트워크의 DNS 서버를 직접 사용하려는 시도가 의심할 여지 없이 실패하게 됩니다(모뎀 자체에서 잠재적으로 모호한 응답을 생성하는 대신). 따라서 resolved
DNS 서버를 더 이상 사용할 수 없으며 다른 대안을 고려해야 함을 나타냅니다. . 연결 확인을 통해 다른 링크의 우선순위가 높아지면 각 링크에 대해 DNS 서버를 사용하기 시작해야 합니다.
와 같은 이름을 사용하여 3G 모뎀의 관리 웹 인터페이스에 액세스할 수 있는 경우 <something>.rig
3G 링크가 작동하는지 여부에 관계없이 모뎀 자체에 액세스할 수 있는 한 해당 이름을 사용하여 인터페이스에 액세스할 수 있습니다.