StrongSwan wysyła adres DNS, do którego Mac nie może dotrzeć

Wszystko działa, dopóki ktoś nie otworzy MacBooka. Tunel się nawiązuje, wewnętrzne hosty odpowiadają po adresie, a rozwiązywanie nazw umiera. Na iPhonie ten sam profil zachowuje się tak samo, podczas gdy klienci Windows i Linux są w porządku. Zwykle winny jest wysyłany atrybut DNS: serwer rozdaje własny publiczny adres interfejsu, a klient IKEv2 firmy Apple nie wysyła tam zapytań przez tunel. Przenieś resolver do puli, a objaw zniknie bez dotykania klienta.

Objaw wskazuje na wysyłany adres

Gdy zawodzą tylko niektóre platformy, tunel i poświadczenia są niemal na pewno w porządku, bo są wspólne. Różni się to, jak każdy klient stosuje otrzymany ładunek konfiguracji, w tym wewnętrzny serwer DNS. Klient, który akceptuje adres, ale kieruje zapytania obok tunelu, kończy z resolverem, który widzi i nie może użyć.

Publiczny adres to zwykły wybór, bo jest jedynym, który administrator już zna. Jest też jedynym adresem gwarantowanie poza prefiksem samego tunelu, i właśnie ta właściwość psuje klientów Apple.

Spójrz na wartość, zanim cokolwiek zmienisz. Jeśli wysyłany resolver to adres WAN serwera, znalazłeś kształt problemu i możesz pominąć resztę zgadywania. Porównaj go też z prefiksem puli, bo adres w puli, ale poza zakresem dzierżawy, to dokładnie to, jak będzie wyglądać poprawka. Dwie minuty z konfiguracją biją popołudnie przechwytywania pakietów na kliencie.

Wytnij resolver z zakresu dzierżawy

Daj tunelowi plan adresów, w którym resolver jest członkiem własnej podsieci puli, a następnie zarezerwuj ten adres, aby nigdy nie został wydzierżawiony żadnemu klientowi. W tym przykładzie pula to 10.180.7.0/24, serwer trzyma 10.180.7.1, a dzierżawy zaczynają się od 10.180.7.2.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

Prefiks puli i resolver dzielą podsieć, więc trasa, która już niesie ruch tunelu, niesie też zapytania. Właśnie ta jedna właściwość czyni poprawkę przenośną między klientami. W konfiguracji swanctl te same dwa fakty pojawiają się jako definicja puli i ustawienie DNS na połączeniu, a nie w składni ipsec.conf.

Serwer nie potrzebuje do tego nowego interfejsu fizycznego. Dodanie 10.180.7.1 do interfejsu loopback wystarczy, aby resolver się związał i odpowiadał, bo klienci docierają do niego przez istniejącą trasę puli. Trzymaj adres poza zakresem dzierżawy, aby żaden klient nie zajął go przypadkiem. Jeśli pulą zarządza zewnętrzna usługa DHCP lub RADIUS, zarezerwuj adres także tam, inaczej zajmie go pierwszy klient, który zapyta.

Zwiąż resolver i zamknij port 53

Przydzielenie adresu to nie to samo co nasłuchiwanie na nim. Resolver, który nasłuchuje tylko na adresie LAN, odmówi lub zignoruje zapytania wysyłane na adres puli, a klient widzi limit czasu, który wygląda jak błąd routingu.

interface: 10.180.7.1
access-control: 10.180.7.0/24 allow
access-control: 0.0.0.0/0 refuse

Ten fragment unbound akceptuje zapytania z puli tunelu i odrzuca wszystko inne, co jest polityką, której chce większość firmowych resolverów. Jeśli ta sama instancja odpowiada też klientom LAN, dodaj prefiks LAN jawnie, zamiast rozszerzać nasłuch na wszystkie źródła.

Następnie reguły firewalla muszą zgadzać się z własną kontrolą dostępu resolvera. Akceptuj port 53 z puli i odrzucaj go wszędzie indziej, ale najpierw sprawdź kolejność łańcucha.

iptables -A INPUT -p udp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j DROP
iptables -A INPUT -p tcp --dport 53 -j DROP

Wcześniejsza, szersza reguła akceptacji czyni dwa ostatnie wiersze dekoracją, a resolver pozostaje osiągalny z internetu. Czytaj efektywny zestaw reguł z licznikami, zamiast ufać zamierzonej kolejności. Alternatywna polityka, wysyłanie publicznego adresu i zezwalanie na zapytania z dowolnego źródła, działa dla wielu klientów, ale wystawia resolver do internetu i wymaga własnego ograniczania szybkości oraz monitorowania.

Sprawdź, co klient faktycznie otrzymał

Najpierw sprawdź widok serwera, potem klienta, bo oba różnią się w pouczający sposób. Lista puli pokazuje, który adres wydzierżawiono, a lista asocjacji bezpieczeństwa pokazuje, czy połączenie jest aktywne z oczekiwaną tożsamością.

swanctl --list-sas
swanctl --list-pools
dig +short @10.180.7.1 intranet.plant.example

Bezpośrednie zapytanie dowodzi, że resolver odpowiada na adresie puli z hosta, który może go osiągnąć. Nie dowodzi, że Mac wybrał ten serwer. W macOS scutil --dns wymienia resolvery dla każdej usługi z zakresem i jest bardziej pouczający niż panel podsumowania; w Windows Get-DnsClientServerAddress pokazuje, czy adapter tunelu zaakceptował wysłaną wartość.

Jeśli klient pokazuje adres puli, a zapytania nadal kończą się limitem czasu, winna jest trasa tunelu lub łańcuch firewalla. Klient, który nie zgłasza żadnego resolvera, oznacza, że ładunek konfiguracji nigdy nie dotarł, więc patrz na to, jak ta platforma stosuje wysyłane ustawienia, a nie na sieć. Zapisz, który z tych dwóch przypadków zaobserwowałeś, zanim zmienisz cokolwiek innego. Te dwa błędy wyglądają identycznie w zgłoszeniu do pomocy i prowadzą do przeciwnych napraw.