గేట్వేపై OpenVPN DNS: dnsmasq మరియు ఫైర్వాల్ పరిధి

టన్నెల్ చిరునామాపై dnsmasq నడపండి, క్లయింట్ పూల్ నుండి మాత్రమే DNS అనుమతించండి, రిజాల్వర్ పుష్ చేయండి, ఆపై నేరుగా ప్రశ్నలు మరియు యాప్ స్వంత శోధనను పరీక్షించండి.

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

వినిపించేది రెండు దిశల స్థానిక సేవ

లోపలికి క్లయింట్ గేట్వే టన్నెల్ చిరునామాకు పోర్ట్ 53లో ప్రశ్న పంపుతుంది. బయటకు డీమన్ ఆ ప్రశ్నను తన కాన్ఫిగర్ చేసిన అప్స్ట్రీమ్కు పంపుతుంది. రెండు భాగాలు పని చేయాలి, అవి వేర్వేరు విధాలుగా విఫలమవుతాయి.

క్లయింట్ నివేదించే టైమ్అవుట్ మరియు గేట్వేపై కనిపించే టైమ్అవుట్ ఒకటే లోపం కాదు.

టన్నెల్ చిరునామాను బంధించండి, ప్రతి చిరునామాన్ని కాదు

ఈ పని కోసం ప్రత్యేక dnsmasq ఇన్స్టాన్స్కు స్పష్టమైన వినికిడి చిరునామా, ప్రారంభం తర్వాత టన్నెల్ కనిపించడాన్ని సహించే బైండ్ మోడ్, మరియు ఒక స్పష్టమైన అప్స్ట్రీమ్ అవసరం. ఇది నేను ఉపయోగించే చిన్న సంస్కరణ:

listen-address=127.0.0.1,10.90.0.1
bind-dynamic
no-resolv
no-hosts
server=192.168.50.53

bind-dynamic వ్యక్తిగత చిరునామాలను బంధిస్తుంది మరియు tun0 తర్వాత కనిపించినప్పుడు నిర్వహిస్తుంది, VPN సేవ పునఃప్రారంభమయ్యే హోస్ట్లో ఇది ముఖ్యం. loopback జాబితా చేయడం పబ్లిక్ వినిపించేది జోడించకుండా స్థానిక సాధనాలను నడుపుతుంది. no-resolv డీమన్ హోస్ట్ రిజాల్వర్ కాన్ఫిగరేషన్ నుండి అప్స్ట్రీమ్లను వారసత్వంగా పొందకుండా నిరోధిస్తుంది, మరియు no-hosts ఈ ఇన్స్టాన్స్ గేట్వే hosts ఫైల్ను ప్రచురించకుండా నిరోధిస్తుంది. ఈ ఎంపికల్లో ఏదీ ఎవరికీ సేవను ప్రశ్నించే అనుమతి ఇవ్వదు.

రెండవ డీమన్ ప్రారంభించే ముందు పోర్ట్ 53లో ఇప్పటికే ఉన్న వినిపించేది ఉందో లేదో తనిఖీ చేయండి, మరియు తప్పు డైరెక్టరీలో ఉన్న తప్పిపోయిన ఫైల్కు బదులుగా పంపిణీ కాన్ఫిగరేషన్ యజమానిని ఉపయోగించండి.

DNS ఇన్పుట్ను అనుమతించండి, టన్నెల్ ట్రాన్సిట్ను కాదు

దీన్ని పని చేయించే ఫైర్వాల్ నియమాలు టన్నెల్ ఇంటర్ఫేస్, క్లయింట్ పూల్, గేట్వే చిరునామా మరియు పోర్ట్ 53కి పరిమితమైన స్థానిక-ఇన్పుట్ నియమాలు. ప్రతి ప్రోటోకాల్కు ఒకటి, రెండు నియమాలు సరిపోతాయి:

sudo ufw allow in on tun0 proto udp from 10.90.0.0/24 to 10.90.0.1 port 53
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 53

