StrongSwan posílá DNS adresu, na kterou se Mac nedostane

Všechno funguje, dokud někdo neotevře MacBook. Tunel se naváže, interní hosty odpovídají podle adresy a překlad jmen umře. Na iPhonu se stejný profil chová stejně, zatímco klienti Windows a Linux jsou v pořádku. Obvykle je viníkem posílaný atribut DNS: server rozdává vlastní veřejnou adresu rozhraní a klient IKEv2 od Apple tam neposílá dotazy tunelem. Přesuňte resolver dovnitř poolu a symptom zmizí, aniž byste se klienta dotkli.

Symptom ukazuje na posílanou adresu

Když selhávají jen některé platformy, tunel a přihlašovací údaje jsou téměř jistě v pořádku, protože jsou společné. Liší se to, jak každý klient aplikuje přijatou konfigurační zátěž, včetně interního serveru DNS. Klient, který adresu přijme, ale dotazy vede mimo tunel, skončí s resolverem, který vidí a nemůže použít.

Veřejná adresa je obvyklá volba, protože je to ta, kterou administrátor už zná. Je to také jediná adresa zaručeně mimo vlastní prefix tunelu, a právě tato vlastnost láme klienty Apple.

Podívejte se na hodnotu, než cokoli změníte. Pokud je posílaný resolver WAN adresa serveru, našli jste podobu problému a můžete zbytek hádání přeskočit. Porovnejte ji také s prefixem poolu, protože adresa uvnitř poolu, ale mimo přidělený rozsah, je přesně to, jak bude oprava vypadat. Dvě minuty s konfigurací porazí odpoledne zachytávání paketů na klientovi.

Vyřízněte resolver z rozsahu pronájmu

Dejte tunelu plán adres, ve kterém je resolver členem vlastní podsítě poolu, a pak tuto adresu rezervujte, aby nikdy nebyla pronajata žádnému klientovi. V tomto příkladu je pool 10.180.7.0/24, server drží 10.180.7.1 a pronájmy začínají na 10.180.7.2.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

Prefix poolu a resolver sdílejí podsíť, takže trasa, která už nese tunelový provoz, nese i dotazy. Právě tato jediná vlastnost činí opravu přenosnou mezi klienty. V konfiguraci swanctl se stejné dva fakty objevují jako definice poolu a nastavení DNS na spojení, nikoli v syntaxi ipsec.conf.

Server k tomu nepotřebuje nové fyzické rozhraní. Přidání 10.180.7.1 na rozhraní loopback stačí, aby se resolver připoutal a odpovídal, protože klienti se k němu dostanou přes trasu poolu, která už existuje. Držte adresu mimo rozsah pronájmu, aby ji žádný klient omylem nezabral. Pokud pool spravuje externí služba DHCP nebo RADIUS, rezervujte adresu i tam, jinak si ji vezme první klient, který se zeptá.

Připoutejte resolver a zavřete port 53

Přidělit adresu není totéž jako na ní naslouchat. Resolver, který naslouchá jen na adrese LAN, odmítne nebo ignoruje dotazy poslané na adresu poolu a klient vidí vypršení, které vypadá jako chyba směrování.

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

Tento fragment unbound přijímá dotazy z tunelového poolu a vše ostatní odmítá, což je politika, kterou chce většina firemních resolverů. Pokud stejná instance odpovídá i klientům LAN, přidejte prefix LAN výslovně, místo abyste posluchače rozšířili na všechny zdroje.

Pravidla firewallu pak musí souhlasit s vlastní kontrolou přístupu resolveru. Přijměte port 53 z poolu a všude jinde ho zahoďte, ale nejprve zkontrolujte pořadí řetězce.

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

Dřívější a širší pravidlo přijetí dělá z posledních dvou řádků dekoraci a resolver zůstává dostupný z internetu. Čtěte efektivní sadu pravidel s počítadly, místo abyste věřili zamýšlenému pořadí. Alternativní politika, posílat veřejnou adresu a povolit dotazy z libovolného zdroje, funguje pro mnoho klientů, ale staví resolver na internet a vyžaduje vlastní omezení rychlosti a monitoring.

Ověřte, co klient skutečně dostal

Nejprve zkontrolujte pohled serveru, pak klienta, protože oba se informativně rozcházejí. Výpis poolu ukazuje, která adresa byla pronajata, a výpis bezpečnostních asociací ukazuje, zda je spojení navázáno s očekávanou identitou.

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

Přímý dotaz dokazuje, že resolver odpovídá na adrese poolu z hostu, který se k němu dostane. Nedokazuje, že Mac zvolil právě tento server. V macOS scutil --dns vypisuje resolvery podle vymezené služby a je informativnější než souhrnný panel; ve Windows Get-DnsClientServerAddress ukazuje, zda tunelový adaptér posílanou hodnotu přijal.

Pokud klient zobrazuje adresu poolu a dotazy stále vyprší, vinna je trasa tunelu nebo řetězec firewallu. Klient, který nehlásí žádný resolver, znamená, že konfigurační zátěž nikdy nedorazila, takže se dívejte, jak tato platforma aplikuje posílaná nastavení, a ne na síť. Zapište, který z těchto dvou případů jste pozorovali, než změníte cokoli dalšího. Tyto dvě poruchy vypadají v podpůrném tiketu stejně a vedou k opačným opravám.