இரு முனைகளிலும் ஒரே துணை வலை: தொலை LAN-ஐ இலவச வரம்புக்கு மேப் செய்யுங்கள்
கிளையண்ட் பக்க முகவரி மேப்பிங் ஒன்றுடன் ஒன்று மேலிடும் தொலை LAN-ஐ இலவச வரம்பின் கீழ் வழங்க முடியும், ஆனால் சில கிளையண்டுகள் மட்டுமே அதைப் பயன்படுத்துகின்றன, திரும்பு பாதை எப்படியும் இருக்க வேண்டும்.
வீடும் அலுவலகமும் இரண்டும் 192.168.1.0/24 பயன்படுத்துவதால், 192.168.1.1 க்கான கோரிக்கைக்கு இரண்டு சாத்தியமான பதில்கள் உள்ளன, கிளையண்ட் கேட்காமலே ஒன்றைத் தேர்ந்தெடுக்கிறது. இயங்கும் அலுவலக வலையமைப்பை மறுஎண்ணிடுவது அரிதாகவே விரும்பப்படும், ரவுட்டரின் முகவரிகள் அச்சுப்பொறிகள், கேமராக்கள் மற்றும் ஆவணங்களில் அடிக்கடி பதிந்திருக்கும். கிளையண்ட் பக்க முகவரி மேப்பிங் அதற்குப் பதிலாக தொலை வலையமைப்பை இலவச வரம்பின் கீழ் வழங்க முடியும், ஹோஸ்ட் பகுதி அதேபோல் இருக்க முடியும், அதனால் 192.168.1.20 10.203.41.20 ஆகத் தெரிகிறது. சிக்கல் என்னவென்றால் சில கிளையண்டுகள் மட்டுமே அதைச் செயல்படுத்துகின்றன, திரும்பு பாதைக்கு அது எதுவும் செய்யாது.
ஒரே ஹோஸ்ட்டின் இரு பார்வைகள்
மேப்பிங் ஹோஸ்ட் பகுதியை வைத்துக்கொண்டு வலையமைப்புப் பகுதியை மட்டும் மாற்றுகிறது. பிறகு அதே இயந்திரம் நீங்கள் நிற்கும் இடத்தைப் பொறுத்து இரு முகவரிகளில் பதிலளிக்கிறது. எதையும் உள்ளமைக்கும் முன் இரு நிரல்களையும் எழுதிவைப்பது பின்னர் பதிவுகளையும் ஃபயர்வால் விதிகளையும் தவறாகப் படிப்பதைத் தடுக்கிறது.
| The application dials | The remote device is |
|---|---|
| 10.203.41.1 | 192.168.1.1 |
| 10.203.41.20 | 192.168.1.20 |
வீட்டு உள்ளூர் சாதனங்கள் தங்கள் 192.168.1.x முகவரிகளை வைத்திருக்கின்றன, இதுவே இந்தப் பயிற்சியின் நோக்கம். அடுத்த அறையின் அச்சுப்பொறி அணுகக்கூடியதாகவே உள்ளது, அலுவலகம் மோதாத வரம்பின் கீழ் தெரிகிறது.
வாதங்களின் வரிசையே முழு தந்திரம்
இந்த விருப்பம் திசை, வலையமைப்பு மற்றும் மாஸ்க், மற்றும் ஒரு மாற்றுப்பெயரை எடுக்கிறது: முதல் வலையமைப்பு கிளையண்ட் பார்ப்பது, மாற்றுப்பெயர் சேவையகம் பார்ப்பது. தொலை நுழைவாயிலுக்குப் பின்னால் உள்ள வளங்களுக்கு திசை என்பது இலக்கு வடிவம். கடைசி வாதம் மாற்றுப்பெயர் என அழைக்கப்படுவதால் இரு வலையமைப்புகளையும் தலைகீழாக மாற்றுவதே இணைக்கும் ஆனால் எதையும் மேப் செய்யாத சுரங்கப்பாதையை உருவாக்கும் தவறு.
push "route 10.203.41.0 255.255.255.0"
push "client-nat dnat 10.203.41.0 255.255.255.0 192.168.1.0"
புதிய வரம்புக்கான கிளையண்டின் பாக்கெட்டுகளைச் சுரங்கப்பாதைக்கு அனுப்புவது பாதை; மொழிபெயர்ப்பு வழியில் இலக்கை மீண்டும் எழுதுகிறது. 192.168.1.20 இலிருந்து பதில் 10.203.41.20 க்கு மீண்டும் எழுதப்படுவதால் கிளையண்டின் சாக்கெட் சீரானதாக இருக்கும். ஒரு ஹோஸ்ட் முழு நீள மாஸ்குடன் அதேபோல் செயல்படுகிறது, பாதையும் மேப்பிங்கும் ஒரே முகவரியை விவரிக்கும் வரை.
இது முகவரி மேப்பிங், போர்ட் மேப்பிங் அல்ல. ஒரு ஹோஸ்ட்டில் இரு சேவைகளை இதனால் பிரிக்க முடியாது, தன் பேலோடில் IP முகவரிகளைப் பொதித்துள்ள நெறிமுறை இன்னும் உண்மையானவற்றைப் பார்க்கும்.
மேப்பிங் திரும்பு பாதையை உருவாக்காது
மொழிபெயர்ப்பு கிளையண்டில் நடக்கிறது, எனவே சேவையகம் இன்னும் பதில்களைச் சுரங்கப்பாதைக்கு வழிமாற்ற வேண்டும், அதன் ஃபயர்வால் இன்னும் அவற்றை அனுமதிக்க வேண்டும். தொலை நுழைவாயிலுக்குச் சுரங்கப்பாதையின் துணை வலையை அடைவது எப்படி என்று தெரியாவிட்டால், கோரிக்கை வருகிறது, பதில் தவறான கதவு வழியே வெளியேறுகிறது; மேப்பிங் தோல்வியைக் கிளையண்ட் பிரச்சினைபோல் காட்டுகிறது.
சேவையகப் பக்க விதிகள் மொழிபெயர்ப்புக்குப் பிறகு சேவையகத்தில் உள்ள முகவரிகளை விவரிக்க வேண்டும், கிளையண்டுக்குத் தெரியும் வரம்பை அல்ல. மாற்றுப்பெயரை அனுமதி விதியில் நகலெடுப்பது ஒரு பிற்பகலை வீணாக்குகிறது, ஏனெனில் அந்தப் பக்கத்தில் எந்தப் பாக்கெட்டும் அதைச் சுமக்காது.
கிளையண்ட் வழிமாற்றும் வேறு எதனுடனும் மோதாத மாற்றுப்பெயர் வரம்பைத் தேர்ந்தெடுங்கள்: மற்றொரு VPN, கொள்கலன் வலையமைப்பு, இரண்டாம் அலுவலகம். இங்கு மோதல் அசல் தெளிவின்மையை வேறு எண்ணின் கீழ் மீண்டும் கொண்டுவருகிறது, முகவரிகள் அறிமுகமில்லாததாகத் தெரிவதால் கவனிப்பது கடினம்.
பெயர்களும் பேலோடுகளும் மொழிபெயர்ப்பைத் தாண்டி வாழ்கின்றன
உண்மையான 192.168.1.20 க்குத் தீர்க்கும் ஹோஸ்ட்பெயர் உலாவியைத் தொலை சாதனத்திற்கு அல்ல, உள்ளூர் சாதனத்திற்கு அனுப்புகிறது, வழிமாற்று அட்டவணை என்ன சொன்னாலும். தனியார் DNS பதில் கிளையண்டுக்குத் தெரியும் வரம்பைச் சுட்ட வேண்டும், TLS சான்றிதழ் இன்னும் பயன்பாடு எதிர்பார்க்கும் பெயரைக் கொண்டுள்ளது. முகவரிக்குப் பதிலாகப் பெயரால் சோதியுங்கள், ஏனெனில் முகவரி வேலை செய்யலாம், பெயர் அமைதியாகத் தவறான திசையில் தீர்க்கப்படலாம். தொலை நுழைவாயில் அந்த மண்டலத்தையும் வழங்கினால், அதன் சொந்தப் பதிவுகளுக்கும் கிளையண்டுக்குத் தெரியும் வரம்பு தேவை.
வழிமாற்றங்கள், உட்பொதிக்கப்பட்ட URL கள் மற்றும் தங்கள் முகவரியைப் பேலோடில் வழங்கும் பயன்பாடுகள் எந்தப் பாக்கெட் மேப்பிங்காலும் சரிசெய்ய முடியாத வகையில் உடையலாம். அவற்றைப் பயன்பாட்டுப் பிரச்சினையாகக் கருதி, மறுஎண்ணிடுவது தேவையில்லை என்று உறுதியளிக்கும் முன் முயற்சியை அதற்கேற்ப அளவிடுங்கள்.
உறுதியளிப்புக்கு முன் மூன்று சோதனைகள்
முதலில், கிளையண்ட் செயலாக்கத்தை உறுதிப்படுத்துங்கள். Community OpenVPN இந்த விருப்பத்தை ஆதரிக்கிறது; OpenVPN 3 குறியீட்டுத் தளம் அதை ஆதரிக்கப்படாத அம்சங்களில் பட்டியலிடுகிறது, எனவே Connect பாணி கிளையண்டுக்குத் தள்ளப்பட்ட சுயவிவரம் அதை வெறுமனே புறக்கணிக்கலாம். ஏற்கப்பட்டு ஒருபோதும் பயன்படுத்தப்படாத வழிமுறை பிழையைவிட மோசமானது, சுரங்கப்பாதை ஆரோக்கியமாகத் தெரிவதால்.
இரண்டாவதாக, அதிக விவரநிலையில் குறுகிய கண்டறியும் சாளரத்துடன் பாதையையும் மொழிபெயர்ப்பையும் தனித்தனியாகச் சரிபார்த்து, பின்னர் ping க்குப் பதிலாக உண்மையான சேவையைச் சோதியுங்கள். மூன்றாவதாக, உள்ளூர் ரவுட்டரும் தொலை வளமும் கிளையண்டிலிருந்து வேறுபடுத்தக்கூடியதாக இருப்பதை உறுதிப்படுத்துங்கள், அதுவே அசல் இலக்கு.
கிளையண்ட் மொழிபெயர்ப்பைச் செய்ய முடியாவிட்டால், நுழைவாயில் பக்கத்திடம் உதவி கேளுங்கள் அல்லது மறுஎண்ணிடுவதை ஏற்றுக்கொள்ளுங்கள். அதே முகவரிக்கு மேலும் பாதைகளைச் சேர்ப்பது வடிவமைப்பு அல்ல.