StrongSwan saadab DNS-aadressi, kuhu Mac ei pääse

Kõik töötab, kuni keegi avab MacBooki. Tunnel luuakse, sisemised hostid vastavad aadressi järgi ja nimehulkus sureb. iPhone'is käitub sama profiil samamoodi, samas kui Windowsi ja Linuxi kliendid on korras. Tavaliselt on süüdlane saadetud DNS-atribuut: server jagab oma avalikku liidese aadressi ja Apple'i IKEv2 klient ei saada sinna päringuid läbi tunneli. Viige resolver pooli sisse ja sümptom kaob ilma klienti puutumata.

Sümptom osutab saadetud aadressile

Kui ainult mõned platvormid ei tööta, on tunnel ja mandaadid peaaegu kindlasti korras, sest need on ühised. Erineb see, kuidas iga klient rakendab saadud konfiguratsioonikoormat, sealhulgas sisemist DNS-serverit. Klient, kes võtab aadressi vastu, kuid suunab päringud tunnelist mööda, jääb resolveriga, mida ta näeb ega saa kasutada.

Avalik aadress on tavaline valik, sest see on ainus, mida administraator juba teab. See on ka ainus aadress, mis on garanteeritult väljaspool tunneli enda prefiksit, ja just see omadus rikub Apple'i kliente.

Vaadake väärtust enne, kui midagi muudate. Kui saadetud resolver on serveri WAN-aadress, olete leidnud probleemi kuju ja võite ülejäänud oletused vahele jätta. Võrrelge seda ka pooli prefiksiga, sest aadress, mis asub pooli sees, kuid rendivahemikust väljas, on täpselt see, milline parandus välja näeb. Kaks minutit konfiguratsiooniga on parem kui terve pärastlõuna paketipüüdmist kliendis.

Lõigake resolver rendivahemikust välja

Andke tunnelile aadressiplaan, kus resolver on pooli enda alamvõrgu liige, seejärel reserveerige see aadress, et seda ei renditaks kunagi ühelegi kliendile. Selles näites on pool 10.180.7.0/24, server hoiab 10.180.7.1 ja rendid algavad 10.180.7.2-st.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

Pooli prefiks ja resolver jagavad alamvõrku, seega marsruut, mis juba kannab tunneliliiklust, kannab ka päringuid. Just see üks omadus teeb paranduse klientide vahel ülekantavaks. Swanctl-konfiguratsioonis esinevad samad kaks fakti pooli definitsiooni ja ühenduse DNS-seadena, mitte ipsec.conf süntaksis.

Server ei vaja selleks uut füüsilist liidest. 10.180.7.1 lisamine loopback-liidesele on piisav, et resolver saaks siduda ja vastata, sest kliendid jõuavad selleni juba olemasoleva pooli marsruudi kaudu. Hoidke aadress rendivahemikust väljas, et ükski klient ei haaraks seda kogemata. Kui pooli haldab väline DHCP või RADIUS teenus, reserveerige aadress ka seal, muidu võtab selle esimene klient, kes küsib.

Siduge resolver ja sulgege port 53

Aadressi määramine ei ole sama, mis sellel kuulamine. Resolver, mis kuulab ainult LAN-aadressil, keeldub pooli aadressile saadetud päringutest või eirab neid, ja klient näeb ajalõppu, mis näeb välja nagu marsruutimise tõrge.

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

See unbound fragment võtab vastu päringuid tunnelipoolist ja keeldub kõigest muust, mis on poliitika, mida enamik ettevõtete resolvereid tahab. Kui sama eksemplar vastab ka LAN-klientidele, lisage LAN-prefiks selgesõnaliselt, selle asemel et laiendada kuulajat kõikidele allikatele.

Seejärel peavad tulemüürireeglid ühtima resolveri enda juurdepääsukontrolliga. Võtke vastu port 53 poolist ja loobuge sellest kõikjal mujal, kuid kontrollige esmalt ahela järjekorda.

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

Varasem, laiem vastuvõtureegel muudab kaks viimast rida dekoratiivseks ja resolver jääb internetist kättesaadavaks. Lugege kehtivat reeglistikku loenduritega, selle asemel et usaldada kavatsetud järjekorda. Alternatiivne poliitika, saata avalik aadress ja lubada päringuid mis tahes allikast, töötab paljude klientide puhul, kuid asetab resolveri internetti ja vajab oma kiiruspiirangut ja jälgimist.

Kontrollige, mida klient tegelikult sai

Kontrollige kõigepealt serveri vaadet, seejärel kliendi oma, sest need kaks erinevad informatiivselt. Pooli loend näitab, milline aadress renditi, ja turbeseoste loend näitab, kas ühendus on üleval oodatud identiteediga.

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

Otsene päring tõestab, et resolver vastab pooli aadressil hostist, mis pääseb sellele ligi. See ei tõesta, et Mac valis just selle serveri. MacOS-is loetleb scutil --dns resolverid iga piiratud teenuse kohta ja on informatiivsem kui kokkuvõtvaade; Windowsis näitab Get-DnsClientServerAddress, kas tunneladapter võttis saadetud väärtuse vastu.

Kui klient näitab pooli aadressi ja päringud aeguvad endiselt, on süüdi tunnelimarsruut või tulemüüriahel. Klient, kes ei teata ühtegi resolverit, tähendab, et konfiguratsioonikoorem ei jõudnud kunagi kohale, seega vaadake, kuidas see platvorm saadetud seadeid rakendab, mitte võrku. Kirjutage üles, kumba kahest juhtumist te nägite, enne kui midagi muud muudate. Need kaks tõrget näevad toe piletis identsed välja ja viivad vastupidiste parandusteni.