WireGuard DNS DNAT: ప్రతిస్పందన మార్గాన్ని పని చేస్తూ ఉంచండి

WireGuard క్లయింట్ యొక్క DNS ప్రశ్నను మరో రిజాల్వర్కు మళ్లించడం ఒక నియమంలా కనిపిస్తుంది కానీ మూడు నిర్ణయాల్లా ప్రవర్తిస్తుంది. గమ్యాన్ని తిరిగి రాయాలి, ప్యాకెట్ను పంపాలి, మరియు సమాధానం గేట్వే సృష్టించిన అనువాద స్థితి గుండా తిరిగి వచ్చే దారిని కనుగొనాలి. మూడవదాన్ని దాటవేస్తే ప్రశ్న శుభ్రంగా బయటకు వెళ్తుంది, కానీ క్లయింట్ ఎప్పటికీ వేచి ఉంటుంది.

10.77.0.0/24 లోని అధికృత క్లయింట్లు wg0 ద్వారా వచ్చి, ప్రకటించిన చిరునామా 10.77.0.1 ను అడిగి, 203.0.113.53 లో రిజాల్వర్ అవసరమయ్యే ఉదాహరణ తీసుకోండి. అప్స్ట్రీమ్ చిరునామా డాక్యుమెంటేషన్ కోసం ప్లేస్హోల్డర్, పనిచేస్తున్న సేవ కాదు.

ప్రశ్నను మళ్లించడం దాని గమ్యాన్ని మాత్రమే మారుస్తుంది

PREROUTING లోని గమ్య-NAT నియమం రూటింగ్ నిర్ణయం తీసుకోక ముందే చిరునామాను తిరిగి రాస్తుంది, కాబట్టి ప్యాకెట్ తర్వాత పాత గమ్యానికి బదులు కొత్త గమ్యం వైపు రూట్ చేయబడుతుంది. క్లయింట్ యొక్క మూల చిరునామా ఆ చర్యతో తాకబడదు. అందుకే పూర్తిగా కనిపించే నియమం కూడా నిశ్శబ్దాన్ని సృష్టించగలదు: అభ్యర్థన ఇప్పుడు క్లయింట్ యొక్క ప్రైవేట్ పరిధి గురించి ఎప్పుడూ వినని రిజాల్వర్ వైపు వెళ్తుంది. గేట్వే ఒక ఫీల్డ్ను అనువదించి రెండవ సమస్యను వారసత్వంగా పొందింది.

రెండు DNS రవాణాలకూ సరిపోలే నియమాలు అవసరం, ఎందుకంటే సమాధానం కత్తిరించబడినప్పుడు క్లయింట్ TCP కు తిరిగి వెళ్తుంది.

క్రింది నియమాలు ఒక ఇన్కమింగ్ ఇంటర్ఫేస్, ఒక క్లయింట్ పరిధి మరియు ఒక అసలు గమ్య చిరునామాన్ని ఎంచుకుంటాయి. గేట్వేపై మరేదీ ప్రభావితం కాదు, గేట్వే యొక్క స్వంత ప్రశ్న అసలు సరిపోలదు.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i wg0 -s 10.77.0.0/24 -d 10.77.0.1 -p udp --dport 53 -j DNAT --to-destination 203.0.113.53:53
iptables -t nat -A PREROUTING -i wg0 -s 10.77.0.0/24 -d 10.77.0.1 -p tcp --dport 53 -j DNAT --to-destination 203.0.113.53:53

ప్రతిస్పందన మార్గం వేరే నిర్ణయం

రెండు ఏర్పాట్లు సమాధానం తిరిగి రావడానికి అనుమతిస్తాయి, ఒకదాన్ని ముందే ఎంచుకోవడం ఒక డీబగ్గింగ్ సెషన్ను ఆదా చేస్తుంది. గాని అప్స్ట్రీమ్ రిజాల్వర్కు ఈ గేట్వే ద్వారా 10.77.0.0/24 కు తిరిగి వెళ్లే మార్గం ఉంది, లేదా గేట్వే నిష్క్రమణలో మూలాన్ని అనువదిస్తుంది, తద్వారా సమాధానం అప్స్ట్రీమ్కు ఇప్పటికే తెలిసిన చిరునామాకు చేరుతుంది. రెండూ పనిచేస్తాయి; అప్స్ట్రీమ్పై మీ నియంత్రణకు ఒకటి మాత్రమే సరిపోతుంది.

రూటింగ్ మొదటి ప్రయత్నానికి అర్హం, ఎందుకంటే అది క్లయింట్ చిరునామాను రిజాల్వర్కు కనిపించేలా ఉంచి రెండవ అనువాద పొరను నివారిస్తుంది. అప్స్ట్రీమ్ మీ నియంత్రణకు వెలుపల ఉన్నప్పుడు, నిర్దిష్ట నిష్క్రమణ ఇంటర్ఫేస్లో మూల అనువాదమే ఆచరణాత్మక ఎంపిక.

