ISP మార్చండి, సైట్ VPN చిరునామాలను మళ్లీ నంబర్ చేయకుండా

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

స్వతంత్రంగా కదిలే రెండు చిరునామా ప్రణాళికలు

లోపలి ప్రణాళిక అప్లికేషన్లు ఉపయోగించే ప్రైవేట్ చిరునామాలను వివరిస్తుంది: 10.55.8.20 వద్ద శాఖ సర్వర్, అక్కడికి రూట్ చేసే ప్రధాన కార్యాలయ ప్రిఫిక్స్, మరియు తిరిగి వచ్చే మార్గం. బయటి ప్రణాళిక రెండు గేట్‌వేలు ఒకదానికొకటి ఎలా చేరుకుంటాయో వివరిస్తుంది: పీర్ చిరునామాలు, వినే పోర్టులు మరియు ఇంటర్నెట్ ద్వారా మార్గం.

ప్రొవైడర్ మార్పు బయటి ప్రణాళికను తాకుతుంది. అది తనంతట తానే లోపలి ప్రణాళిక మారాలని కోరదు.

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

బయటి టన్నెల్ లోపలి సంభాషణను మోసుకెళ్తుంది

గేట్‌వే-నుండి-గేట్‌వే టన్నెల్‌లో బయటి IP శీర్షిక రెండు గేట్‌వేలకు చిరునామా ఇస్తుంది. లోపలి శీర్షిక ఇప్పటికీ అప్లికేషన్ యొక్క నిజమైన ముగింపు బిందువులను పేర్కొంటుంది. RFC 7296 యొక్క గేట్‌వే-నుండి-గేట్‌వే వివరణ దీనిని టన్నెల్ ముగింపు బిందువుల ద్వారా ట్రాఫిక్ అందించే సాధారణ రూటింగ్‌గా పరిగణిస్తుంది.

అందుకే గేట్‌వే యొక్క పబ్లిక్ చిరునామం మారుతున్నప్పుడు కూడా శాఖ సర్వర్ 10.55.8.20 ను నిలుపుకోగలదు. లోపలి ప్యాకెట్‌లో ప్రొవైడర్ చిరునామా అసలు ఉండదు.

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

ప్రొవైడర్ తరలింపుకు ఇంకా తనిఖీ జాబితా ఉంది

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

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

మరో అనుసంధానిత సైట్‌తో చిరునామా అతివ్యాప్తి వేరే ప్రణాళిక సమస్య. ప్రొవైడర్ మార్పు దాన్ని సృష్టించదు, కానీ తరలింపే సాధారణంగా అది బయటపడే సమయం.

నిలవనివి: పబ్లిక్ మూలం మరియు సెషన్లు

స్థిరమైన ప్రైవేట్ సర్వర్ చిరునామం స్థిరమైన పబ్లిక్ మూలం కాదు. బ్రౌజింగ్ నేరుగా కొత్త ప్రొవైడర్ ద్వారా బయటకు వెళితే, వెబ్‌సైట్లు ప్రొవైడర్ వైపు చూసే కొత్త చిరునామాన్ని చూస్తాయి.

ఆ చిరునామాన్ని స్థిరంగా ఉంచడానికి దాని స్వంత లభ్యత మరియు విధానంతో ఉద్దేశపూర్వక నిర్గమ డిజైన్ అవసరం. అది టన్నెల్‌తో ఉచితంగా రాదు.

స్థాపించిన సెషన్లు కూడా మార్గ మార్పును తట్టుకోవు. టన్నెల్ సెకన్లలో తిరిగి ఏర్పాటు కాగలదు మరియు పాత మార్గానికి బంధించిన దీర్ఘకాలిక కనెక్షన్లను తెంచగలదు. పునఃకనెక్షన్ ఆమోదయోగ్యమైన విండో కోసం మార్పిడిని ప్రణాళిక చేయండి. నిర్దిష్ట క్లయింట్లు మరియు వాటి సమయ పరిమితులు పరీక్షించకుండా తరలింపు కనిపించదు అని చెప్పవద్దు.

నాలుగు తనిఖీలతో తరలింపును ధృవీకరించండి

మార్పు తర్వాత నాలుగు విషయాలను వరుసగా ధృవీకరించండి: టన్నెల్ ఉద్దేశించిన పీర్‌తో ఏర్పాటైంది, శాఖ ప్రిఫిక్స్‌కు లోపలి మార్గం ఉంది, విధానం అప్లికేషన్ ప్రవాహాన్ని అనుమతిస్తుంది మరియు అప్లికేషన్ సమాధానం ఇస్తుంది. ప్రతిదానికి దాని స్వంత ఆదేశం ఉంది.

Linux గేట్‌వేలో, ఈ మూడూ ఆ జాబితా మధ్య భాగాన్ని కవర్ చేస్తాయి:

ip route get 10.55.8.20
ip xfrm policy list
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 http://10.55.8.20/health

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