StrongSwan-ը ուղարկում է DNS հասցե, որին Mac-ը չի կարող հասնել

Ամեն ինչ աշխատում է, մինչև ինչ-որ մեկը բացում է MacBook։ Թունելը հաստատվում է, ներքին հոսթերը պատասխանում են հասցեով, և անունների լուծումը մահանում է։ iPhone-ում նույն պրոֆիլը վարվում է նույն կերպ, մինչդեռ Windows-ի և Linux-ի հաճախորդները լավ են։ Սովորաբար մեղավորը ուղարկված DNS հատկանիշն է։ Սերվերը տրամադրում է իր սեփական հանրային ինտերֆեյսի հասցեն, և Apple-ի IKEv2 հաճախորդը թունելի միջով այնտեղ հարցումներ չի ուղարկում։ Տեղափոխեք լուծիչը լողավազանի ներսում, և ախտանիշը կանհետանա՝ առանց հաճախորդին դիպչելու։

Ախտանիշը մատնանշում է ուղարկված հասցեին

Երբ ձախողվում են միայն որոշ պլատֆորմներ, թունելը և հավատարմագրերը գրեթե անշուշտ լավ են, որովհետև դրանք ընդհանուր են։ Տարբերվում է այն, թե ինչպես է յուրաքանչյուր հաճախորդ կիրառում ստացած կոնֆիգուրացիայի բեռը, ներառյալ ներքին DNS սերվերը։ Այն հաճախորդը, որը ընդունում է հասցեն, բայց հարցումները շրջանցում է թունելը, հայտնվում է լուծիչի հետ, որը տեսնում է և չի կարող օգտագործել։

Հանրային հասցեն սովորական ընտրություն է, որովհետև այն միակն է, որը ադմինիստրատորն արդեն գիտի։ Այն նաև միակ հասցեն է, որը երաշխավորված է թունելի սեփական նախածանցից դուրս, և հենց այդ հատկությունն է կոտրում Apple-ի հաճախորդներին։

Նայեք արժեքին, մինչև որևէ բան փոխելը։ Եթե ուղարկված լուծիչը սերվերի WAN հասցեն է, դուք գտել եք խնդրի ձևը և կարող եք բաց թողնել մնացած գուշակությունները։ Համեմատեք այն լողավազանի նախածանցի հետ նույնպես, որովհետև լողավազանի ներսում, բայց վարձակալության տիրույթից դուրս գտնվող հասցեն հենց այն է, ինչպիսին կլինի ուղղումը։ Երկու րոպեն կոնֆիգուրացիայի հետ ավելի լավ է, քան հաճախորդի վրա ամբողջ կեսօր փաթեթների որսը։

Կտրեք լուծիչը վարձակալության տիրույթից

Տվեք թունելին հասցեների պլան, որտեղ լուծիչը լողավազանի սեփական ենթացանցի անդամ է, ապա վերապահեք այդ հասցեն, որպեսզի այն երբեք չտրվի ոչ մի հաճախորդի։ Այս օրինակում լողավազանը 10.180.7.0/24 է, սերվերը պահում է 10.180.7.1-ը, և վարձակալությունները սկսվում են 10.180.7.2-ից։

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

Լողավազանի նախածանցը և լուծիչը կիսում են ենթացանցը, ուստի այն երթուղին, որն արդեն կրում է թունելի երթևեկությունը, կրում է նաև հարցումները։ Հենց այդ մեկ հատկությունն է ուղղումը տեղափոխելի դարձնում հաճախորդների միջև։ swanctl կոնֆիգուրացիայում նույն երկու փաստերը հայտնվում են որպես լողավազանի սահմանում և DNS կարգավորում կապի վրա, այլ ոչ թե ipsec.conf շարահյուսության մեջ։

Սերվերին դրա համար նոր ֆիզիկական ինտերֆեյս պետք չէ։ 10.180.7.1-ը loopback ինտերֆեյսին ավելացնելը բավական է, որպեսզի լուծիչը կապվի և պատասխանի, քանի որ հաճախորդները հասնում են դրան արդեն գոյություն ունեցող լողավազանի երթուղով։ Պահեք հասցեն վարձակալության տիրույթից դուրս, որպեսզի ոչ մի հաճախորդ պատահաբար չզավթի այն։ Եթե լողավազանը կառավարվում է արտաքին DHCP կամ RADIUS ծառայությամբ, վերապահեք հասցեն նաև այնտեղ, այլապես առաջին հարցնող հաճախորդը կվերցնի այն։

