systemd-giải quyết, độ phân giải dịch vụ, độ phân giải và openresolv. Tại sao, cái nào và như thế nào?

Tôi đang sử dụng máy khách VPN có thêm hai máy chủ tên /etc/resolv.conf. Tất cả các kết nối của tôi được quản lý bởi Network-Manager.

Tôi phải sử dụng máy khách VPN này cho VPN công việc của mình nhưng sau khi Ubuntu chuyển sang systemd-resolved16.10, tôi gặp vấn đề với kết nối và DNS của mình. Có vẻ như các systemd-resolvedthay đổi /etc/resolv.conftrở lại máy chủ tên mặc định vì một số lý do khiến các trang nội bộ không giải quyết được. Tôi đã xem xét thêm một số điều này và cuối cùng thay thế resolvconfbằng openresolv. Điều đó đã giúp rất nhiều, nhưng vẫn systemd-resolvedđặt lại /etc/resolv.confsau khi VPN đã hoạt động được một thời gian.

Nó có thể chỉ là kết nối lên hoặc sau một vài phút hoặc đôi khi không phải là tất cả. Sau đó tôi bị vô hiệu hóa systemd-resolvedvà systemd resolvconf.servicevà chỉ chạy openresolv. Có vẻ như tất cả đều hoạt động tốt.

Tuy nhiên, đây là tất cả rất khó hiểu. Có một lý do để sử dụng systemd-resolvedvới một trong những người khác? Nó được kích hoạt trong Ubuntu 16.10 vì vậy tôi nghĩ rằng phải có lý do cho nó nhưng dường như nó gây ra một cuộc chiến /etc/resolv.conf.

Sẽ thật tuyệt nếu tôi có thể chạy operesolvvà giải thích điều này. Tôi đã đọc khá nhiều về nó nhưng tôi vẫn không hiểu tại sao /etc/resolv.confđược quản lý như vậy, chỉ khi tôi sử dụng systemdnó, tôi không thể sử dụng máy khách VPN của mình.

Tôi đã quản lý để thay đổi tập lệnh xử lý các mục cấu hình này trong OpenVPN trong Ubuntu (được thử nghiệm vào ngày 18.04). Đây là một bản vá cho điều đó:

--- /etc/openvpn/update-resolv-conf.orig    2019-03-13 19:14:16.163914424 +0400
+++ /etc/openvpn/update-resolv-conf 2019-03-13 19:29:30.380420708 +0400
@@ -15,7 +15,7 @@
 #     foreign_option_3='dhcp-option DOMAIN be.bnc.ch'
 #

-[ -x /sbin/resolvconf ] || exit 0
+[ -x /usr/bin/systemd-resolve ] || exit 0
 [ "$script_type" ] || exit 0
 [ "$dev" ] || exit 0

@@ -43,16 +43,16 @@
        fi
    done
    R=""
-   [ "$SRCHS" ] && R="search $SRCHS
-"
+   for SRCH in $SRCHS ; do
+       R="${R}--set-domain=$SRCH "
+   done
    for NS in $NMSRVRS ; do
-           R="${R}nameserver $NS
-"
+       R="${R}--set-dns=$NS "
    done
-   echo -n "$R" | /sbin/resolvconf -a "${dev}.openvpn"
+   /usr/bin/systemd-resolve -i ${dev} ${R}
    ;;
   down)
-   /sbin/resolvconf -d "${dev}.openvpn"
+   echo "Doing nothing, interface disappears."
    ;;
 esac

Bạn sẽ cần thêm các mục sau vào tệp cấu hình OpenVPN của mình:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

Bạn đang sử dụng máy khách VPN nào? Tôi đã gặp sự cố với OpenVPN thẳng, nhưng cài đặt phiên bản NM của máy khách đã khắc phục được sự cố. Chà, hầu hết trong số họ, tôi không thể ngăn chặn một tuyến đường bị đẩy, nhưng đó là một vấn đề hoàn toàn khác.

Vấn đề là: client VPN của bạn có biết về cách để tương tác với ý tưởng systemd của làm thế nào để quản lý dịch vụ DNS. Tôi không khuyến nghị điều này, nhưng bạn có thể thử vô hiệu hóa dịch vụ phân giải ( systemctl disable systemd-resolved.service) để xem liệu nó có cải thiện mọi thứ không, nhưng cuối cùng bạn sẽ phải có một khách hàng hiểu cách gửi đến các ma trận của systemd :)

(Con tàu systemd đã đi thuyền từ lâu, chúng ta đừng mở một cuộc thảo luận về lý do tại sao một số điều đã được thực hiện.)

Một bản cập nhật cho máy khách VPN mà tôi đã sử dụng đã giải quyết (ý định chơi chữ). Đó là ứng dụng khách OpenFortiGui cho Fortinet VPN.