StrongSwan skickar en DNS-adress som Mac inte når

Allt fungerar tills någon öppnar en MacBook. Tunneln upprättas, interna värdar svarar på adress, och namnmatchningen dör. På iPhone beter sig samma profil likadant, medan Windows- och Linux-klienterna fungerar. Det skickade DNS-attributet är oftast boven: servern delar ut adressen till sitt eget publika gränssnitt, och Apples IKEv2-klient skickar inga frågor dit genom tunneln. Flytta resolvern in i poolen så försvinner symtomet utan att klienten rörs.

Symtomet pekar på den skickade adressen

När bara vissa plattformar misslyckas är tunneln och inloggningsuppgifterna nästan säkert okej, eftersom de delas. Det som skiljer är hur varje klient tillämpar nyttolasten i konfigurationen som den tar emot, inklusive den interna DNS-servern. En klient som accepterar adressen men dirigerar frågorna runt tunneln hamnar med en resolver som den ser men inte kan använda.

Den publika adressen är det vanliga valet eftersom det är den administratören redan känner till. Det är också den enda adress som garanterat ligger utanför tunnelns eget prefix, vilket är precis den egenskap som bryter Apples klienter.

Titta på värdet innan du ändrar något. Om den skickade resolvern är serverns WAN-adress har du hittat problemets form och kan hoppa över resten av gissningarna. Jämför den också med poolens prefix, eftersom en adress som ligger i poolen men utanför låneintervallet är precis hur rättningen kommer att se ut. Två minuter med konfigurationen slår en eftermiddag av paketinsamling på klienten.

Skär ut resolvern ur låneintervallet

Ge tunneln en adressplan där resolvern är medlem i poolens eget subnät och reservera sedan adressen så att ingen klient någonsin lånar den. I det här exemplet är poolen 10.180.7.0/24, servern har 10.180.7.1 och lån börjar på 10.180.7.2.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

Poolens prefix och resolvern delar subnät, så den rutt som redan bär tunneltrafik bär också frågorna. Just den egenskapen gör rättningen flyttbar mellan klienter. I en swanctl-konfiguration visas samma två fakta som en pooldefinition och en DNS-inställning på anslutningen, inte i syntaxen ipsec.conf.

Servern behöver inget nytt fysiskt gränssnitt för detta. Att lägga till 10.180.7.1 på loopback-gränssnittet räcker för att en resolver ska binda och svara, eftersom klienterna når den via poolrutten som redan finns. Håll adressen utanför låneintervallet så att ingen klient kan ta den av misstag. Om poolen hanteras av en extern DHCP- eller RADIUS-tjänst, reservera adressen även där, annars tar den första klient som frågar den.

Bind resolvern och stäng port 53

Att tilldela en adress är inte samma sak som att lyssna på den. En resolver som bara lyssnar på LAN-adressen vägrar eller ignorerar frågor som skickas till pooladressen, och klienten ser en timeout som ser ut som ett routingfel.

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

Det där unbound-fragmentet accepterar frågor från tunnelpoolen och vägrar allt annat, vilket är policyn de flesta företagsresolvers vill ha. Om samma instans också svarar LAN-klienter, lägg till LAN-prefixet uttryckligen i stället för att vidga lyssnaren till alla källor.

Brandväggsreglerna måste då stämma med resolverns egen åtkomstkontroll. Acceptera port 53 från poolen och släpp den från allt annat, men kontrollera först ordningen i kedjan.

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

En tidigare, bredare accepteregel gör de två sista raderna dekorativa, och resolvern förblir nåbar från internet. Läs den effektiva regeluppsättningen med räknarna i stället för att lita på ordningen du avsåg. Den alternativa policyn, att skicka den publika adressen och tillåta frågor från vilken källa som helst, fungerar för många klienter, men den sätter resolvern på internet och kräver egen hastighetsbegränsning och övervakning.

Verifiera vad klienten faktiskt fick

Kontrollera först serverns vy, sedan klientens, eftersom de två inte stämmer överens på ett informativt sätt. En poollista visar vilken adress som lånades, och listan över säkerhetsassociationer visar om anslutningen är uppe med förväntad identitet.

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

Den direkta frågan bevisar att resolvern svarar på pooladressen från en värd som kan nå den. Den bevisar inte att Macen valde den servern. På macOS listar scutil --dns resolvers per scopad tjänst och är mer informativ än sammanfattningspanelen; på Windows visar Get-DnsClientServerAddress om tunneladaptern accepterade det skickade värdet.

Om klienten visar pooladressen och frågorna fortfarande tar timeout, är det tunnelrutten eller brandväggskedjan som är fel. En klient som inte rapporterar någon resolver betyder att konfigurationsnyttolasten aldrig landade, så titta på hur den plattformen tillämpar skickade inställningar i stället för på nätverket. Skriv ned vilket av de två du observerade innan du ändrar något annat. De två felen ser identiska ut i ett supportärende och leder till motsatta åtgärder.