ఇంటి VPN సర్వర్‌కు డైనమిక్ DNS అవసరమా?

నన్ను అడిగే ఇంటి VPN వైఫల్యాలలో చాలావరకు DNS వైఫల్యాలు కావు, అయినా ప్రజలు మొదట డైనమిక్ DNS సభ్యత్వాన్ని కొంటారు. ఏదైనా కాన్ఫిగర్ చేయడానికి ముందు, hostname నిజంగా విరిగిన భాగమా అని నిర్ణయించుకోండి. మీ ISP ఇచ్చిన చిరునామా కదిలినప్పుడు అప్డేటర్ రికార్డును తిరిగి రాస్తుంది; అది పోర్టును తెరవలేదు, క్యారియర్ NAT ను దాటలేదు, లేదా నడుస్తున్న WireGuard సెషన్ తన ముగింపు బిందువు మారిందని గమనించేలా చేయలేదు. డైనమిక్ DNS పూర్తి పరిష్కారమా లేదా దానిలో ఒక వరుస మాత్రమేనా అని మూడు షరతులు నిర్ణయిస్తాయి.

షరతు ఒకటి: మీ చిరునామా నిజంగా కదులుతుంది

నివాస చిరునామాలు సాధారణ కారణాల వల్ల కదులుతాయి: విద్యుత్ కోత తర్వాత మోడెమ్ తిరిగి సింక్ అవుతుంది, ISP పూల్‌ను తిరిగి సమతుల్యం చేస్తుంది, దీర్ఘ అంతరాయం తర్వాత కొత్త లీజ్ వస్తుంది. కొన్ని లైన్లలో అవి అరుదుగా కూడా కదులుతాయి, అదే చిరునామా సంవత్సరం నిలిచిపోవడాన్ని నేను చూశాను; వ్యాపార ప్రణాళికల్లో తరచుగా స్థిరమైనది ఉంటుంది. పన్నెండు నెలల్లో ఏమీ మారకపోతే, చేతితో సవరించే ఒక A రికార్డు జీవించి ఉంచాల్సిన ఒక డీమన్ తక్కువ.

ఊహించకుండా కొలవండి. రౌటర్ స్థితి పేజీలో WAN చిరునామా చదివి, బయటి ప్రపంచం చూసే దానితో పోల్చండి. దీన్ని LAN లోని యంత్రం నుండి నడపండి:

curl -fsS https://api.ipify.org; echo

రెండు విలువలు భిన్నంగా ఉంటే, మీ రౌటర్ ముందు ఏదో అనువదిస్తోంది, ఏ hostname అప్డేట్ దాన్ని సరిచేయదు. 100.64.0.0/10 లోపలి చిరునామా క్యారియర్-గ్రేడ్ NAT కోసం పంచుకున్న పరిధి, సరిగ్గా అప్డేట్ చేసిన పేరు కూడా బయటి నుండి సమయం మించిపోవడానికి సాధారణ కారణం అదే.

షరతు రెండు: క్లయింట్లు పేరును మళ్లీ వెతుకుతారు

చిన్న TTL ప్రజలు దాటవేసే భాగం. పునరావృత రిజాల్వర్లు రికార్డు TTL ను గౌరవిస్తాయి, కానీ క్లయింట్ స్టాక్‌లు విడిగా కాష్ చేస్తాయి, ఇప్పటికే నిలిచిన సొరంగం ఏదీ మళ్లీ పరిష్కరించదు. డీబగ్ చేస్తున్నప్పుడు రికార్డును 60-300 సెకన్లకు పెట్టండి; పాత సమాధానం ఇచ్చే విండోను అది తగ్గిస్తుంది, కనెక్ట్ అయిన సెషన్‌ను తరలించదు.

