VPN이 다운되어 액세스할 수 없는 경우에도 내부 도메인의 고정 목록을 항상 내부 네임서버를 통해 확인하면서 다른 모든 작업에는 기본 네임서버를 계속 사용하도록 하는 가장 안정적인 구성은 무엇입니까?
KDE(또는 다른 데스크탑 환경)에서 적절한 인터페이스나 네트워크를 선택한 후 NetworkManager가 연결을 설정합니다.
이 질문은 특히 다음과 같은 이유로 VPN 도메인의 정적 목록을 정의하는 것에 관한 것입니다.
- VPN 내의 내부 이름 서버에만 알려진 세 개의 내부 도메인이 있다고 가정합니다. 그 중 두 개는
/etc/resolv.conf
VPN 연결을 설정할 때 자동으로 "검색" 도메인으로 추가되고, VPN 연결을 설정하는 경우 내부 이름 서버(파일 앞에 추가됨) 그렇게 하도록 구성된 클라이언트입니다. - 기본 VPN의 내부 도메인이 ".int", ".org" 및 ".test.net"이라고 가정하고, 클라이언트가 파일을 변경하도록 구성된 경우 처음 두 도메인이 검색 도메인으로 추가됩니다
resolv.conf
. /etc/resolv.conf
연결이 설정된 후 VPN 클라이언트가 변경되면 모든 DNS 요청은 내부 이름 서버로 전송됩니다. 이 서버는 3개의 내부 도메인만 처리하고 다른 도메인은 처리하지 않습니다.- VPN 연결이 끊어질 때마다 VPN 클라이언트는
resolv.conf
DHCP가 할당하고 NetworkManager가 추가한 표준 이름 서버만 남겨두고 자동으로 파일을 재설정합니다. 따라서 VPN이 종료될 때마다 내부 DNS 요청이 중지됩니다.방법을 제공;표준 네임서버로 전송되는데, 표준 네임서버는 이에 대해 알지 못하거나 다른 외부 IP로 확인합니다. - 이 파일은 KDE에서 연결이 설정될 때마다 DHCP 할당 이름 서버에 기록됩니다. NetworkManager가 이를 처리합니다. 만 포함된 파일에 대한 링크인 경우 수신된 이름 서버 IP 주소를 확인자가 사용할 파일
nameserver localhost
에 써야 할 수도 있습니다 .uplink.conf
resolv.conf
파일이 files 만 포함하는 심볼릭 링크이고nameserver localhost
로컬 확인자가 도메인을 기반으로 쿼리를 전달하는 방법을 항상 알고 있는 경우 파일을 다르게 변경할 필요가 없습니다.- 내부 이름 서버의 IP 주소는 내부 도메인 목록과 마찬가지로 정적입니다. 이러한 내부 도메인에 대한 DNS 쿼리는 예외 없이 내부 이름 서버로만 전송될 수 있습니다.
- 평소와 같이 다른 도메인에 대한 DNS 쿼리는 표준 이름 서버에서 처리되어야 합니다. 유사한 문제는 이름 서버를 수동으로 구성하여 해결되었지만 이 경우 시스템은 DHCP 할당 이름 서버를 사용해야 합니다.
- dnsmasq를 사용한 빠른 시도가 실패했습니다. 구성 등을 거친 후에도 여전히
server=/int/10.1.1.1
표준 이름 서버에 쿼리를 보냅니다.xxx.int
로그 파일에는 DHCP 할당 표준 이름 서버의 위치using nameserver 10.1.1.1#53 for domain int
와 위치가 표시됩니다using nameserver 192.168.1.1#53 for domain int
( 따라서 DNS 쿼리가 누출되고 있음).192.168.1.1
systemd-resolved를 사용하는 솔루션이 선호되지만 다른 해석기에 대한 구성 예제도 환영합니다. - 문제의 초점은 VPN 연결 상태나 두 번째 VPN 연결이 현재 활성 상태인지 여부에 관계없이 로컬 확인자(예: systemd-resolved)의 구성입니다.
- 이 질문은 특정 배포판에 관한 것이 아닙니다. systemd를 사용하고 KDE가 있는 모든 배포판에서 작동합니다. 예를 들어,Fedora 33은 systemd-resolved를 사용합니다.기본적으로 이에 대한 구성 예가 좋을 것입니다.
dig
,host
, 또는nslookup
같은 표준 도구가ping
작동해야 합니다(예: 잘못된 이름 서버에 쿼리를 보내지 않음).
이 사이트에는 비슷한 질문이 있으며 일반적으로 누출 쿼리가 필요하지 않으며 다른 사이트에도 비슷한 질문이 있습니다. 예를 들어,gnome.org의 기사"분할 DNS 문제"를 해결하는 것 같습니다.회사 VPN에 라우팅 도메인이 없습니다. 어떻게 해야 합니까?"하지만 기대된다.모두VPN 클라이언트에 의해 설정되고 다음을 설명하는 내부 도메인입니다.
...안타깝게도 기존의 비분할 DNS에서는 중요하지 않기 때문에 모든 VPN이 실제로 이를 올바르게 수행하는 것은 아닙니다. 설상가상으로 그놈 시스템 설정에는 이 문제를 해결할 수 있는 그래픽 구성이 없습니다. 정말 있어야합니다. 하지만 이제는 사용해야합니다
nmcli
...
그러한 명령을 사용해야 하는 것은 안정적인 구성처럼 보이지 않습니다. 그리고일시적으로 연결이 끊어지면 DNS 쿼리가 유출되어서는 안 됩니다.. 기사는 계속됩니다 :
이 일을 엉망으로 만들 필요가 없기를 바랍니다.
그랬다면 어떨까요? 이것은 너무 드물어서는 안됩니다. 표준 솔루션이 하나 이상 있어야 합니다.
참고로 다음 dnsmasq 구성을 시도했지만 DHCP에서 기본적으로 제공하는 표준 이름 서버에 대한 요구 사항을 충족하지 않습니다.
/etc/dnsmasq.d/dns-int.conf
:
no-resolv
server=/int/10.1.1.1
server=/org/10.1.1.1
server=/test.net/10.1.1.1
server=/google.com/8.8.8.8 # example
server=9.9.9.9 # not wanted
log-queries
에서 /etc/NetworkManager/NetworkManager.conf
하단 부분 [main]
:
dns=dnsmasq
dnsmasq를 직접 시작할 때 사용할 구성 파일을 가리키는 NetworkManager가 사용하는 구성 디렉터리에 심볼릭 링크를 추가합니다 systemctl start dnsmasq
.
`/etc/NetworkManager/dnsmasq.d/dns-int.conf` -> `/etc/dnsmasq.d/dns-int.conf`
그러나 위에서 언급했듯이 이 구성은 완전히 정확하지는 않습니다.
답변1
이 질문은 주로 systemd-resolved에 관한 것이지만 dnsmasq에 대한 나의 시도를 별도의 답변으로 설명하는 것이 유용할 것이라고 생각했습니다. 나는 다른 답변이 먼저 나오도록 내 답변을 반대 투표했으며, 처음에 왜 작동하지 않았는지 명확하지 않기 때문에 반대했습니다. 편집: 내 게시물에 반대 투표를 할 수 없는 것 같습니다. 어쩌면 다른 사람이 이것을 할 수도 있습니다.
DNS
첫째, NetworkManager가 dbus를 통해 dnsmasq에 이 목록을 보내기 때문에 기본 네임서버 목록으로 "업링크" 프로필을 지정할 필요가 없습니다. 그러나 어떤 이유로 이것이 작동하지 않으면 네트워크에 연결하거나 다시 연결할 때 NetworkManager가 생성하는 파일을 dnsmasq로 지정하여 명시적으로 지정할 수 있습니다.
resolv-file=/run/NetworkManager/no-stub-resolv.conf
dnsmasq 구성 파일: /etc/dnsmasq.d/dns-int.conf
:
no-resolv
server=/int/10.1.1.1
server=/org/10.1.1.1
server=/test.net/10.1.1.1
no-poll
domain-needed
strict-order
clear-on-reload
no-negcache
log-queries
/etc/NetworkManager/NetworkManager.conf의 [main] 섹션에서:
dns=dnsmasq
systemctl start dnsmasq를 사용하여 dnsmasq를 직접 시작할 때 사용할 구성 파일을 가리키는 NetworkManager에서 사용하는 구성 디렉터리에 심볼릭 링크를 추가합니다.
`/etc/NetworkManager/dnsmasq.d/dns-int.conf` -> `/etc/dnsmasq.d/dns-int.conf`
참고: dnsmasq가 모든 쿼리를 위에 나열된 내부 도메인(내부 이름 서버뿐만 아니라 10.1.1.1
DHCP 할당 기본 이름 서버) 으로 전달하기 때문에 초기 시도가 실패했습니다.
$ sudo grep dnsmasq /var/log/messages | grep forward | grep test.net
May 3 10:06:52 ... dnsmasq[4128385]: forwarded foo.test.net to 10.1.1.1
May 3 10:06:52 ... dnsmasq[4128385]: forwarded foo.test.net to 192.168.1.1
이제는 더 이상 이 작업을 수행하지 않는 것 같습니다. 애초에 왜 그런 작업을 수행했는지 잘 모르겠습니다.
또한 구성 파일에 다음을 추가하여 검색 도메인 "intern"에 대한 쿼리 차단을 시도했습니다.
address=/intern/
매뉴얼 페이지에 따르면 Queries in the domains are never forwarded
대신 다음을 수행합니다.
forwarded foo.intern to 192.168.1.1
가짜 주소를 시도했습니다:
address=/intern/127.0.0.2
... dnsmasq[95222]: query[A] foo.intern from 127.0.0.1
... dnsmasq[95222]: config foo.intern is 127.0.0.2
... dnsmasq[95222]: query[AAAA] foo.intern from 127.0.0.1
... dnsmasq[95222]: forwarded foo.intern to 192.168.1.1
$ host foo.intern localhost
Using domain server:
Name: localhost
Address: 127.0.0.1#53
Aliases:
foo.intern has address 127.0.0.2
Host foo.intern not found: 3(NXDOMAIN)
Host foo.intern not found: 4(NOTIMP)
이러한 방식으로 IPv6 쿼리가 유출됩니다. 이 특정 설정을 사용하면 다음과 같습니다.
address=/intern/#
MX 쿼리가 유출되고 있습니다.
... dnsmasq[97107]: query[AAAA] foo.intern from 127.0.0.1
... dnsmasq[97107]: config foo.intern is ::
... dnsmasq[97107]: query[MX] foo.intern from 127.0.0.1
... dnsmasq[97107]: forwarded foo.intern to 192.168.1.1
... dnsmasq[97107]: reply error is not implemented
즉, DNS 누출을 막았다고 생각하는 순간 새로운 DNS 누출이 나타납니다. 이 모든 것은 NetworkManager가 dnsmasq를 시작할 때 발생합니다. ( address=/intern/
dnsmasq가 수동으로 시작되면 작동하는 것처럼 보이기 때문입니다 .)
그 외에는 대부분의 경우 작동하는 것처럼 보이지만 시스템 해결 작업 구성을 갖는 것이 여전히 더 좋습니다.