இயந்திரம் ஒரு நிமிடம் முன்பு பதிலளித்தது, VPN இணைந்தது, இப்போது அதே முகவரி நேரம் முடிந்துவிடுகிறது. மூன்று கோளாறுகள் இந்த அறிகுறியை உருவாக்குகின்றன, அவை வெவ்வேறு இயந்திரங்களில் வாழ்கின்றன. ஹோஸ்ட் தனியார் நெட்வொர்க்கிற்கான பாதையை இழக்கலாம், விருந்தினரின் NAT வரம்பு சுரங்கப்பாதை இப்போது அறிவிக்கும் வரம்புடன் மோதலாம், அல்லது முழு சுரங்கப்பாதை ஹோஸ்ட்டின் ஒவ்வொரு பாதையின் உரிமையையும் எடுத்துக்கொள்ளலாம். எந்த கட்டமைப்பையும் மாற்றுவதற்கு முன் எது நடந்தது என்பதைக் கண்டறியுங்கள், ஏனெனில் ஒவ்வொரு சரிசெய்தலும் வேறு இடத்தில் வாழ்கிறது.

பாதையைப் பாருங்கள், இயந்திரத்தை அல்ல

சுரங்கப்பாதை இயங்கும்போது விருந்தினர் முகவரிக்கான ஹோஸ்ட்டின் ரூட்டிங் முடிவைப் பாருங்கள். இன்னும் ஹோஸ்ட்-மட்டும் அடாப்டரை நோக்கிக் காட்டும் பாதை சிக்கல் அல்ல. இப்போது VPN அடாப்டரை நோக்கிக் காட்டும் பாதையே சிக்கல், அதை நீங்கள் அல்ல, கிளையண்ட் மாற்றியது. அடாப்டர் தன் முகவரியைத் தக்கவைப்பது இடைமுகம் தப்பிப்பிழைத்தது என்பதைச் சொல்கிறது, இது பாதை தப்பிப்பிழைத்ததிலிருந்து வேறுபட்ட உண்மை.

இணைக்கும் சரியான தருணத்தில் விழும் SSH அமர்வு எதிர்பார்க்கப்பட்ட நடத்தை. கிளையண்ட் அடாப்டர்களை மறுசுழற்சி செய்து பாதைகளை நிறுவுகிறது, எனவே இணைப்பு சில வினாடிகள் இறக்கிறது. கோளாறு என்பது ஒருபோதும் திரும்பாத இணைப்பு, ஒரு கணம் மின்னியது அல்ல.

சுரங்கப்பாதைக்கு முன் அட்டவணையைப் பிடியுங்கள், பின்னர் மீண்டும், பிறகு அந்த இரண்டு வெளியீடுகளையும் ஒப்பிடுங்கள். வித்தியாசமே கண்டறிதல், அதுவே நெட்வொர்க் உரிமையாளர் கேட்கும் சான்றும் ஆகும்.

ip -4 route get 192.168.56.10
ip -brief addr show
ip route show table main | head -20

இணைவதற்கு முன் பின்னர் ஹோஸ்ட்டின் அட்டவணையைப் படியுங்கள்

லினக்ஸில் ஒன்றையொன்று மேலெழும் பாதைகளுக்கு இடையிலான முன்னுரிமை முன்னொட்டு நீளம் மற்றும் மெட்ரிக்கிலிருந்து வருகிறது, எனவே மிகவும் குறிப்பிட்ட VPN பாதை தவறாக இருந்தாலும் வெல்லும். விண்டோஸில் இடைமுக மெட்ரிக் சமநிலையைத் தீர்மானிக்கிறது, சுரங்கப்பாதை அடாப்டர் பொதுவாக மெய்நிகர் அடாப்டரை விடக் குறைந்த மெட்ரிக்குடன் வருகிறது. இரண்டு சூழ்நிலைகளிலும் தெரியும் அறிகுறி ஒன்றே: பாக்கெட்டுகள் சுரங்கப்பாதை அடாப்டர் வழியாக வெளியேறி மறைந்துவிடுகின்றன.

விருந்தினர் முன்னொட்டின் பாதைக்கு அருகில் அடாப்டர்களையும் அவற்றின் மெட்ரிக்குகளையும் அச்சிடுங்கள். அந்த வெளியீட்டு ஜோடி உரிமைக் கேள்விக்கு ஒரு பார்வையில் பதிலளிக்கிறது.

Get-NetAdapter | Select-Object Name, InterfaceIndex, InterfaceMetric
Get-NetRoute -DestinationPrefix 192.168.56.0/24
route print -4 | Select-String '192.168.56'

பாதை மாறியது ஆனால் அடாப்டர் மெட்ரிக் மாறவில்லை என்றால், கிளையண்ட் போட்டியிடும் பாதையை நிறுவியது. மெட்ரிக் மாறியிருந்தால், கிளையண்ட் அடாப்டர்களை மறுவரிசைப்படுத்தியது. இரண்டையும் சரிசெய்யலாம், இரண்டும் வெவ்வேறு இடங்களில் சரிசெய்யப்படுகின்றன.

விருந்தினரின் NAT வரம்பே மோதலாக இருக்கும்போது

VirtualBox NAT இயல்பாக 10.0.2.0/24 பயன்படுத்துகிறது, அதே வரம்பைத் தள்ளும் சுரங்கப்பாதை விருந்தினரை அந்தப் போக்குவரத்தை உண்மையான இலக்குக்கு அல்ல, தன் NAT நுழைவாயிலுக்கு அனுப்ப வைக்கிறது. பாக்கெட் ஒருபோதும் ஹோஸ்ட்டை விட்டு வெளியேறாது, எனவே மறுபக்கத்தின் எந்த ஃபயர்வால் பதிவும் அதைக் காட்டாது. Docker Machine அதன் ஹோஸ்ட்-மட்டும் திட்டத்தில் அதே வகை மோதலைக் கொண்டுள்ளது, அந்தத் திட்டத்தை மாற்றுவது இயந்திரத்தை அதன் சான்றிதழ்களுடன் மீண்டும் உருவாக்க வேண்டியிருக்கலாம்.

