StrongSwan dërgon një adresë DNS që Mac nuk e arrin

Gjithçka funksionon derisa dikush hap një MacBook. Tuneli vendoset, hostet e brendshme përgjigjen me adresë, dhe zgjidhja e emrave vdes. Në iPhone i njëjti profil sillet njësoj, ndërsa klientët Windows dhe Linux janë në rregull. Atributi DNS i dërguar zakonisht është fajtori: serveri shpërndan adresën e ndërfaqes së vet publike, dhe klienti IKEv2 i Apple nuk dërgon kërkesa atje përmes tunelit. Zhvendoseni zgjidhësin brenda grupit dhe simptoma zhduket pa prekur klientin.

Simptoma tregon adresën e dërguar

Kur dështojnë vetëm disa platforma, tuneli dhe kredencialet pothuajse me siguri janë në rregull, sepse janë të përbashkëta. Ajo që ndryshon është mënyra se si secili klient zbaton ngarkesën e konfigurimit që merr, përfshirë serverin DNS të brendshëm. Një klient që e pranon adresën por i drejton kërkesat rreth tunelit përfundon me një zgjidhës që e sheh dhe nuk mund ta përdorë.

Adresa publike është zgjedhja e zakonshme sepse është ajo që administratori tashmë e njeh. Është gjithashtu adresa e vetme e garantuar jashtë prefiksit të tunelit, që është pikërisht vetia që prish klientët Apple.

Shikoni vlerën përpara se të ndryshoni gjë. Nëse zgjidhësi i dërguar është adresa WAN e serverit, keni gjetur formën e problemit dhe mund të kaloni pjesën tjetër të hamendjes. Krahasojeni edhe me prefiksin e grupit, sepse një adresë që ndodhet brenda grupit por jashtë intervalit të dhënies është pikërisht ajo që do të duket rregullimi. Dy minuta me konfigurimin vlejnë më shumë se një pasdite kapjeje paketash në klient.

Nxirreni zgjidhësin jashtë intervalit të dhënies

Jepini tunelit një plan adresash ku zgjidhësi është anëtar i nënrrjetit të vetë grupit, pastaj rezervoni atë adresë që asnjë klient të mos e marrë kurrë me qira. Në këtë shembull grupi është 10.180.7.0/24, serveri mban 10.180.7.1, dhe dhëniet nisin nga 10.180.7.2.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

Prefiksi i grupit dhe zgjidhësi ndajnë një nënrrjet, kështu që rruga që tashmë mbart trafikun e tunelit mbart edhe kërkesat. Pikërisht kjo veti e bën rregullimin të transportueshëm mes klientëve. Në një konfigurim swanctl të njëjtat dy fakte shfaqen si përkufizim grupi dhe rregullim DNS në lidhje, jo në sintaksën ipsec.conf.

Serveri nuk ka nevojë për një ndërfaqe të re fizike për këtë. Shtimi i 10.180.7.1 në ndërfaqen loopback mjafton që një zgjidhës të lidhet dhe të përgjigjet, pasi klientët e arrijnë përmes rrugës së grupit që ekziston tashmë. Mbajeni adresën jashtë intervalit të dhënies që asnjë klient të mos e marrë aksidentalisht. Nëse grupi menaxhohet nga një shërbim i jashtëm DHCP ose RADIUS, rezervojeni adresën edhe atje, përndryshe klienti i parë që kërkon do ta marrë.

Lidhni zgjidhësin dhe mbyllni portën 53

Të caktosh një adresë nuk është njësoj si të dëgjosh në të. Një zgjidhës që dëgjon vetëm në adresën LAN do të refuzojë ose injorojë kërkesat e dërguara në adresën e grupit, dhe klienti sheh një skadim kohe që duket si dështim rrugëtimi.

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

Ky fragment unbound pranon kërkesat nga grupi i tunelit dhe refuzon gjithçka tjetër, që është politika që duan shumica e zgjidhësve korporativë. Nëse i njëjti instancë u përgjigjet edhe klientëve LAN, shtoni prefiksin LAN në mënyrë eksplicite në vend që të zgjeroni dëgjimin për të gjitha burimet.

Rregullat e firewall-it pastaj duhet të pajtohen me kontrollin e aksesit të vetë zgjidhësit. Pranoni portën 53 nga grupi, dhe hidheni atë nga kudo tjetër, por së pari kontrolloni renditjen e zinxhirit.

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

Një rregull më i hershëm dhe më i gjerë pranimi i bën ato dy rreshtat e fundit dekorativë, dhe zgjidhësi mbetet i arritshëm nga interneti. Lexoni grupin efektiv të rregullave me numëruesit në vend që t'i besoni renditjes që kishit ndërmend. Politika alternative, dërgimi i adresës publike dhe lejimi i kërkesave nga çdo burim, funksionon për shumë klientë, por e vendos zgjidhësin në internet dhe kërkon kufizim të vet ritmi dhe monitorim.

Verifikoni çfarë mori vërtet klienti

Kontrolloni së pari pamjen e serverit, pastaj atë të klientit, sepse të dyja nuk pajtohen në mënyra informuese. Një listë e grupit tregon cila adresë u dha me qira, dhe lista e shoqërimeve të sigurisë tregon nëse lidhja është ngritur me identitetin e pritur.

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

Kërkesa e drejtpërdrejtë provon që zgjidhësi përgjigjet në adresën e grupit nga një host që mund ta arrijë. Nuk provon që Mac-i zgjodhi atë server. Në macOS, scutil --dns liston zgjidhësit sipas shërbimit të fushës dhe është më informues se paneli përmbledhës; në Windows, Get-DnsClientServerAddress tregon nëse përshtatësi i tunelit e pranoi vlerën e dërguar.

Nëse klienti shfaq adresën e grupit dhe kërkesat ende skadojnë, rruga e tunelit ose zinxhiri i firewall-it është në faj. Një klient që nuk raporton asnjë zgjidhës do të thotë që ngarkesa e konfigurimit nuk mbërriti kurrë, prandaj shikoni si ajo platformë i zbaton rregullimet e dërguara, jo rrjetin. Shkruani cila nga të dyja vëzhguat përpara se të ndryshoni gjë tjetër. Ato dy dështime duken njësoj në një ticket mbështetjeje dhe çojnë në rregullime të kundërta.