OpenVPN మళ్లీ కనెక్ట్ అయిన ప్రతిసారీ లైన్ remote vpn.example.net 1194 ను మళ్లీ పరిష్కరిస్తుంది, మరియు resolv-retry infinite శోధన విఫలమైనప్పుడు నిష్క్రమించకుండా మళ్లీ ప్రయత్నించేలా చేస్తుంది. సర్వర్‌లో float స్థాపించిన సెషన్ మూల చిరునామా మారిన సహచరుడిని అనుసరించడానికి అనుమతిస్తుంది. WireGuard మరింత నేరుగా ఉంటుంది: wg-quick up కాన్ఫిగరేషన్ వర్తించినప్పుడు Endpoint ను పరిష్కరిస్తుంది, క్లయింట్ సొరంగాన్ని తిరిగి నిర్మించినప్పుడు దాన్ని మళ్లీ పరిష్కరిస్తుంది, కాబట్టి పాత చిరునామాపై ఇంకా విజయవంతమయ్యే హ్యాండ్‌షేక్ ఆగే వరకు విజయవంతమవుతూనే ఉంటుంది.

ఈ భేదం ప్రణాళికను రూపొందిస్తుంది. క్లయింట్లు డిమాండ్‌పై కనెక్ట్ అయితే, చిరునామా మార్పుకు ఒక తిరిగి కనెక్షన్ ఖర్చు. రోజుల తరబడి సెషన్ తెరిచి ఉంచితే, తదుపరి హ్యాండ్‌షేక్‌లో సొరంగం చనిపోతుందని ఆశించండి, అది నిలిచి ఉంటుందని ఊహించకుండా క్లయింట్‌ను మళ్లీ ప్రయత్నించనివ్వండి.

షరతు మూడు: లోపలికి వచ్చే మార్గం ఇంకా తెరిచి ఉంది

డైనమిక్ DNS పేరు ఎక్కడికి సూచిస్తుందో మాత్రమే మారుస్తుంది, మరేదీ కాదు. రౌటర్‌పై పోర్ట్ ఫార్వార్డింగ్, VPN హోస్ట్‌పై ఫైర్‌వాల్ నియమం, ISP లోని ఇన్‌బౌండ్ ప్యాకెట్లకు అనుమతి — అన్నీ రికార్డు ముఖ్యమయ్యే ముందు ఉండాలి. ఫార్వార్డింగ్ ఏది లక్ష్యంగా చేసుకుందో చూడండి: అది ఇంటర్‌ఫేస్‌కు బదులు WAN చిరునామాకు పిన్ అయి ఉంటే, చిరునామా మార్పు ఫార్వార్డింగ్‌ను నిశ్శబ్దంగా విరుస్తుంది, నింద రికార్డుపై పడుతుంది.

బయటి నుండి పరీక్షించండి. Wi-Fi ఆఫ్ చేసిన సెల్యులార్ డేటాలోని ఫోన్ అత్యంత చవకైన నిజాయితీ పరీక్ష; అదే LAN లోని ల్యాప్‌టాప్ కాదు. పేరు మీ పబ్లిక్ చిరునామాకు పరిష్కరించబడి రౌటర్‌లో NAT లూప్‌బ్యాక్ లేకపోతే, లోపలి పరీక్ష విఫలమవుతుంది, రికార్డు పూర్తిగా సరైనదే, ఇదే చాలామందిని ఎప్పుడూ తప్పు కాని రికార్డును సవరించడానికి పంపుతుంది.

మూడూ నెరవేరినప్పుడు ఏమి నడపాలి

చిన్న హోస్ట్‌కు ddclient అత్యంత తక్కువ ఆశ్చర్యపరిచే అప్డేటర్. కనిష్ఠ కాన్ఫిగరేషన్ ప్రదాత చూసే చిరునామాను ప్రచురిస్తుంది, ఇది రెట్టింపు NAT పొరపాటును నివారిస్తుంది:

protocol=dyndns2
use=web, web=https://api.ipify.org
server=updates.your-dns-provider.net
login=vpn-home
password=update-token
vpn.example.net

దీన్ని shell లూప్‌కు బదులు ప్రతి కొన్ని నిమిషాలకు systemd టైమర్ నుండి నడపండి, విజయాన్ని ఊహించకుండా ప్రదాత ప్రతిస్పందనను లాగ్ చేయండి. ఆధారాలను తాళంచెవిలా చూడండి, ఎందుకంటే ప్రతి క్లయింట్ ఎక్కడికి పంపబడుతుందో అదే నిర్ణయిస్తుంది: ఖాతా పాస్‌వర్డ్‌కు బదులు పరిమిత అప్డేట్ టోకెన్ ఉపయోగించండి, ఫైల్‌ను 0600 మోడ్‌లో ఉంచండి, అప్డేట్‌లను HTTPS పై పంపండి.

