Mac చేరుకోలేని DNS చిరునామాను StrongSwan పంపుతుంది

ఎవరైనా 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ను జోడిస్తే రిజాల్వర్ బైండ్ అయ్యి సమాధానం ఇవ్వడానికి సరిపోతుంది, ఎందుకంటే క్లయింట్లు ఇప్పటికే ఉన్న పూల్ మార్గం ద్వారా దాన్ని చేరుకుంటాయి. ఏ క్లయింటూ ప్రమాదవశాత్తు దాన్ని తీసుకోకుండా చిరునామాను లీజు పరిధికి బయట ఉంచండి. పూల్ను బాహ్య 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 టన్నెల్ అడాప్టర్ పంపిన విలువను అంగీకరించిందా అని చూపుతుంది.

క్లయింట్ పూల్ చిరునామాను చూపించి ప్రశ్నలు ఇంకా సమయం ముగిస్తే, టన్నెల్ మార్గం లేదా ఫైర్వాల్ చైన్ తప్పు. ఏ రిజాల్వర్నూ నివేదించని క్లయింట్ అంటే కాన్ఫిగరేషన్ పేలోడ్ ఎప్పటికీ చేరలేదు, కాబట్టి నెట్వర్క్ కాదు, ఆ ప్లాట్ఫారమ్ పంపిన సెట్టింగ్లను ఎలా వర్తింపజేస్తుందో చూడండి. మరేదైనా మార్చే ముందు మీరు గమనించిన రెండింటిలో ఏదో రాయండి. ఆ రెండు వైఫల్యాలు సపోర్టు టికెట్లో ఒకేలా కనిపించి వ్యతిరేక మరమ్మతులకు దారి తీస్తాయి.