ఆ అనువాదాన్ని మళ్లింపు అంత బిగుతుగా పరిమితం చేయండి, లేకపోతే నియమం దానితో యాదృచ్ఛికంగా సరిపోలే ఏదైనా ఒక సాధారణ ప్రయోజన NAT అవుతుంది:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -d 203.0.113.53 -o eth0 -p udp --dport 53 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -d 203.0.113.53 -o eth0 -p tcp --dport 53 -j MASQUERADE

కనెక్షన్ ట్రాకింగ్ మ్యాపింగ్ను జతగా ఉంచుతుంది, కాబట్టి తిరిగి వచ్చేటప్పుడు సమాధానం క్లయింట్ యొక్క అసలు ట్యూపుల్కు తిరిగి రాయబడుతుంది. నిష్క్రమణ నియమం లేకుంటే, రిజాల్వర్ తన సమాధానాన్ని చేరుకోలేని ప్రైవేట్ చిరునామాకు పంపుతుంది, క్లయింట్ లోపానికి బదులు సమయం ముగింపును చూస్తుంది.

పని కనిపించిన దాని కంటే ఇరుకుగా నియమాలు రాయండి

ఫార్వార్డింగ్ అనుమతి అదే పరిధిలో ఉంటుంది. మెషీన్లోని ప్రతి DNAT కనెక్షన్ను అంగీకరించడానికి బదులు క్లయింట్ నుండి రిజాల్వర్కు ప్రవాహాన్ని మరియు conntrack ఇప్పటికే గుర్తించే తిరిగి వచ్చే ట్రాఫిక్ను అనుమతించండి. సర్వవ్యాప్త అనుమతి DNS తో ఎటువంటి సంబంధం లేని పోర్ట్ ఫార్వార్డింగ్లకు కూడా అధికారం ఇస్తుంది.

గేట్వే యొక్క స్వంత రిజాల్వర్ వేరే కోడ్ మార్గం. స్థానికంగా జారీ చేసిన ప్రశ్న OUTPUT గుండా వెళ్తుంది, కాబట్టి గేట్వే షెల్ నుండి పరీక్షించడం PREROUTING నియమాన్ని గాని ఫార్వార్డింగ్ విధానాన్ని గాని సాధన చేయదు. అందుకే స్థానిక పరీక్ష ఉత్తీర్ణమైనప్పుడు ప్రతి క్లయింట్ విఫలమవుతుంది, దీనికి వ్యతిరేకమూ అంతే సాధారణం.

ఇక్కడ ఏదీ పోర్ట్ 443 లో HTTPS పై DNS ను గాని పోర్ట్ 853 లో TLS పై DNS ను గాని కవర్ చేయదు, IPv6 ను కూడా కవర్ చేయదు. IPv6 రిజాల్వర్ కాన్ఫిగర్ చేసిన క్లయింట్ మొత్తం ఏర్పాటును సంతోషంగా పట్టించుకోదు.

కొత్త ప్రశ్న ఏమి నిరూపిస్తుంది

కనెక్షన్ ట్రాకింగ్ గత మ్యాపింగ్లను గుర్తుంచుకుంటుంది, కాబట్టి నియమ మార్పుకు ముందు పంపిన ప్రశ్న పాత స్థితి నుండి సమాధానం పొంది కొత్త నియమాన్ని విరిగినట్లు కనిపించేలా చేయవచ్చు. కొత్త మూల పోర్ట్తో ప్రారంభించండి, క్లయింట్ సమాధానాలను కాష్ చేసే చోట కొత్త పేరుతో ప్రారంభించండి.

dig @10.77.0.1 example.com A +short
conntrack -L -p udp --dport 53 | head

మొదటి ఆదేశం క్లయింట్ మార్గం అసలు పరిష్కరమవుతుందో లేదో చూపిస్తుంది, రెండవది గేట్వే నిజంగా ఇన్స్టాల్ చేసిన అనువాదాన్ని ట్యూపుల్ యొక్క రెండు దిశలతో సహా చూపిస్తుంది. సరైన రిజాల్వర్కు చూపుతూ కూడా సమాధాన కౌంటర్ సున్నా వద్ద చిక్కుకున్న మ్యాపింగ్ ఫిల్టర్ సమస్య కాదు, తిరిగి వచ్చే మార్గ సమస్య.

ఏదైనా మళ్లించే ముందు మీరు ఆశించే పేర్లను రిజాల్వర్కు తెలుసని నిర్ధారించుకోండి. ప్రజా పేర్లకు సమాధానం ఇచ్చే కానీ మీ ప్రైవేట్ జోన్కు ఇవ్వని ప్రత్యామ్నాయం పనిచేసే శోధనను విరిగిన సొరంగంలా కనిపించే NXDOMAIN గా మారుస్తుంది. క్లయింట్ మార్గం పాల్గొనక ముందే గేట్వే నుండి నేరుగా రిజాల్వర్ను పరీక్షించండి. మరియు iptables పొడిగింపుల సూచన ఈ నియమాలు ఆధారపడే DNAT మరియు masquerade అర్థశాస్త్రాన్ని డాక్యుమెంట్ చేస్తుంది.