Gdy DNS nie pozwala połączyć się z chmurą AWS

DNS

Nie mogę połączyć się z produkcją, co robić, ratunku! Czy to dlatego, że VPN nie działa na Linuksie? Niekoniecznie. Być może winny jest twój dostawca Internetu.

Opisywany problem dotknął mojego peceta z Ubuntu, ale wkrótce okazało się, że przeszkadza też koledze z Makiem. Może dotknąć też ciebie, o ile korzystasz z usług popularnej firmy, której nazwa zaczyna się na T, a kończy się na A.

W dalszej części opiszę, jak sprawdzić, że masz właśnie ten problem, oraz jak go obejść (bez wypowiadania umowy, zostaniemy przy konfiguracji własnej maszyny). Ogólne instrukcje zostały przetestowane i pomogły na MacOS-ie, ale najwięcej szczegółów będzie dotyczyło sprzętu, do którego mam dostęp, czyli Ubuntu.

Opiszę też, jak z poziomu konsoli dowiedzieć się, jaki tak naprawdę DNS jest używany w systemie. Przez ostatnie zmiany w Linuksie panuje zamieszanie i stare metody przestały działać.

Objawy

Na początek upewnijmy się, że chodzi o dokładnie ten problem:

ping production.hal-2001.amazonaws.com

Jeśli adres jest poprawny, a mimo to w odpowiedzi pokazuje się:

ping: production.hal-2001.amazonaws.com: Name or service not known

to znaczy, że faktycznie coś jest nie tak z DNS-em. Teraz szybkie sprawdzenie, czy zmiana serwera nazw jest w stanie coś pomóc, przez komendę dig (można też użyć nslookup). Najpierw z użyciem ustawień systemowych:

dig production.hal-2001.amazonaws.com

Zła odpowiedź nie zawiera IP:

;; ANSWER SECTION:
production.hal-2001.amazonaws.com. 300 IN CNAME ns.hal-2001.amazonaws.com.

Spróbujmy z innym DNS-em (podajemy po małpie):

dig production.hal-2001.amazonaws.com @8.8.8.8

Sytuacja wygląda dobrze, gdy wtedy przychodzi IP:

;; ANSWER SECTION:
production.hal-2001.amazonaws.com. 5 IN CNAME ns.hal-2001.amazonaws.com.
ns.hal-2001.amazonaws.com. 5 IN A 10.5.13.36

Problem

Objawy wskazują, co się dzieje: DNS, który mamy w systemie, nie udziela odpowiedzi, choć inny DNS jest w stanie. O ile nie psuliśmy konfiguracji sami, prawdopodobnie spaprał coś nasz dostawca Internetu.

Możemy ominąć problem i ustawić, żeby system korzystał z niezależnego DNS-a. Na przykład użyć wystawionego przez Google’a, jego adres to 8.8.8.8. Albo 1.1.1.1 od Cloudfare’a. Albo jeszcze innego, lista jest choćby w artykule na Linuxize.

Zmiana DNS używanego w systemie

Konfiguracja powinna być w miejscu, gdzie konfigurujemy nasze połączenie internetowe. U mnie w KDE jest to zakładka „IPv4” w ustawieniach domowego WiFi. Dopisałem 8.8.8.8 jako ręcznie skonfigurowany DNS.

ustawienia WiFi w KDE

Instrukcje dla innych systemów (Windows, MacOS) podaje Google.

Jeśli to możliwe, warto zaznaczyć, by ignorować DNS-y wysyłane przez dostawcę Internetu. Takie ustawienie może nazywać się „DNS: Automatic” (trzeba je wtedy wyłączyć, nie chcemy automatycznych). Czemu? Żeby zapobiec sytuacji, że wpisany przez nas DNS będzie potraktowany jako pomocniczy. Ma być główny.

Tylko czy na pewno jest?

Miałem sytuację, że już ustawiłem sobie własny DNS, wszystko działało, ale do momentu włączenia VPN-a. Bo na VPN-ie mogłem połączyć się do wszystkich stron, oprócz produkcji. Przydatne, prawda? Okazało się, że w UI nie byłem w stanie ustawić ignorowania DNS-ów od dostawcy Internetu. Normalnie mój 8.8.8.8 był główny, ale program do VPN-u mieszał coś i mój główny stawał się jedynie pomocniczym, a na pierwsze miejsce wskakiwał zepsuty DNS od dostawcy Internetu.

Kilka DNS-ów, który użyty?

Ta część będzie specyficzna dla Linuksa. Sposób obsługi DNS-ów przechodził tam przez ostatnie lata fundamentalne zmiany. Skutkiem jest to, że w Internecie jest pełno poradników, jak ogarniać konfigurację DNS-ów, ale większość z nich jest nieaktualna i nie będzie działać.

Dawno temu trzeba było edytować plik /etc/resolv.conf. To już nieprawda. Ten plik już niczym nie steruje, a nawet jego zawartość jest do niczego, nie znajdziemy tam prawdziwych adresów DNS-ów.

Zarówno dig jak i nslookup nie mówią, skąd przyszła odpowiedź. Jeśli nie dostajemy wyników, to nie wiemy, czy te komendy odpytały dobry DNS, czy też coś nie styka w konfiguracji i dalej wszystkie idzie przez stare, złe DNS-y, zamiast przez nowy, który mieliśmy nadzieję ustawić.

DNS-y przewędrowały do systemd. Nowsze poradniki każą używać systemd-resolve – ale to też już przeszłość. Ubuntu 22.04 pozbyło się tej komendy.

Teraz trzeba użyć resolvectl status:

Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (wlp2s0)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 215.119.221.133
       DNS Servers: 215.119.221.133 8.8.8.8

Wynik powyżej wskazuje na problem. Ustawiony ręcznie DNS jest widziany przez system, ale tylko jako pomocniczy, a nie główny.

Całkowite ignorowanie DNS-ów od dostawcy Internetu

U mnie sprawdziło się narzędzie nmcli (Network Manager CLI). Tu polecenia znalezione na Server Fault:

nmcli con mod moje_wifi ipv4.dns "8.8.8.8"
nmcli con mod moje_wifi ipv4.ignore-auto-dns yes

Są też poradniki każące edytować /etc/netplan, na przykład na Linux Shout. Nie sprawdzałem.


Grafika z Wikimedia Commons na licencji LGPL, autor Everaldo Coelho.

Creative Commons License
Except where otherwise noted, the content by Piotr Kubowicz is licensed under a Creative Commons Attribution 4.0 International License.