StrongSwanek Mac-ak iritsi ezin duen DNS helbidea bidaltzen du

Dena funtzionatzen du norbaitek MacBook bat ireki arte. Tunela ezartzen da, barneko ostalariek helbidez erantzuten dute, eta izenen ebazpena hiltzen da. iPhonean profil berak modu berean jokatzen du, Windows eta Linux bezeroak ondo dauden bitartean. Normalean bidalitako DNS atributua da erruduna: zerbitzariak bere interfazearen helbide publikoa banatzen du, eta Apple-ren IKEv2 bezeroak ez ditu horra kontsultak bidaltzen tunelaren bidez. Eraman resolverra poolaren barrura eta sintomak desagertu egiten dira bezeroa ukitu gabe.

Sintomak bidalitako helbidera seinalatzen du

Plataforma batzuek bakarrik huts egiten dutenean, tunela eta kredentzialak ziurrenik ondo daude, partekatuak direlako. Aldatzen dena da bezero bakoitzak jasotzen duen konfigurazio-karga nola aplikatzen duen, barneko DNS zerbitzaria barne. Helbidea onartzen duen baina kontsultak tunelaren inguruan bideratzen dituen bezero batek ikus dezakeen baina erabili ezin duen resolver batekin amaitzen du.

Helbide publikoa ohiko aukera da, administratzaileak jada ezagutzen duen bakarra delako. Tunelaren beraren aurrizkitik kanpo egongo dela bermatuta dagoen helbide bakarra ere bada, eta propietate horrek hain zuzen hausten ditu Apple-ren bezeroak.

Begiratu balioa ezer aldatu aurretik. Bidalitako resolverra zerbitzariaren WAN helbidea bada, problemaren forma aurkitu duzu eta gainerako asmakizunak saihestu ditzakezu. Konparatu poolaren aurrizkiarekin ere, poolaren barruan baina alokairu-tartetik kanpo dagoen helbidea izango baita konponketaren itxura. Bi minutu konfigurazioarekin hobeak dira bezeroan arratsalde oso bat paketeak harrapatzen baino.

Moztu resolverra alokairu-tartetik

Eman tunelari helbide-plana non resolverra poolaren beraren azpisareko kidea den, eta gero erreserbatu helbide hori bezero bati inoiz alokatuko ez zaiola ziurtatzeko. Adibide honetan pool-a 10.180.7.0/24 da, zerbitzariak 10.180.7.1 dauka, eta alokairuak 10.180.7.2-n hasten dira.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

Poolaren aurrizkiak eta resolverrak azpisare bat partekatzen dute, beraz tunelaren trafikoa daraman bideak kontsultak ere daramatza. Propietate bakar horrek egiten du konponketa bezeroen artean eramangarri. Swanctl konfigurazio batean bi gertaera berak pool definizio eta konexioaren DNS ezarpen gisa agertzen dira, ipsec.conf sintaxian beharrean.

Zerbitzariak ez du interfaze fisiko berririk behar horretarako. 10.180.7.1 loopback interfazeari gehitzea nahikoa da resolver bat lotu eta erantzun dezan, bezeroek jada existitzen den poolaren bidearen bidez iristen baitzaizkio. Eduki helbidea alokairu-tartetik kanpo, bezeroek nahi gabe har ez dezaten. Pool-a kanpoko DHCP edo RADIUS zerbitzu batek kudeatzen badu, erreserbatu helbidea han ere, bestela galdetzen duen lehen bezeroak hartuko du.

Lotu resolverra eta itxi 53 portua

Helbide bat esleitzea ez da horrela entzutea bezalakoa. LAN helbidean soilik entzuten duen resolver batek poolaren helbidera bidalitako kontsultak ukatu edo ezjoko ditu, eta bezeroak bideratze-hutsegitea ematen duen denbora-muga ikusten du.

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

Unbound zati horrek tunelaren pooletik datozen kontsultak onartzen ditu eta gainerako guztia ukatzen du, eta horixe da resolver korporatibo gehienek nahi duten politika. Instantzia berak LAN bezeroei ere erantzuten badie, gehitu LAN aurrizkia berariaz, entzulea iturri guztietara zabaldu beharrean.

Gero suebakiko arauek resolverraren beraren sarbide-kontrolekin bat egin behar dute. Onartu 53 portua pooletik eta baztertu beste guztietatik, baina egiaztatu lehenago katearen ordena.

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

Lehenagoko onarpen-arau zabalago batek azken bi lerroak apaingarri bihurtzen ditu, eta resolverra internetetik irisgarri jarraitzen du. Irakurri benetako arau-multzoa kontagailuekin, asmo duzun ordenan fidatu beharrean. Politika alternatiboak, helbide publikoa bidaliz eta edozein iturritako kontsultak onartuz, bezero askorentzat funtzionatzen du, baina resolverra interneten jartzen du eta bere abiadura-muga eta monitoretza behar ditu.

Egiaztatu bezeroak benetan zer jaso duen

Egiaztatu lehenengo zerbitzariaren ikuspegia, gero bezeroarena, biak modu informatiboan desadosten baitira. Pool zerrenda batek erakusten du zein helbide alokatu zen, eta segurtasun-elkarteen zerrendak erakusten du konexioa espero zen identitatearekin dagoen.

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

Kontsulta zuzenean frogatzen du resolverrak poolaren helbidean erantzuten duela hara irits daitekeen ostalari batetik. Ez du frogatzen Mac-ak zerbitzari hori aukeratu zuenik. macOS-en scutil --dns resolvers zerrendatzen ditu zerbitzu esparrutan eta laburpen paneleak baino informazio gehiago ematen du; Windows-en Get-DnsClientServerAddress erakusten du tunel egokitzaileak bidalitako balioa onartu duen.

Bezeroak poolaren helbidea erakusten badu eta kontsultak oraindik denbora-muga gainditzen badute, tunelaren bidea edo suebakien katea da erruduna. Resolverrik ez duen bezero batek konfigurazio-karga inoiz iritsi ez zela esan nahi du, beraz begiratu plataforma horrek bidalitako ezarpenak nola aplikatzen dituen eta ez sarea. Idatzi bi kasuetako zein behatu duzun beste ezer aldatu aurretik. Bi hutsegite horiek berdinak dirudite laguntza-txartel batean eta kontrako konponketetara daramate.