StrongSwan lähettää DNS-osoitteen, johon Mac ei pääse

Kaikki toimii, kunnes joku avaa MacBookin. Tunneli muodostuu, sisäiset isännät vastaavat osoitteella ja nimien selvitys kuolee. iPhonessa sama profiili käyttäytyy samoin, kun taas Windows- ja Linux-asiakkaat ovat kunnossa. Yleensä syyllinen on työnnetty DNS-attribuutti: palvelin jakaa oman julkisen liitäntäosoitteensa, eikä Applen IKEv2-asiakas lähetä kyselyitä sinne tunnelin kautta. Siirrä resolver poolin sisään, ja oire katoaa koskematta asiakkaaseen.

Oire osoittaa työnnettyyn osoitteeseen

Kun vain jotkin alustat epäonnistuvat, tunneli ja tunnistetiedot ovat lähes varmasti kunnossa, koska ne ovat yhteisiä. Ero on siinä, miten kukin asiakas soveltaa vastaanottamaansa kokoonpanokuormaa, mukaan lukien sisäinen DNS-palvelin. Asiakas, joka hyväksyy osoitteen mutta ohjaa kyselyt tunnelin ohi, päätyy resolveriin, jonka se näkee eikä voi käyttää.

Julkinen osoite on tavallinen valinta, koska se on ainoa, jonka ylläpitäjä jo tietää. Se on myös ainoa osoite, joka on taatusti tunnelin oman etuliitteen ulkopuolella, ja juuri tämä ominaisuus rikkoo Applen asiakkaat.

Katso arvoa ennen kuin muutat mitään. Jos työnnetty resolver on palvelimen WAN-osoite, olet löytänyt ongelman muodon ja voit ohittaa loput arvailut. Vertaa sitä myös poolin etuliitteeseen, sillä osoite poolin sisällä mutta vuokrausalueen ulkopuolella on juuri se, miltä korjaus näyttää. Kaksi minuuttia kokoonpanon kanssa voittaa iltapäivän pakettikaappauksia asiakkaassa.

Leikkaa resolver vuokrausalueen ulkopuolelle

Anna tunnelille osoitesuunnitelma, jossa resolver on poolin oman aliverkon jäsen, ja varaa sitten tämä osoite, ettei sitä koskaan vuokrata asiakkaalle. Tässä esimerkissä pool on 10.180.7.0/24, palvelin pitää 10.180.7.1 ja vuokrat alkavat 10.180.7.2:sta.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

Poolin etuliite ja resolver jakavat aliverkon, joten reitti, joka jo kuljettaa tunneliliikennettä, kuljettaa myös kyselyt. Juuri tämä yksi ominaisuus tekee korjauksesta siirrettävän asiakkaiden välillä. Swanctl-kokoonpanossa samat kaksi tosiasiaa esiintyvät poolin määritelmänä ja yhteyden DNS-asetuksena eikä ipsec.conf-syntaksissa.

Palvelin ei tarvitse tähän uutta fyysistä liitäntää. 10.180.7.1:n lisääminen loopback-liitäntään riittää, jotta resolver voi sitoa ja vastata, koska asiakkaat saavuttavat sen jo olemassa olevan poolin reitin kautta. Pidä osoite vuokrausalueen ulkopuolella, ettei kukaan asiakas ota sitä vahingossa. Jos poolia hallinnoi ulkoinen DHCP- tai RADIUS-palvelu, varaa osoite myös siellä, muuten ensimmäinen kysyvä asiakas ottaa sen.

Sido resolver ja sulje portti 53

Osoitteen määrittäminen ei ole sama kuin sillä kuunteleminen. Resolver, joka kuuntelee vain LAN-osoitteessa, hylkää tai jättää huomiotta poolin osoitteeseen lähetetyt kyselyt, ja asiakas näkee aikakatkaisun, joka näyttää reititysvirheeltä.

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

Tämä unbound-fragmentti hyväksyy kyselyt tunnelipoolista ja hylkää kaiken muun, mikä on käytäntö, jota useimmat yritysresolverit haluavat. Jos sama instanssi vastaa myös LAN-asiakkaille, lisää LAN-etuliite nimenomaisesti sen sijaan, että laajentaisit kuuntelijan kaikkiin lähteisiin.

Sitten palomuurisääntöjen on sovittava resolverin oman käyttöoikeudenvalvonnan kanssa. Hyväksy portti 53 poolista ja hylkää se kaikkialla muualla, mutta tarkista ensin ketjun järjestys.

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

Aiempi, laajempi hyväksyntäsääntö tekee kahdesta viimeisestä rivistä koristeellisia, ja resolver pysyy saavutettavissa internetistä. Lue tehokas sääntöjoukko laskureineen sen sijaan, että luottaisit aikomaasi järjestykseen. Vaihtoehtoinen käytäntö, julkisen osoitteen työntäminen ja kyselyiden salliminen mistä tahansa lähteestä, toimii monille asiakkaille, mutta asettaa resolverin internetiin ja vaatii oman nopeusrajoituksen ja valvonnan.

Varmista, mitä asiakas todella vastaanotti

Tarkista ensin palvelimen näkymä, sitten asiakkaan, koska ne eroavat toisistaan valaisevasti. Poolin listaus näyttää, mikä osoite vuokrattiin, ja suojausturvaliittojen listaus näyttää, onko yhteys pystyssä odotetulla identiteetillä.

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

Suora kysely todistaa, että resolver vastaa poolin osoitteessa isännästä, joka pääsee siihen. Se ei todista, että Mac valitsi juuri tämän palvelimen. MacOS:ssä scutil --dns listaa resolverit rajattua palvelua kohden ja on valaisevampi kuin yhteenvetopaneeli; Windowsissa Get-DnsClientServerAddress näyttää, hyväksyikö tunnelisovitin työnnetyn arvon.

Jos asiakas näyttää poolin osoitteen ja kyselyt silti aikakatkeavat, syyllinen on tunnelin reitti tai palomuuriketju. Asiakas, joka ei raportoi yhtään resolveria, tarkoittaa, että kokoonpanokuorma ei koskaan saapunut, joten katso, miten kyseinen alusta soveltaa työnnettyjä asetuksia, älä verkkoa. Kirjoita muistiin, kumman kahdesta tapauksesta havaitsit, ennen kuin muutat mitään muuta. Nämä kaksi vikaa näyttävät tukipyynnössä samoilta ja johtavat vastakkaisiin korjauksiin.