Կապեք լուծիչը և փակեք 53 պորտը

Հասցե նշանակելը նույնը չէ, ինչ դրա վրա լսելը։ Այն լուծիչը, որը լսում է միայն LAN հասցեին, կմերժի կամ կանտեսի լողավազանի հասցեին ուղարկված հարցումները, և հաճախորդը տեսնում է ժամանակավարտ, որը նման է երթուղավորման ձախողման։

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

Այս unbound հատվածը ընդունում է լողավազանից եկող հարցումները և մերժում մնացած ամեն ինչ, ինչը այն քաղաքականությունն է, որը ցանկանում են կորպորատիվ լուծիչների մեծ մասը։ Եթե նույն օրինակը պատասխանում է նաև LAN հաճախորդներին, ավելացրեք LAN նախածանցը բացահայտ, լսողին բոլոր աղբյուրներին ընդլայնելու փոխարեն։

Այնուհետև ֆայրվոլի կանոնները պետք է համընկնեն լուծիչի սեփական հասանելիության վերահսկման հետ։ Ընդունեք 53 պորտը լողավազանից և մերժեք այն ամենուր այլ տեղ, բայց նախ ստուգեք շղթայի կարգը։

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

Ավելի վաղ, ավելի լայն ընդունման կանոնը վերջին երկու տողերը դարձնում է դեկորատիվ, և լուծիչը մնում է հասանելի ինտերնետից։ Կարդացեք գործող կանոնների հավաքածուն հաշվիչներով, այլ ոչ թե վստահեք նախատեսված կարգին։ Այլընտրանքային քաղաքականությունը՝ ուղարկել հանրային հասցեն և թույլատրել հարցումներ ցանկացած աղբյուրից, աշխատում է շատ հաճախորդների համար, բայց լուծիչը դնում է ինտերնետում և պահանջում է իր սեփական արագության սահմանափակում և մոնիտորինգ։

Ստուգեք, թե ինչ է իրականում ստացել հաճախորդը

Նախ ստուգեք սերվերի տեսքը, ապա հաճախորդինը, որովհետև երկուսը տեղեկատվական կերպով հակասում են։ Լողավազանի ցանկը ցույց է տալիս, թե որ հասցեն է վարձակալվել, և անվտանգության միավորումների ցանկը ցույց է տալիս, թե արդյոք կապը բարձրացած է սպասված ինքնությամբ։

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

Ուղիղ հարցումը ապացուցում է, որ լուծիչը պատասխանում է լողավազանի հասցեին այնպիսի հոսթից, որը կարող է հասնել դրան։ Այն չի ապացուցում, որ Mac-ը ընտրել է այդ սերվերը։ macOS-ում scutil --dns-ը թվարկում է լուծիչները յուրաքանչյուր սահմանափակված ծառայության համար և ավելի տեղեկատվական է, քան ամփոփիչ վահանակը, իսկ Windows-ում Get-DnsClientServerAddress-ը ցույց է տալիս, թե արդյոք թունելի ադապտերը ընդունել է ուղարկված արժեքը։

Եթե հաճախորդը ցույց է տալիս լողավազանի հասցեն, և հարցումները դեռ ժամանակավարտվում են, մեղավորը թունելի երթուղին է կամ ֆայրվոլի շղթան։ Այն հաճախորդը, որը ոչ մի լուծիչ չի հաղորդում, նշանակում է, որ կոնֆիգուրացիայի բեռը երբեք չի հասել, ուստի նայեք, թե ինչպես է այդ պլատֆորմը կիրառում ուղարկված կարգավորումները, այլ ոչ թե ցանցին։ Գրեք, թե այս երկու դեպքերից որն եք դիտել, նախքան որևէ այլ բան փոխելը։ Այս երկու ձախողումները աջակցության տոմսում նույնն են թվում և տանում են հակառակ վերանորոգումների։