StrongSwan inatuma anwani ya DNS ambayo Mac haifikii

Kila kitu hufanya kazi hadi mtu afungue MacBook. Handaki huanzishwa, wenyeji wa ndani hujibu kwa anwani, na utatuzi wa majina hufa. Kwenye iPhone wasifu huo huo hujiendesha vivyo hivyo, wakati wateja wa Windows na Linux wako sawa. Sifa ya DNS inayotumwa kwa kawaida ndiyo mchawi: seva hutoa anwani ya kiolesura chake cha umma, na mteja wa IKEv2 wa Apple hatumi maulizo huko kupitia handaki. Hamisha kitatuzi ndani ya bwawa na dalili itatoweka bila kugusa mteja.

Dalili inaelekeza kwenye anwani inayotumwa

Wakati mifumo mingine hushindwa pekee, handaki na vitambulisho viko sawa kwa uhakika, kwa sababu vinashirikiwa. Kinachotofautiana ni jinsi kila mteja anavyotumia mzigo wa usanidi anaoupokea, ikiwa ni pamoja na seva ya DNS ya ndani. Mteja anayekubali anwani lakini anaelekeza maulizo kuzunguka handaki huishia na kitatuzi anachokiona na hawezi kukitumia.

Anwani ya umma ndiyo chaguo la kawaida kwa sababu ndiyo ambayo msimamizi tayari anaifahamu. Pia ni anwani pekee inayohakikishwa kuwa nje ya kiambishi cha handaki, ambayo ndiyo sifa hasa inayovunja wateja wa Apple.

Angalia thamani kabla ya kubadilisha kitu. Ikiwa kitatuzi kinachotumwa ni anwani ya WAN ya seva, umepata umbo la tatizo na unaweza kuruka mabishano mengine ya kubahatisha. Linganisha pia na kiambishi cha bwawa, kwa kuwa anwani iliyo ndani ya bwawa lakini nje ya kipindi cha kukodisha ndiyo hasa jinsi suluhisho litakavyoonekana. Dakika mbili za usanidi hushinda mchana mzima wa kunasa pakiti kwenye mteja.

Toa kitatuzi nje ya kipindi cha kukodisha

Ipe handaki mpango wa anwani ambapo kitatuzi ni mwanachama wa subneti ya bwawa lenyewe, kisha hifadhi anwani hiyo ili mteja yeyote asikodishwe nayo kamwe. Katika mfano huu bwawa ni 10.180.7.0/24, seva inashikilia 10.180.7.1, na ukodishaji huanza 10.180.7.2.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

Kiambishi cha bwawa na kitatuzi hushiriki subneti, kwa hivyo njia ambayo tayari hubeba trafiki ya handaki pia hubeba maulizo. Sifa hiyo moja ndiyo inayofanya suluhisho liweze kuhamishwa kati ya wateja. Katika usanidi wa swanctl ukweli huo huo huonekana kama ufafanuzi wa bwawa na mpangilio wa DNS kwenye muunganisho, badala ya sintaksia ya ipsec.conf.

Seva haihitaji kiolesura kipya halisi kwa hili. Kuongeza 10.180.7.1 kwenye kiolesura cha loopback kunatosha kwa kitatuzi kufunga na kujibu, kwa kuwa wateja huifikia kupitia njia ya bwawa iliyopo tayari. Weka anwani nje ya kipindi cha kukodisha ili mteja yeyote asiiambue kwa bahati mbaya. Ikiwa bwawa linasimamiwa na huduma ya nje ya DHCP au RADIUS, hifadhi anwani huko pia, vinginevyo mteja wa kwanza kuuliza ataichukua.

Funga kitatuzi na funga bandari 53

Kugawa anwani si sawa na kusikiliza juu yake. Kitatuzi kinachosikiliza tu kwenye anwani ya LAN kitakataa au kupuuza maulizo yaliyotumwa kwenye anwani ya bwawa, na mteja huona muda wa kumalizika unaoonekana kama kushindwa kwa njia.

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

Kipande hicho cha unbound hukubali maulizo kutoka bwawa la handaki na kukataa kila kitu kingine, ambayo ndiyo sera ambayo vitatuzi vingi vya mashirika hutaka. Ikiwa mfano huo huo pia hujibu wateja wa LAN, ongeza kiambishi cha LAN kwa uwazi badala ya kupanua kusikiliza kwa vyanzo vyote.

Kanuni za firewall basi lazima zikubaliane na udhibiti wa ufikiaji wa kitatuzi chenyewe. Kubali bandari 53 kutoka bwawani, na uitupe kutoka kila mahali pengine, lakini kwanza angalia mpangilio wa mnyororo.

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

Kanuni ya mapema na pana zaidi ya kukubali hufanya mistari miwili ya mwisho kuwa ya mapambo, na kitatuzi huendelea kufikiwa kutoka mtandao. Soma seti halisi ya kanuni pamoja na vihesabu badala ya kuamini mpangilio uliokusudia. Sera mbadala, kutuma anwani ya umma na kuruhusu maulizo kutoka chanzo chochote, hufanya kazi kwa wateja wengi, lakini inaweka kitatuzi kwenye mtandao na inahitaji uwekaji kikomo wa kasi na ufuatiliaji wake.

Thibitisha kile mteja alichopokea kweli

Angalia mtazamo wa seva kwanza, kisha wa mteja, kwa sababu wawili hawakubaliani kwa namna yenye kufundisha. Orodha ya bwawa huonyesha ni anwani gani ilikodishwa, na orodha ya vyama vya usalama huonyesha kama muunganisho uko juu na utambulisho unaotarajiwa.

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

Ulizo la moja kwa moja huthibitisha kuwa kitatuzi hujibu kwenye anwani ya bwawa kutoka mwenyeji anayeweza kuifikia. Haithibitishi kuwa Mac ilichagua seva hiyo. Kwenye macOS, scutil --dns huorodhesha vitatuzi kwa kila huduma iliyo na wigo na ni yenye taarifa zaidi kuliko paneli ya muhtasari; kwenye Windows, Get-DnsClientServerAddress huonyesha kama adapta ya handaki ilikubali thamani iliyotumwa.

Ikiwa mteja anaonyesha anwani ya bwawa na maulizo bado yanakwisha muda, njia ya handaki au mnyororo wa firewall ndio wenye kosa. Mteja asiyeripoti kitatuzi chochote humaanisha kuwa mzigo wa usanidi haukuwasili kamwe, kwa hivyo angalia jinsi mfumo huo unavyotumia mipangilio iliyotumwa, sio mtandao. Andika ni ipi kati ya hizo mbili uliyoona kabla ya kubadilisha kitu kingine. Hitilafu hizo mbili huonekana sawa kwenye tikiti ya usaidizi na huongoza kwenye matengenezo kinyume.