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 કન્ફિગરેશનમાં એ જ બે હકીકતો ipsec.conf સિન્ટેક્સને બદલે પૂલ વ્યાખ્યા અને કનેક્શન પર DNS સેટિંગ તરીકે દેખાય છે.

સર્વરને આ માટે નવું ભૌતિક ઇન્ટરફેસ જોઈતું નથી. લૂપબેક ઇન્ટરફેસમાં 10.180.7.1 ઉમેરવું પૂરતું છે જેથી રિઝોલ્વર બાઈન્ડ થઈને જવાબ આપી શકે, કારણ કે ક્લાયન્ટ્સ પહેલેથી હાજર પૂલ રૂટ દ્વારા તેને પહોંચે છે. સરનામું ભાડા શ્રેણીની બહાર રાખો જેથી કોઈ ક્લાયન્ટ ભૂલથી તેને દાવો ન કરે. જો પૂલ બાહ્ય 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 બતાવે છે કે ટનલ એડેપ્ટરે પુશ કરેલ મૂલ્ય સ્વીકાર્યું કે નહીં.

જો ક્લાયન્ટ પૂલ સરનામું બતાવે અને ક્વેરી હજી ટાઈમઆઉટ થાય, તો દોષ ટનલ રૂટ અથવા ફાયરવોલ ચેઇનનો છે. જે ક્લાયન્ટ કોઈ રિઝોલ્વરની જાણ કરતું નથી તેનો અર્થ છે કે કન્ફિગરેશન પેલોડ કદી પહોંચ્યું જ નહીં, તેથી નેટવર્કને બદલે તે પ્લેટફોર્મ પુશ કરેલ સેટિંગ્સ કેવી રીતે લાગુ કરે છે તે જુઓ. બીજું કંઈપણ બદલતા પહેલાં તમે આ બેમાંથી કયો કેસ જોયો તે લખો. આ બંને નિષ્ફળતાઓ સપોર્ટ ટિકિટમાં એકસરખી દેખાય છે અને વિરોધી સમારકામ તરફ દોરે છે.