Pi గేట్వే హోస్ట్నేమ్ స్టాటిక్ మార్గాలను స్వయంగా అప్డేట్ చేస్తుందా?

స్టాటిక్ మార్గాన్ని గేట్వే పేరు వైపు చూపించడం చిరునామా మారినా అది నిలిచిపోతుందని అనిపిస్తుంది, కానీ నిలవదు. పేరు DNS లో నివసిస్తుంది, మార్గం క్లయింట్ రూటింగ్ పట్టికలో సంఖ్యాత్మక తదుపరి హాప్గా కూర్చుంటుంది. Pi వేరే చిరునామాకు వెళ్ళినప్పుడు, పాత హాప్ను ఇప్పటికే ఇన్స్టాల్ చేసిన ప్రతి వినియోగదారు అదే నంబరుకే ట్రాఫిక్ పంపుతూనే ఉంటాడు. ఏ రిజాల్వర్ ఫార్వార్డింగ్ పట్టికకు అనుసంధానించబడలేదు, కాబట్టి మీ కోసం ఆ ఎంట్రీని తిరిగి రాసేది ఏదీ లేదు.

DNS సమాధానం మరియు మార్గం వేర్వేరు వస్తువులు

మీ Pi vpn-gw.lan కు సమాధానం ఇస్తుంది మరియు 10.44.0.0/16 ను ఒక సొరంగానికి పంపుతుంది అనుకుందాం. 192.168.30.0/24 లోని క్లయింట్లు స్టాటిక్ మార్గం ద్వారా చేరుకుంటాయి. Pi చిరునామా 192.168.30.4 నుండి 192.168.30.11 కి మారినప్పుడు, రికార్డు దాని TTL లోపు అనుసరించింది, మార్గాలు అనుసరించలేదు.

రెండు దృశ్యాలు తప్పించుకోవడం సులభమైన విధంగా విభేదిస్తాయి, ఎందుకంటే విడివిడిగా అడిగినప్పుడు రెండూ నమ్మదగినవిగా కనిపిస్తాయి:

$ ip route get 10.44.0.1
10.44.0.1 via 192.168.30.4 dev eth0 src 192.168.30.20
$ dig +short vpn-gw.lan
192.168.30.11

ప్యాకెట్లు ఎక్కడికి వెళ్తాయో మొదటి పంక్తి మాత్రమే నిర్ణయిస్తుంది. రెండవ పంక్తి కర్నెల్ ఎప్పుడూ అడగని ప్రశ్నకు సమాధానం ఇస్తుంది. అనేక A రికార్డులు ఉన్న రికార్డు కూడా వైఫల్య సమయంలో మారే విధానం కాదు, ఎందుకంటే ప్రతి చిరునామా ఆ విభాగంలో పనిచేయగల తదుపరి హాప్ అయి ఉండాలి.

ఆదేశం ముగిసిన తర్వాత పట్టికలో ఏమి మిగులుతుంది

Linux మార్గం ఇక్కడ ముఖ్యమైన రెండు విషయాలను నమోదు చేస్తుంది: ప్రోటోకాల్ చిరునామాగా తదుపరి హాప్, మరియు సూచిక సంఖ్యగా నిష్క్రమణ ఇంటర్ఫేస్. rtnetlink మార్గ లక్షణాలు ఆ మొదటి ఫీల్డ్ను RTA_GATEWAY అని పిలుస్తాయి, అందులో బైట్లు ఉంటాయి. ఎంట్రీ స్థానంలో చేరిన తర్వాత దానికి ఏ TTL జోడించబడదు మరియు ఏ నేపథ్య శోధన దాన్ని రిఫ్రెష్ చేయదు.

అందుకే ip route add 10.44.0.0/16 via vpn-gw.lan పని చేస్తున్నట్టు కనిపిస్తుంది. సాధనం ఆదేశం నడుస్తున్నప్పుడు పేరును పరిష్కరిస్తుంది, వచ్చిన చిరునామాను రాస్తుంది, పేరును పూర్తిగా మరచిపోతుంది. తర్వాత ip route show 10.44.0.0/16 ను అమలు చేయండి, అక్షరార్థ చిరునామా తిరిగి వస్తుంది.