DNS UDPతో పాటు TCP ద్వారా కూడా నడుస్తుంది, కాబట్టి UDP మాత్రమే నియమం పెద్ద సమాధానాలను అడపాదడపా అనిపించే విధంగా విఫలం కావడానికి వదిలిస్తుంది. ఇవి ufw route అనుమతులు కావు, మరియు అవి tun0 పై విస్తృత అనుమతి కాకూడదు. క్రమం కంటెంట్తో సమానంగా ముఖ్యం: tun0 నుండి అన్ని ఇన్పుట్ను పడవేసే మునుపటి నియమం ఇప్పటికీ గెలుస్తుంది, మరియు చివరి డ్రాప్ క్రింద అనుమతి జోడించడం ఏమీ సృష్టించదు.

గేట్వే DNS ఇప్పుడు డిజైన్లో భాగమైతే, ఆ మునుపటి విధానాన్ని ఉద్దేశపూర్వకంగా సమీక్షించి ఎందుకో నమోదు చేయండి.

అప్స్ట్రీమ్ సగం వేరే మార్గం

ప్రశ్నలు గేట్వే నుండి దాని స్వంత చిరునామా నుండి అప్స్ట్రీమ్ రిజాల్వర్ వైపు బయలుదేరుతాయి, కాబట్టి గేట్వే మార్గం మరియు ఆ రిజాల్వర్ వైపు అవుట్పుట్ విధానం ఈ మార్పిడిని అనుమతించాలి. ఇది క్లయింట్లను వినిపించేది వరకు చేర్చే నియమం కంటే భిన్నమైనది, మరియు వేరే లక్షణంతో విఫలమవుతుంది.

సమాధానాలు పని చేయడానికి అపరిమిత టన్నెల్ అవుట్పుట్ జోడించవద్దు; ట్రాక్ చేసిన సమాధానాలకు అది అవసరం లేదు.

ఎంపికను పుష్ చేయండి, ఆపై అప్పగింతను తనిఖీ చేయండి

సర్వర్ పుష్ చేసిన ఎంపికతో రిజాల్వర్ను క్లయింట్లకు ప్రకటించగలదు. అది ఎంపిక, ఆపరేటింగ్ సిస్టమ్ తప్పనిసరిగా పాటించాల్సిన ఆదేశం కాదు:

push "dhcp-option DNS 10.90.0.1"

కమాండ్ లైన్ Linux క్లయింట్కు దాని కనెక్షన్ మేనేజర్ రిజాల్వర్ ఇంటిగ్రేషన్ అవసరం కావచ్చు, నిర్వహించే పరికరానికి నవీకరించిన నిర్వహణ ప్రొఫైల్ అవసరం కావచ్చు. కనెక్ట్ అయిన తర్వాత క్లయింట్లో సక్రియ రిజాల్వర్ను నిర్ధారించండి, పుష్ వర్తించిందని ఊహించడం బదులు. రెండు యంత్రాంగాలు ఒకేసారి DNS సెట్ చేయడానికి ప్రయత్నించినప్పుడు, మెరిసే పరిష్కారంగా కనిపించే పోటీ ఏర్పడుతుంది.

క్లయింట్ రిజాల్వర్ కాన్ఫిగరేషన్కు ఒకే యజమాని ఉండటం లక్ష్యం, మరియు పుష్ సాధారణంగా ఆ యజమాని అయ్యేది క్లయింట్ ప్లాట్ఫారమ్ అంగీకరించినప్పుడు మాత్రమే.

మీరు నిజంగా నిర్మించినదాన్ని పరీక్షించండి

ఒక ప్రైవేట్ పూర్తి అర్హత కలిగిన పేరు మరియు ఒక అనుమతించిన బాహ్య పేరును నేరుగా టన్నెల్ చిరునామాపై, UDP మరియు TCP రెండింటిలో ప్రశ్నించండి. తర్వాత యాప్ సాధారణ శోధన మార్గం ద్వారా పునరావృతం చేయండి.

నేరుగా ప్రశ్నలు పని చేసి యాప్ ఇంకా విఫలమైతే, లోపం సర్వర్పై కాదు, అప్పగింతలో ఉంది:

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

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

సంబంధిత వ్యాసాలు