ESXi விருந்தினர் VPN: ரூட்டிங் அல்லது பிரிட்ஜிங் — போர்ட் குழுவுக்கு முன் முடிவு செய்யுங்கள்
ரூட்டட் TUN-க்கு திரும்பும் வழிகள் தேவை; பிரிட்ஜ்டு TAP-க்கு அடுக்கு 2 அணுகல் மற்றும் பரந்த போர்ட் குழு கொள்கை தேவை. promiscuous முறையை விரிவாக்கும் முன் பங்கை தீர்மானிக்கவும்.
பாக்கெட்டுகளை ரூட் செய்யுங்கள் அல்லது Ethernet களத்தை விரிவாக்குங்கள்: போர்ட் குழுவின் மாற்றம் அந்தத் தேர்வுக்குப் பிறகு வரும். தனியார் முகவரி கொண்ட பயன்பாட்டிலிருந்து முடிவுகள் ஒரே மாதிரியாகத் தோன்றலாம், ஆனால் ஹைப்பர்வைசரின் தேவைகள் முற்றிலும் வேறுபடும். அதனால்தான் முதலில் போர்ட் குழு விரிவாக்கப்படுகிறது, வடிவமைப்புக் கேள்விக்கு இரண்டாவதாக பதில் சொல்லப்படுகிறது, பொதுவாக broadcast புயலுக்குப் பிறகு. இந்த சோதனைகளை வரிசையாகச் செய்து, தேவை இன்னும் தெளிவற்றதாக இருக்கும்போது நிறுத்துங்கள், ஏனெனில் எந்த போர்ட்-குழு அமைப்பும் ஒருபோதும் தேர்ந்தெடுக்கப்படாத வடிவமைப்பைச் சரிசெய்யாது.
முடிவு சேவையின் உரிமையாளருக்கு உரியது; ஹைப்பர்வைசர் உள்ளமைவு அதைச் செயல்படுத்த வேண்டும், தற்செயலாக தீர்மானிக்கக்கூடாது.
தூர முனைக்கு உண்மையில் என்ன தேவை என்பதைச் சரிபார்க்கவும்
தொலைவு வாடிக்கையாளர்கள் அடைய வேண்டிய சேவைகளையும் அவர்கள் பயன்படுத்தும் நெறிமுறைகளையும் பட்டியலிடுங்கள். பட்டியல் அறியப்பட்ட முன்னொட்டுகளில் சில TCP சேவைகள் என்றால், ரூட்டிங் போதும். ஏதாவது உண்மையில் அடுக்கு 2 அண்டை நிலையைக் கோரினால் — broadcast சார்ந்த கண்டறிதல், IP அல்லாத நெறிமுறைகள், நுழைவாயிலை ஏற்காத சாதனம் — ரூட்டிங் அதைப் பின்பற்ற முடியாது, அதை முன்கூட்டியே சொல்ல வேண்டும். அந்தப் பட்டியலில் உள்ள IP அல்லாத உள்ளீடுகள் குறித்து நேர்மையாக இருங்கள், ஏனெனில் அங்குதான் ரூட்டட் வடிவமைப்பு ஒரு வாரம் கழித்து அமைதியாகத் தோல்வியடைகிறது.
பிறகு வாடிக்கையாளர் குளத்தைச் சரிபார்க்கவும். ரூட்டட் வடிவமைப்புக்கு முகவரி வரம்பும் தூரப் பக்கத்தில் தெளிவான திரும்பும் வழியும் தேவை; பிரிட்ஜ்டு வடிவமைப்புக்கு விரிவாக்கப்பட்ட Ethernet களம் முகவரி ஒதுக்கீடு மற்றும் தனிமையைக் கொண்டிருக்க வேண்டும். நீங்கள் எதைத் தேர்ந்தெடுத்தாலும், இந்த VM-க்கு வெளியே உள்ள ஒருவர் அதற்கு ஒப்புக்கொள்ள வேண்டும்.
ஒவ்வொரு வடிவமைப்பும் மெய்நிகர் வலையமைப்பிடம் கேட்பது
இரு வடிவமைப்புகளும் மெய்நிகர் வலையமைப்பு எதைத் தாங்க வேண்டும் என்பதில் வேறுபடுகின்றன, அதைப் பார்ப்பதற்கான குறுகிய வழி அட்டவணை:
| வடிவமைப்பு | விருந்தினர் பக்கப் பங்கு | மெய்நிகர் வலையமைப்பு எதை உள்ளடக்க வேண்டும் | தவறாகத் தேர்ந்தெடுத்தால் தோல்வி முறை |
|---|---|---|---|
| ரூட்டட் TUN | தனித்த முன்னொட்டுகளுக்கு இடையே ரூட்டர் | ரூட்டட் வாடிக்கையாளர் குளம் மற்றும் தூரப் பக்கத்தில் திரும்பும் பாதைகள் | வாடிக்கையாளர்கள் நுழைவாயிலை அடைகிறார்கள், அதன் பின்னால் உள்ள சேவையை ஒருபோதும் அடையவில்லை |
| பிரிட்ஜ்டு TAP | இணையும் வாடிக்கையாளர்களுக்கான அடுக்கு 2 பிரிட்ஜ் | கூடுதல் Ethernet அடையாளங்கள், broadcast போக்குவரத்து மற்றும் VLAN விதிகள் | vSwitch சட்டகங்களை வீசுகிறது, அல்லது வடிவமைப்புக்கு யாரும் அனுமதிக்காத promiscuous முறை தேவை |
ரூட்டிங் broadcast களத்தை அது இருக்கும் இடத்திலேயே வைத்து, நுழைவாயிலைக் கடக்கும் சேவைகளை வரம்பிட இயற்கையான இடத்தைத் தருகிறது. பிரிட்ஜிங் எல்லையை நகர்த்துகிறது: வாடிக்கையாளர்கள் விரிவாக்கப்பட்ட Ethernet களத்தின் பங்கேற்பாளர்களாகிறார்கள், முகவரி ஒதுக்கீடு, தனிமை மற்றும் எந்த அடுக்கு 2 கொள்கையும் இப்போது அவர்களுக்குப் பொருந்தும். தேர்ந்தெடுத்த வரியை மாற்றப் பதிவில் எழுதுங்கள். “ரூட்டட் TUN, வாடிக்கையாளர் குளம் 10.90.0.0/24, மையத்தில் திரும்பும் வழி” போன்ற வாக்கியம் அடுத்த பொறியாளர் போர்ட்-குழு அமைப்புகளிலிருந்து வடிவமைப்பை மீண்டும் வாதிடுவதைத் தடுக்கிறது.
யாருடைய சட்டகங்களை யார் பார்க்கலாம்
போர்ட் குழுவைத் தொடுவதற்கு முன் தள உரிமையாளரிடம் ஒரு கேள்வி கேளுங்கள்: இந்த VM மற்ற பங்கேற்பாளர்களுக்கு முகவரியிடப்பட்ட சட்டகங்களைப் பெற வேண்டுமா? பதில் இல்லை என்றால், இந்தப் பகுதியில் எதுவும் பொருந்தாது, ஏனெனில் ரூட்டட் TUN-க்கு அந்தத் தெரிவுநிலை ஒருபோதும் தேவையில்லை. பதில் ஆம் என்றால், promiscuous முறை குறித்த Broadcom வழிகாட்டுதல் முக்கிய வாசிப்பு: VM vSwitch-இலிருந்து எவ்வளவு அதிகமாகப் பார்க்க முடியும் என்பதை விளக்கி, அந்தக் கொள்கையை ஒரு போர்ட் குழுவுக்கு மட்டுப்படுத்தப் பரிந்துரைக்கிறது.
இதை அனுமதிச் சீட்டாக அல்ல, தேவைச் சரிபார்ப்பாகக் கருதுங்கள். பிரிட்ஜிங் தேவை எழுதப்பட்டதும் ஒரு பிரத்யேக இணைப்புக்கு அமைப்பை இயக்கி, மற்ற எல்லா இடங்களிலும் அணைத்து வையுங்கள். மற்றொரு பிரிட்ஜ் எடுத்துக்காட்டிலிருந்து நகலெடுக்கப்பட்ட அகலமான VLAN ட்ரங்க் நீக்க நினைவில் இருக்காத பகுதி, ஒரு-VLAN வடிவமைப்பு ஒரு-VLAN ஆகவே இருக்க வேண்டும்.
எந்த போர்ட் குழு மாறியது, ஏன் என்பதை வடிவமைப்பு வரியை எழுதிய அதே இடத்தில் பதிவு செய்யுங்கள். அந்த இணையே அடுத்த தணிக்கையைச் சாத்தியமாக்குகிறது.
விருந்தினரின் பொருட்களை வெளிப்படையாக வையுங்கள்
Linux-க்குள், பிரிட்ஜ் உறுப்பினர் நிலையும் முகவரி உரிமையும் தனித்தனி பொருட்கள், அவற்றைக் கலப்பது குழப்பமான பாதி-வேலை செய்யும் நிலையை உருவாக்குகிறது. முகவரிகளை பிரிட்ஜ் இடைமுகத்துக்கு அல்லது ரூட்டட் சுரங்கப்பாதைக்குக் கொடுங்கள், ஒரே பாதையின் இரு பக்கங்களுக்கும் அல்ல, உறுப்பினர் போர்ட்டுகளை IP உள்ளமைவு இல்லாமல் வையுங்கள்.
ஒரு துணை வலையமைப்பை சுயாதீனமாக ரூட்டட் TUN-இலும் தொடர்பில்லாத Ethernet இடைமுகத்திலும் வைப்பதைத் தவிர்க்கவும். அந்த உள்ளமைவு ஒரே முன்னொட்டுக்கு இரு பாதைகள் உருவாக்குகிறது, சமச்சீரற்ற பதில்கள் மற்றும் flapping குறித்த ஆதரவு இழை, இரு பாதைகளில் ஒன்றையும் குறிப்பிடாது. விருந்தினர் கொள்கலன்கள் அல்லது உள்ளூர் ஹைப்பர்வைசரையும் ஹோஸ்ட் செய்தால், அவை ஏற்கனவே அதே uplink-க்கு பிரிட்ஜ் செய்யவில்லை என்பதைச் சரிபார்க்கவும். ஒரு NIC-இல் இரு பிரிட்ஜ்கள் ஒரு வடிவமைப்பு, மாற்ற சாளரத்தில் கண்டறிய விரும்பாத விபத்து அல்ல.
ping-ஆல் அல்ல, பாக்கெட் பாதையால் உறுதிப்படுத்துங்கள்
அணுகல் மட்டுமல்ல, உண்மையான பாதையைச் சரிபார்க்கவும். வாடிக்கையாளரிடமிருந்து எந்த மூல முகவரி தூரச் சேவையை அடைகிறது என்பதை உறுதிப்படுத்தி, பிறகு பதில் அதே வழியில் திரும்புகிறது என்பதை உறுதிப்படுத்துங்கள். விருந்தினரில் குறிப்பிட்ட ஓட்டத்திற்கான அனுப்பு கணக்குகளைப் பாருங்கள், போர்ட் குழுவில் தேர்ந்தெடுத்த வடிவமைப்பின் தேவைக்கு மேல் கூடுதல் தெரிவுநிலை இயக்கப்படவில்லை என்பதை உறுதிப்படுத்துங்கள்.
இறுதியாக தோல்வியின் திசையைச் சோதியுங்கள். சுரங்கப்பாதையை நிறுத்துங்கள் அல்லது வாடிக்கையாளரைப் பிரிக்கவும், பயன்படுத்தப்படவில்லை என நீங்கள் கருதிய ரூட்டட் பாதைக்கு போக்குவரத்து அமைதியாக விழுகிறதா என்பதைச் சரிபார்க்கவும், ஏனெனில் அந்த வீழ்ச்சியே பிரிட்ஜ்டு வடிவமைப்பு அமைதியாக எதிர்பாராத ரூட்டராக மாறும் வழி.