சுரங்கப்பாதை ஏற்கனவே எதை அறிவிக்கிறது, பின்னர் அலுவலக நெட்வொர்க் எதைப் பயன்படுத்துகிறது, பின்னர் இந்த ஹோஸ்ட்டின் ஒவ்வொரு மெய்நிகர் அடாப்டரும் எதைக் கோரியது என்பதைப் பட்டியலிட்டு மாற்றீட்டைத் தேர்ந்தெடுங்கள். ரூட்டிங்கை உடைப்பது மேலெழுதலே, ஒற்றுமை பொருத்தமற்றது. ஒரு வரம்பு மற்றொன்றின் உள்ளே முழுவதுமாக அமர்ந்திருக்கலாம், ஆனால் முதல் பார்வையில் சிறிதும் ஒத்திருக்காது.

இயந்திரம் உருவாக்கப்படும்போது புதிய வரம்பை அமைக்கவும், அல்லது அதை மாற்றி மீண்டும் ஏற்றவும், பின்னர் விருந்தினரிடமிருந்து தோல்வியடையும் இணைப்பை மீண்டும் சோதிக்கவும். விருந்தினரின் சொந்த அட்டவணையே முக்கியமான பார்வை.

VBoxManage modifyvm devbox --natnet1 10.77.0.0/24
vagrant reload devbox --provision
vagrant ssh devbox -c 'ip route get 10.20.0.15'

கிளையண்டுடன் சண்டையிடாமல் பாதையை மீட்டெடுங்கள்

ஒவ்வொரு தளமும் ஹோஸ்ட்-மட்டும் முன்னொட்டை மீண்டும் முன்னுக்குக் கொண்டுவரும் வழியை வழங்குகிறது. macOS இல் ஹோஸ்ட்-மட்டும் இடைமுகத்திற்கான நிலையான பாதை அடுத்த இணைப்பு வரை வேலை செய்கிறது. விண்டோஸில் மெய்நிகர் அடாப்டரில் குறைந்த இடைமுக மெட்ரிக் அதை முன்னுரிமையில் வைக்கிறது. லினக்ஸில் மாற்று செயல்பாடு ஒரு முன்னொட்டை மட்டும் உள்ளடக்குகிறது. மூன்றும் தற்காலிக தீர்வுகள், ஏனெனில் தன் பாதைகளை மீண்டும் வலியுறுத்தும் கிளையண்ட் அவற்றை ரத்து செய்யும்.

துவக்கத்தில் குருட்டுத்தனமாக மீண்டும் இணைப்பதற்குப் பதிலாக சரிபார்ப்பை ஸ்கிரிப்ட் செய்யுங்கள். ஒவ்வொரு இணைப்பிற்குப் பிறகும் விருந்தினர் முன்னொட்டின் பாதையை அச்சிடும் சிறிய ஸ்கிரிப்ட் மர்மத்தை பதிவின் ஒரு வரியாக மாற்றுகிறது.

சுயவிவரம் முழு சுரங்கப்பாதையாக இருந்தால், நெட்வொர்க் உரிமையாளரிடம் பிளவு சுரங்கப்பாதை அல்லது ஆவணப்படுத்தப்பட்ட விதிவிலக்கைக் கேளுங்கள். பாதுகாப்புக் கொள்கையைத் தவிர்க்கும் பாதைகளை அமைதியாகச் சேர்ப்பது சரிசெய்தல் அல்ல, அது பின்னர் தணிக்கையாளருடன் வரும் இரண்டாவது சிக்கல்.

சரிசெய்தலை இரு பக்கங்களிலும் சரிபார்க்கவும்

மாற்றத்திற்குப் பிறகு மூன்று பாதைகளைச் சரிபார்க்கவும்: ஹோஸ்ட்டிலிருந்து விருந்தினருக்கு, விருந்தினரிலிருந்து நிறுவன ஹோஸ்ட்டுக்கு, மற்றும் விருந்தினரிலிருந்து இணையத்திற்கு. ஒன்றை மீட்டெடுத்து மற்றொன்றை உடைக்கும் சரிசெய்தல் பழுதுநீக்கத்தின் முகமூடியில் உள்ள கட்டமைப்பு மாற்றம். ஒப்பீடு சமமாக இருக்க, மாற்றத்திற்கு முன் சேகரித்த அதே வெளியீடுகளைப் பிடியுங்கள்.

மாறிய இடைமுகம், மெட்ரிக் மற்றும் பாதையை நேரத்துடன் பதிவு செய்யுங்கள், அடுத்த நிகழ்வு மீளுருவாக்கம் அல்ல, தேடலாக இருக்கட்டும். அந்தக் குறிப்பு நீண்ட டிக்கெட் இழையை விட மதிப்புமிக்கது.

ip -4 route get 192.168.56.10
traceroute -n -m 4 10.20.0.15
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

ஹோஸ்ட் மீண்டும் விருந்தினரை அடைந்து விருந்தினர் LAN ஐ அடையும்போது, நீங்கள் தொடங்கிய பாதையை மீட்டெடுத்துள்ளீர்கள். அவற்றில் ஒன்று மட்டும் வேலை செய்தால், மீதமுள்ள கோளாறு மற்ற உரிமையாளரின் எல்லையில் உள்ளது, வித்தியாசம் எந்த எல்லை என்பதைச் சொல்கிறது.

தொடர்புடைய கட்டுரைகள்