నిబద్ధతకు ముందు ధృవీకరించండి

ఒక శోధన మిగిలిన ప్రపంచం ఏమి చూస్తుందో చెబుతుంది, మార్పు తర్వాత వేచి ఉండాల్సిన TTL ను ముద్రిస్తుంది:

dig +noall +answer vpn.example.net @1.1.1.1

ఆ చిరునామాను రౌటర్ WAN చిరునామాతో పోల్చండి. సరిపోతే, పేరు తన పని చేస్తోంది, ఇంకా విఫలమయ్యేది ఇన్‌బౌండ్ చేరువు, తాళంచెవి లేదా మళ్లీ పరిష్కరించని క్లయింట్. భిన్నమైతే, అప్డేటర్ తప్పు ఇంటర్‌ఫేస్‌ను ప్రచురిస్తోంది, తరచుగా అది రౌటర్‌పై కాక రౌటర్ వెనుక ఉన్న VPN హోస్ట్‌పై నడిచినందున.

ఒక నిమిషపు రోల్‌బ్యాక్ ఉంచుకోండి: చివరిగా పనిచేసిన చిరునామా, మునుపటి TTL ను గుర్తించండి, ప్రదాతకు చెడ్డ మధ్యాహ్నం ఉన్నప్పుడు రెండింటినీ చేతితో ప్రచురించవచ్చు.

సమాధానం లేదు అయినప్పుడు

షరతు ఒకటి లేదా మూడు విఫలమైతే, కాన్ఫిగరేషన్ కాదు, నిర్ణయం మారుతుంది. క్యారియర్ NAT వెనుక మీ ఆచరణాత్మక ఎంపికలు ISP నుండి పబ్లిక్ చిరునామా అడగడం, ప్రవేశ బిందువును స్థిర చిరునామా ఉన్న చిన్న VPS కు తరలించడం, లేదా తన సమావేశాన్ని ఉంచుకునే పొరను ఉపయోగించడం. చిరునామా స్థిరమైతే, అప్డేటర్‌ను దాటవేయండి: ఒక A రికార్డు, IPv6 నడిపితే ఒక AAAA రికార్డు, అదే పోర్ట్ ఫార్వార్డింగ్.

క్లయింట్లు కనెక్ట్ అయి ఉండగా చిరునామా మారితే, నిజాయితీ సవరణ క్లయింట్‌లోనే ఉంటుంది: తిరిగి కనెక్షన్ తర్కం, మళ్లీ ప్రయత్నించే విరామం, వేగవంతమైన అప్డేటర్ కాదు. రెండో ప్రదాతను జోడించడం విరామాన్ని దాచుతుంది మాత్రమే.

ముందుకు వెళ్లే ముందు నాలుగు విషయాలను క్రమంగా నిర్ధారించండి:

• అప్డేటర్ ప్రచురించే చిరునామా రౌటర్ WAN చిరునామాతో సరిపోతుంది.
• రికార్డు TTL మార్పు కొన్ని నిమిషాల్లో కనిపించేంత చిన్నది.
• పోర్ట్ ఫార్వార్డింగ్ స్థిర చిరునామాకు కాదు, ఇంటర్‌ఫేస్‌కు కట్టుబడి ఉంది.
• చివరి మార్పు తర్వాత ఒక నిజమైన క్లయింట్ తిరిగి కనెక్ట్ అయి ట్రాఫిక్ పంపింది.

నాలుగూ సరిపోతే, సెటప్‌ను అలాగే ఉంచండి; మీ తదుపరి వైఫల్యం నామకరణ సమస్య కాదు, తాళంచెవి లేదా ఫైర్‌వాల్ నియమం. ఏదైనా విఫలమైతే, మరో కదిలే భాగాన్ని జోడించే ముందు ఆ వరుసను సరిచేయండి. RFC 2136 అప్డేట్ యంత్రాంగాన్ని వివరిస్తుంది, డీమన్ తీగపై ఏమి పెడుతుందో చూడాలంటే.