StrongSwan sūta DNS adresi, kuru Mac nevar sasniegt

Viss darbojas, līdz kāds atver MacBook. Tunelis tiek izveidots, iekšējie resursi atbild pēc adreses, un vārdu izšķiršana mirst. iPhone tā pati konfigurācija uzvedas tāpat, kamēr Windows un Linux klienti ir kārtībā. Parasti vainīgais ir sūtītais DNS atribūts: serveris izplata savu publisko saskarnes adresi, un Apple IKEv2 klients caur tuneli uz turieni vaicājumus nesūta. Pārvietojiet resolveri pūla iekšpusē, un simptoms pazūd, klientam nepiekļūstot.

Simptoms norāda uz sūtīto adresi

Kad neizdodas tikai dažas platformas, tunelis un akreditācijas dati gandrīz noteikti ir kārtībā, jo tie ir kopīgi. Atšķiras tas, kā katrs klients piemēro saņemto konfigurācijas kravu, tostarp iekšējo DNS serveri. Klients, kas pieņem adresi, bet vaicājumus novirza apkārt tunelim, nonāk pie resolvera, ko redz un nevar izmantot.

Publiskā adrese ir ierastā izvēle, jo tā ir vienīgā, ko administrators jau zina. Tā ir arī vienīgā adrese, kas garantēti atrodas ārpus paša tuneļa prefiksa, un tieši šī īpašība salauž Apple klientus.

Apskatiet vērtību, pirms kaut ko maināt. Ja sūtītais resolvers ir servera WAN adrese, esat atradis problēmas formu un varat izlaist pārējos minējumus. Salīdziniet to arī ar pūla prefiksu, jo adrese pūla iekšpusē, bet ārpus nomāšanas diapazona ir tieši tas, kā izskatīsies labojums. Divas minūtes ar konfigurāciju ir labākas par pēcpusdienu, ķerot paketes klientā.

Izgrieziet resolveri no nomāšanas diapazona

Dodiet tunelim adrešu plānu, kurā resolvers ir pūla paša apakštīkla dalībnieks, pēc tam rezervējiet šo adresi, lai tā nekad netiktu iznomāta nevienam klientam. Šajā piemērā pūls ir 10.180.7.0/24, serveris tur 10.180.7.1, un nomas sākas ar 10.180.7.2.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

Pūla prefikss un resolvers dala apakštīklu, tāpēc maršruts, kas jau pārvadā tuneļa trafiku, pārvadā arī vaicājumus. Tieši šī vienīgā īpašība padara labojumu pārnesamu starp klientiem. swanctl konfigurācijā tie paši divi fakti parādās kā pūla definīcija un DNS iestatījums savienojumā, nevis ipsec.conf sintaksē.

Serverim tam nav vajadzīga jauna fiziska saskarne. 10.180.7.1 pievienošana loopback saskarnei ir pietiekama, lai resolvers piesaistītos un atbildētu, jo klienti to sasniedz pa jau esošo pūla maršrutu. Turiet adresi ārpus nomāšanas diapazona, lai neviens klients to nejauši neaizņemtu. Ja pūlu pārvalda ārējs DHCP vai RADIUS serviss, rezervējiet adresi arī tur, citādi to paņems pirmais klients, kas jautā.

Piesaistiet resolveri un aizveriet 53. portu

Adreses piešķiršana nav tas pats, kas klausīšanās uz tās. Resolvers, kas klausās tikai LAN adresē, noraidīs vai ignorēs vaicājumus, kas sūtīti uz pūla adresi, un klients redz taimautu, kas izskatās kā maršrutēšanas kļūda.

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

Šis unbound fragments pieņem vaicājumus no tuneļa pūla un noraida visu pārējo, kas ir politika, ko vēlas lielākā daļa uzņēmumu resolveru. Ja tā pati instance atbild arī LAN klientiem, skaidri pievienojiet LAN prefiksu, nevis paplašiniet klausītāju uz visiem avotiem.

Pēc tam ugunsmūra noteikumiem jāsaskan ar paša resolvera piekļuves kontroli. Pieņemiet 53. portu no pūla un nometiet to visur citur, bet vispirms pārbaudiet ķēdes secību.

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

Agrāks, plašāks pieņemšanas noteikums padara pēdējās divas rindas par dekorāciju, un resolvers paliek sasniedzams no interneta. Lasiet efektīvo noteikumu kopu ar skaitītājiem, nevis paļaujieties uz paredzēto secību. Alternatīvā politika, sūtīt publisko adresi un atļaut vaicājumus no jebkura avota, darbojas daudziem klientiem, bet novieto resolveri internetā un prasa savu ātruma ierobežošanu un uzraudzību.

Pārbaudiet, ko klients faktiski saņēma

Vispirms pārbaudiet servera skatījumu, tad klienta, jo abi informatīvi atšķiras. Pūla saraksts parāda, kura adrese tika iznomāta, un drošības asociāciju saraksts parāda, vai savienojums ir pacelts ar gaidīto identitāti.

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

Tiešais vaicājums pierāda, ka resolvers atbild pūla adresē no resursa, kas to var sasniegt. Tas nepierāda, ka Mac izvēlējās tieši šo serveri. macOS scutil --dns uzskaita resolverus pa ierobežotu pakalpojumu un ir informatīvāks par kopsavilkuma paneli; Windows Get-DnsClientServerAddress parāda, vai tuneļa adapteris pieņēma sūtīto vērtību.

Ja klients rāda pūla adresi un vaicājumi joprojām beidzas ar taimautu, vainīgs ir tuneļa maršruts vai ugunsmūra ķēde. Klients, kas neziņo ne par vienu resolveri, nozīmē, ka konfigurācijas krava nekad nav pienākusi, tāpēc skatieties, kā šī platforma piemēro sūtītos iestatījumus, nevis tīklu. Pierakstiet, kuru no diviem gadījumiem novērojāt, pirms maināt ko citu. Šie divi traucējumi atbalsta pieteikumā izskatās vienādi un ved pie pretējiem labojumiem.