సొరంగాన్ని నిందించే ముందు ఈ ప్రవర్తనను తెలుసుకోవడం విలువైనది.

మీ కోసం పేరును పరిష్కరించే సాధనాలు, మరియు ఎప్పుడు

కొన్ని రౌటర్లు మరియు ఫైర్వాల్లు మార్గం లేదా గేట్వే ఫీల్డ్లో హోస్ట్నేమ్లను నిజంగా అంగీకరిస్తాయి. ముఖ్యమైనది పరిష్కారం ఎప్పుడు జరుగుతుంది అనేది. పరికరం కాన్ఫిగరేషన్ వర్తించేటప్పుడు మాత్రమే పేరును పరిష్కరిస్తే, నిల్వ చేసిన ఎంట్రీ టైప్ చేసిన చిరునామా అంతే స్థిరంగా ఉంటుంది, తర్వాతి చిరునామా మార్పుకు మరోసారి వర్తించాలి. ఫీల్డ్ పేరును అంగీకరించడం రిఫ్రెష్ గురించి ఏమీ చెప్పదు.

నిర్వహించిన అమరికలు పనిని విభజిస్తాయి. DHCP రిజర్వేషన్ లేదా స్టాటిక్ లీజ్ Pi ను ఒకే చిరునామాలో ఉంచుతుంది, DNS రికార్డు లీజ్ను అనుసరిస్తుంది. కదిలే లక్ష్యాన్ని ట్రాక్ చేయాల్సిన అవసరం లేదు, ఎందుకంటే లక్ష్యం కదలదు.

పర్యవేక్షించబడే అప్డేటర్ మరో చట్టబద్ధమైన నమూనా, దానికి యజమాని కావాలి.

చిరునామాను పిన్ చేయండి లేదా అప్డేటర్ను మీరే అమలు చేయండి

చిన్న LAN కోసం, DHCP సర్వర్లో రిజర్వేషన్ చవకైన పరిష్కారం. డైనమిక్ పూల్ వెలుపల చిరునామాను ఎంచుకోండి, దాన్ని Pi MAC చిరునామాకు కట్టండి, తదుపరి లీజ్ పునరుద్ధరణ తర్వాత ip -4 addr show dev eth0 తో నిర్ధారించండి. తర్వాత క్లయింట్ల తదుపరి హాప్ను ఒకసారి ఆ చిరునామా వైపు తిప్పండి. ఇప్పుడు మీకు స్థిరమైన గేట్వే మరియు దానిని వివరించే రికార్డు ఉన్నాయి, ఈ సంబంధం నిజంగా పనిచేసే క్రమం అదే.

Pi నిజంగా కదలాల్సి వస్తే, ప్రతి క్లయింట్ను చేతితో సవరించడం బదులు మార్గ మరమ్మతును ఒకే చోట ఉంచండి. పరిష్కరించే, పోల్చే మరియు భర్తీ చేసే చిన్న స్క్రిప్ట్ ఆ దశను పునరావృతం చేయగలిగేలా చేయడానికి సరిపోతుంది:

new=$(dig +short vpn-gw.lan | head -n1)
cur=$(ip route get 10.44.0.1 | awk '{print $3}')
if [ "$new" != "$cur" ]; then
  ip route replace 10.44.0.0/16 via "$new"
fi
ip route get 10.44.0.1

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

తిరిగి వచ్చే మార్గాన్ని కూడా తనిఖీ చేయండి. Pi క్లయింట్ సబ్నెట్ను ఎలా చేరుకోవాలో తెలుసుకోవాలి, దాని ఫైర్వాల్ సొరంగ ట్రాఫిక్ను అనుమతించాలి. అసమతౌల్యాన్ని కప్పడానికి జోడించిన డిఫాల్ట్ మార్గం సాధారణంగా నిజమైన ఖాళీని దాచి ఒక వారం తర్వాత వేరేదాన్ని పాడు చేస్తుంది.