StrongSwan trimite o adresă DNS la care Mac-ul nu poate ajunge

Totul funcționează până când cineva deschide un MacBook. Tunelul se stabilește, hosturile interne răspund după adresă, iar rezolvarea numelor moare. Pe iPhone același profil se comportă la fel, în timp ce clienții Windows și Linux sunt în regulă. De obicei vinovat este atributul DNS trimis: serverul distribuie propria adresă publică de interfață, iar clientul IKEv2 al Apple nu trimite interogări acolo prin tunel. Mută resolverul în pool și simptomul dispare fără să atingi clientul.

Simptomul indică adresa trimisă

Când eșuează doar unele platforme, tunelul și acreditările sunt aproape sigur în regulă, pentru că sunt comune. Ce diferă este modul în care fiecare client aplică încărcătura de configurare primită, inclusiv serverul DNS intern. Un client care acceptă adresa dar direcționează interogările pe lângă tunel ajunge cu un resolver pe care îl vede și nu îl poate folosi.

Adresa publică este alegerea obișnuită pentru că este singura pe care administratorul o știe deja. Este și singura adresă garantat în afara prefixului tunelului însuși, iar exact această proprietate strică clienții Apple.

Uită-te la valoare înainte de a schimba ceva. Dacă resolverul trimis este adresa WAN a serverului, ai găsit forma problemei și poți sări peste restul presupunerilor. Compară-l și cu prefixul pool-ului, pentru că o adresă în interiorul pool-ului dar în afara intervalului închiriat este exact cum va arăta remedierea. Două minute cu configurația bat o după-amiază de capturi de pachete pe client.

Decupează resolverul din intervalul de închiriere

Dă tunelului un plan de adrese în care resolverul este membru al subrețelei proprii a pool-ului, apoi rezervă acea adresă astfel încât să nu fie niciodată închiriată vreunui client. În acest exemplu pool-ul este 10.180.7.0/24, serverul deține 10.180.7.1, iar închirierile încep la 10.180.7.2.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

Prefixul pool-ului și resolverul împart o subrețea, deci ruta care transportă deja traficul tunelului transportă și interogările. Exact această singură proprietate face remedierea portabilă între clienți. Într-o configurație swanctl aceleași două fapte apar ca definiție de pool și setare DNS pe conexiune, nu în sintaxa ipsec.conf.

Serverul nu are nevoie de o interfață fizică nouă pentru asta. Adăugarea lui 10.180.7.1 la interfața loopback este suficientă pentru ca un resolver să se lege și să răspundă, deoarece clienții ajung la el prin ruta pool-ului care există deja. Ține adresa în afara intervalului de închiriere ca niciun client să nu o revendice din greșeală. Dacă pool-ul este gestionat de un serviciu DHCP sau RADIUS extern, rezervă adresa și acolo, altfel primul client care întreabă o va lua.

Leagă resolverul și închide portul 53

A atribui o adresă nu este același lucru cu a asculta pe ea. Un resolver care ascultă doar pe adresa LAN va refuza sau ignora interogările trimise la adresa pool-ului, iar clientul vede un timeout care pare o defecțiune de rutare.

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

Acest fragment unbound acceptă interogări din pool-ul tunelului și refuză tot restul, ceea ce este politica dorită de majoritatea resolverelor corporative. Dacă aceeași instanță răspunde și clienților LAN, adaugă prefixul LAN explicit în loc să extinzi ascultătorul la toate sursele.

Apoi regulile de firewall trebuie să se potrivească cu controlul de acces al resolverului însuși. Acceptă portul 53 din pool și aruncă-l în toate celelalte locuri, dar verifică mai întâi ordinea lanțului.

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

O regulă de acceptare anterioară și mai largă face ultimele două linii decorative, iar resolverul rămâne accesibil din internet. Citește setul efectiv de reguli împreună cu contoarele în loc să te bazezi pe ordinea intenționată. Politica alternativă, trimiterea adresei publice și permiterea interogărilor din orice sursă, funcționează pentru mulți clienți, dar pune resolverul pe internet și necesită propria limitare de rată și monitorizare.

Verifică ce a primit de fapt clientul

Verifică mai întâi viziunea serverului, apoi pe cea a clientului, pentru că cele două diferă în moduri instructive. O listare a pool-ului arată ce adresă a fost închiriată, iar listarea asocierilor de securitate arată dacă conexiunea este activă cu identitatea așteptată.

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

Interogarea directă dovedește că resolverul răspunde pe adresa pool-ului de la un host care o poate atinge. Nu dovedește că Mac-ul a ales acel server. Pe macOS, scutil --dns listează resolverele pe serviciu cu scop și este mai informativ decât panoul de sinteză; pe Windows, Get-DnsClientServerAddress arată dacă adaptorul tunelului a acceptat valoarea trimisă.

Dacă clientul afișează adresa pool-ului și interogările încă expiră, vina este a rutei tunelului sau a lanțului de firewall. Un client care nu raportează niciun resolver înseamnă că încărcătura de configurare nu a ajuns niciodată, așa că uită-te la modul în care acea platformă aplică setările trimise, nu la rețea. Notează care dintre cele două cazuri l-ai observat înainte de a schimba orice altceva. Aceste două defecțiuni arată identic într-un tichet de suport și duc la reparații opuse.