StrongSwan sendir DNS-vistfangi sem Macinn kemst ekki í
Mac eða iPhone hunsar opinbert vistfang leysisins sem StrongSwan-þjónninn þinn sendir. Færðu leysinn inn í biðlara-hópinn og takmarkaðu gátt 53 við hann.
Allt virkar þar til einhver opnar MacBook. Göngin koma upp, innri hýslar svara eftir vistfangi og nafnaleysing deyr. Á iPhone hegðar sama prófíll sér á sama hátt, á meðan Windows- og Linux-biðlarar eru í lagi. Venjulega er DNS-eigindin sem er ýtt á lagið: þjónninn deilir sínu eigin opinberu viðmótsvistfangi, og IKEv2-biðlari Apple sendir ekki fyrirspurnir þangað í gegnum göngin. Færðu leysinn inn í hópinn og einkennin hverfa án þess að snerta biðlarann.
Einkennin benda á vistfangið sem er ýtt á
Þegar aðeins sumir vettvangar mistakast eru göngin og skilríkin næstum örugglega í lagi, því þau eru sameiginleg. Það sem er öðruvísi er hvernig hver biðlari beytir stillingarbyrðinni sem hann fær, þar á meðal innri DNS-þjóninum. Biðlari sem samþykkir vistfangið en beinir fyrirspurnum fram hjá göngunum endar með leysi sem hann sér og getur ekki notað.
Opinbera vistfangið er venjulegi kosturinn því það er það eina sem stjórnandinn þekkir nú þegar. Það er líka eina vistfangið sem er tryggt utan eigin forskeytis gagnanna, og einmitt sú eiginleiki brýtur Apple-biðlarana.
Skoðaðu gildið áður en þú breytir einhverju. Ef leysirinn sem er ýtt á er WAN-vistfang þjónsins hefurðu fundið lögun vandans og getur sleppt restinni af giskunum. Berðu það saman við forskeyti hópsins líka, því vistfang inni í hópnum en utan leigubilsins er einmitt það sem lagfæringin mun líta út eins og. Tvær mínútur með stillingunni eru betri en síðdegi af pakkaneti á biðlaranum.
Skera leysinn út úr leigubilinu
Gefðu göngunum vistfangaáætlun þar sem leysirinn er meðlimur í eigin undirneti hópsins, og taktu þá vistfangið frá þannig að það verði aldrei leigt neinum biðlara. Í þessu dæmi er hópurinn 10.180.7.0/24, þjónninn heldur 10.180.7.1 og leigur hefjast á 10.180.7.2.
rightsourceip=10.180.7.2/24
rightdns=10.180.7.1Forskeyti hópsins og leysirinn deila undirneti, svo leiðin sem þegar ber gönguliðið ber líka fyrirspurnirnar. Einmitt þessi eina eiginleiki gerir lagfæringuna færanlega milli biðlara. Í swanctl-stillingu koma sömu tvær staðreyndir fram sem skilgreining hóps og DNS-stilling á tengingunni í stað ipsec.conf-setningar.
Þjónninn þarf ekki nýtt líkamlegt viðmót fyrir þetta. Að bæta 10.180.7.1 við loopback-viðmótið er nóg fyrir leysi að bindast og svara, því biðlarar ná honum í gegnum leið hópsins sem er þegar til. Hafðu vistfangið utan leigubilsins svo enginn biðlari grípi það fyrir slysni. Ef hópurinn er stýrður af ytri DHCP- eða RADIUS-þjónustu skaltu taka vistfangið frá þar líka, annars tekur fyrsti biðlarinn sem spyr það.
Bindu leysinn og lokaðu gátt 53
Að úthluta vistfangi er ekki það sama og að hlusta á það. Leysir sem hlustar aðeins á LAN-vistfangið mun hafna eða hunsa fyrirspurnir sem sendar eru á vistfang hópsins, og biðlarinn sér tímalok sem lítur út eins og leiðarvilla.
interface: 10.180.7.1
access-control: 10.180.7.0/24 allow
access-control: 0.0.0.0/0 refuseÞessi unbound-bútur tekur við fyrirspurnum frá hópi ganganna og hafnar öllu öðru, sem er stefnan sem flestir fyrirtækjaleysar vilja. Ef sama tilvikið svarar líka LAN-biðlurum skaltu bæta LAN-forskeytinu við sérstaklega í stað þess að víkka hlustandann út í allar uppsprettur.
Þá verða eldveggjarreglurnar að samræmast aðgangsstýringu leysisins sjálfs. Samþykktu gátt 53 frá hópnum og hentu henni alls staðar annars staðar, en athugaðu fyrst röð keðjunnar.
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 DROPFyrri og víðtækari samþykktarregla gerir síðustu tvær línurnar að skrauti, og leysirinn er áfram aðgengilegur frá internetinu. Lestu virka reglusafnið með telurunum í stað þess að treysta á röðina sem þú ætlaðir. Hin stefnan, að ýta á opinbera vistfangið og leyfa fyrirspurnir frá hvaða uppsprettu sem er, virkar fyrir marga biðlara, en setur leysinn á internetið og þarf eigin hraðatakmörkun og eftirlit.
Staðfestu hvað biðlarinn fékk í raun
Athugaðu sýn þjónsins fyrst, svo þá biðlarans, því þær tveir eru ósammála á upplýsandi hátt. Hópalisti sýnir hvaða vistfang var leigt, og listi öryggjabandalaga sýnir hvort tengingin er uppi með væntanlegri auðkenni.
swanctl --list-sas
swanctl --list-pools
dig +short @10.180.7.1 intranet.plant.exampleBeina fyrirspurnin sannar að leysirinn svarar á vistfangi hópsins frá hýsil sem kemst á hann. Hún sannar ekki að Macinn hafi valið þann þjón. Á macOS telur scutil --dns upp leysa fyrir hverja afmarkaða þjónustu og er upplýsandi en yfirlitsglugginn; á Windows sýnir Get-DnsClientServerAddress hvort gönguadapterinn samþykkti gildið sem var ýtt á.
Ef biðlarinn sýnir vistfang hópsins og fyrirspurnir tímalokna samt, er það leið ganganna eða eldveggjakeðjan sem er sek um það. Biðlari sem tilkynnir engan leysi þýðir að stillingarbyrðin komst aldrei, svo skoðaðu hvernig sá vettvangur beytir stillingum sem er ýtt á í stað netkerfisins. Skrifaðu niður hvor þessara tveggja tilfella þú sást áður en þú breytir einhverju öðru. Þessir tveir gallar líta eins út í stuðningsmiða og leiða til gagnvægra lagfæringa.