StrongSwan stjoert in DNS-adres dy't de Mac net berikke kin

Alles wurket oant immen in MacBook iepenet. De tunnel komt ta stân, ynterne hosts antwurdzje op adres, en nameresolúsje stjert. Op 'e iPhone hâldt itselde profyl him itselde, wylst de Windows- en Linux-kliïnten goed binne. Meastentiids is it stjoerde DNS-attribút de skuldige: de tsjinner dielt syn eigen iepenbiere ynterface-adres út, en de IKEv2-kliïnt fan Apple stjoert dêr gjin fragen troch de tunnel hinne. Ferpleats de resolver yn 'e pool, en it symptoom ferdwynt sûnder de kliïnt oan te reitsjen.

It symptoom wiist nei it stjoerde adres

As allinnich guon platfoarms misse, binne de tunnel en de oanmeldgegevens hast wis yn oarder, om't dy dield wurde. Wat ferskilt, is hoe't elke kliïnt de konfiguraasjelading tapast dy't er krijt, ynklusyf de ynterne DNS-tsjinner. In kliïnt dy't it adres akseptearret mar fragen om 'e tunnel hinne stjoert, einiget mei in resolver dy't er sjocht en net brûke kin.

It iepenbiere adres is de gewoane kar, om't it it iene is dat de behearder al ken. It is ek it iene adres dat garandearre bûten it eigen prefix fan 'e tunnel leit, en krekt dy eigenskip brekt de kliïnten fan Apple.

Besjoch de wearde foardat jo wat feroarje. As de stjoerde resolver it WAN-adres fan 'e tsjinner is, hawwe jo de foarm fan it probleem fûn en kinne jo de rest fan it rieden oerslaan. Fergelykje it ek mei it pool-prefix, want in adres binnen de pool mar bûten it útjûne berik is krekt hoe't de oplossing derút komme sil. Twa minuten mei de konfiguraasje ferslaan in middei pakketopnames op 'e kliïnt.

Snij de resolver út it útjûne berik

Jou de tunnel in adresplan wêryn't de resolver lid is fan it eigen subnet fan 'e pool, en reservearje dan dat adres sadat it nea oan in kliïnt útjûn wurdt. Yn dit foarbyld is de pool 10.180.7.0/24, hâldt de tsjinner 10.180.7.1, en begjinne de útjeften by 10.180.7.2.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

It pool-prefix en de resolver diele in subnet, dat de rûte dy't al tunnelferkear draacht, draacht ek de fragen. Krekt dy iene eigenskip makket de oplossing oerdraachber oer kliïnten. Yn in swanctl-konfiguraasje ferskine deselde twa feiten as in pooldefinysje en in DNS-ynstelling op 'e ferbining ynstee fan yn ipsec.conf-syntaks.

De tsjinner hat hjirfoar gjin nije fysike ynterface nedich. 10.180.7.1 tafoegje oan 'e loopback-ynterface is genôch foar in resolver om te binen en te antwurdzjen, om't kliïnten him berikke fia de pool-rûte dy't al bestiet. Hâld it adres bûten it útjûne berik sadat gjin kliïnt it by ûngelok nimme kin. As de pool beheard wurdt troch in eksterne DHCP- of RADIUS-tsjinst, reservearje it adres dêr ek, oars nimt de earste kliïnt dy't freget it.

Bin de resolver en slút poarte 53

In adres tawize is net itselde as derop harkje. In resolver dy't allinnich op it LAN-adres harket, sil fragen nei it pool-adres wegerje of negearje, en de kliïnt sjocht in tiidferrin dat op in rûteflater liket.

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

Dat unbound-fragmint akseptearret fragen fan 'e tunnelpool en wegeret al it oare, wat it belied is dat de measte bedriuwsresolvers wolle. As deselde eksimplaar ek LAN-kliïnten antwurdet, foegje it LAN-prefix dan eksplisyt ta ynstee fan de harker nei alle boarnen te ferbreedzjen.

Dêrnei moatte de firewall-regels oerienkomme mei de eigen tagongskontrôle fan 'e resolver. Akseptearje poarte 53 fan 'e pool, en smyt it oeral oars weil, mar kontrolearje earst de folchoarder fan 'e keatling.

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

In eardere, bredere akseptaasjeregel makket dy lêste twa rigels dekoratyf, en de resolver bliuwt berikber fan it ynternet. Lês de effektive regelset mei de tellers ynstee fan te fertrouwen op 'e folchoarder dy't jo bedoelden. It alternatyf belied, it iepenbiere adres stjoere en fragen fan elke boarne tastean, wurket foar in protte kliïnten, mar set de resolver op it ynternet en hat syn eigen taryfbeheining en monitoring nedich.

Kontrolearje wat de kliïnt eins krigen hat

Kontrolearje earst it byld fan 'e tsjinner, dan dat fan 'e kliïnt, om't de twa op ynformative wizen ferskille. In poollist litte sjen hokker adres útjûn is, en de list fan befeiligingsassosjaasjes lit sjen oft de ferbining oerút is mei de ferwachte identiteit.

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

De direkte fraach bewiist dat de resolver antwurdet op it pool-adres fan in host dy't him berikke kin. It bewiist net dat de Mac dy tsjinner keazen hat. Op macOS listet scutil --dns resolvers per beheinde tsjinst en is ynformativer as it oersichtspaniel; op Windows lit Get-DnsClientServerAddress sjen oft de tunneladapter de stjoerde wearde akseptearre hat.

As de kliïnt it pool-adres sjen lit en de fragen dochs noch tiidferrinne, is it de tunnelrûte of de firewall-keatling dy't skuld hat. In kliïnt dy't gjin resolver rapportearret, betsjut dat de konfiguraasjelading nea oankommen is, dus sjoch hoe't dat platfoarm stjoerde ynstellingen tapast ynstee fan nei it netwurk. Skriuw op hokker fan 'e twa gefallen jo seagen foardat jo wat oars feroarje. Dy twa flaters lykje identyk yn in stipekaart en liede ta tsjinoerstelde reparaasjes.