உங்கள் VM ஹோஸ்டின் VPN-ஐ பயன்படுத்துகிறதா? கெஸ்ட் உள்ளிருந்து சோதிக்கவும்

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

சோதனை கெஸ்ட்டின் உள்ளே இயங்க வேண்டும், மேலும் எதை அளந்தது என்று அது கூற வேண்டும்.

ஹோஸ்டின் உலாவியில் அல்ல, கெஸ்ட்டின் உள்ளிருந்து தொடங்குங்கள்

முதலில் ஹைப்பர்வைசரின் நெட்வொர்க் பயன்முறையைப் பதிவு செய்யுங்கள்: NAT, bridged, host-only அல்லது macvtap. NAT பயன்முறையில் ஹோஸ்ட் கெஸ்ட்டின் போக்குவரத்தை வழித்தடப்படுத்துகிறது, எனவே கிளையண்ட் வழித்தடங்களை எவ்வாறு நிறுவுகிறது என்பதைப் பொறுத்து ஹோஸ்டின் சுரங்கப்பாதை பொருந்தலாம் அல்லது பொருந்தாமல் இருக்கலாம். Bridged பயன்முறையில் கெஸ்ட் இயற்பியல் LAN-இல் சமமான பங்கேற்பாளர், ஹோஸ்டின் சுரங்கப்பாதை பொருத்தமற்றது. இந்த இரண்டு பயன்முறைகளும் ஒரே ஹோஸ்ட் உள்ளமைவிலிருந்து எதிர் பதில்களைத் தருகின்றன.

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

இலக்கு உங்களுக்குத் தெரிந்த ஒரு கோரிக்கையைச் செய்யுங்கள்

தான் கண்ட மூல முகவரியைத் தெரிவிக்கும் சேவைக்கு பாதிப்பில்லாத கோரிக்கையை அனுப்புங்கள். பின்னர் அந்த இலக்குக்கான கெஸ்ட்டின் சொந்த வழித்தட முடிவைச் சரிபாருங்கள்: ip route get 203.0.113.5 கெஸ்ட் பயன்படுத்தும் இடைமுகத்தையும் நுழைவாயிலையும் அச்சிடுகிறது.

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

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

தீர்வியைத் தனியாகச் சரிபார்க்கவும்

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

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

systemd ஹோஸ்ட்டில், resolvectl query பதிலுக்குப் பின்னால் உள்ள இடைமுகத்தையும் DNS சேவையகத்தையும் பெயரிடுகிறது. பழைய உள்ளமைவுகள் சேவையகத்தை dig வெளியீட்டில் காட்டுகின்றன. எப்படியிருந்தாலும், முக்கிய விஷயம் பதில் வந்ததா என்பதல்ல, எந்த சேவையகம் பதிலளித்தது என்பதைப் பார்ப்பதே.

வெற்றியை மட்டுமல்ல, தோல்விக் கொள்கையையும் சோதியுங்கள்

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

சுரங்கப்பாதை விழும்போது இயற்பியல் NIC-க்குத் திரும்பும் கெஸ்ட் NAT பயன்முறை அனுமதிப்பதைச் சரியாகச் செய்கிறது.

பயன்முறையையும் எல்லையையும் பதிவு செய்யுங்கள்

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

IPv4 சுரங்கப்பாதையைப் பின்பற்றியது என்றால், அதைச் சொல்லுங்கள். இந்தக் கூற்றை IPv6, மற்றொரு namespace அல்லது வேறு நெட்வொர்க்கில் உள்ள வேறு VM-க்கு விரிவுபடுத்த வேண்டாம்.