ரோமிங் VPN கிளையண்ட் அலுவலகத்திற்கான சேவையை ஹோஸ்ட் செய்ய முடியுமா?

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

டயல்-இன் திசை சேவையின் திசையைப் பற்றி எதுவும் கூறுவதில்லை

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

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

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

போர்ட்டைத் திறக்கும் முன் திரும்பும் பாதையைப் பின்பற்றுங்கள்

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

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

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

பெயர்களும் முகவரிகளும் வடிவமைப்பு முடிவுகள்

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

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

VPN அடையாளத்தின் உரிமையாளருடன் பெயரை ஒப்புக்கொள்ளுங்கள், அதனால் பதிவு, முகவரி ஒதுக்கீடு மற்றும் அணுகல் கொள்கை மூன்று தனி டிக்கெட்டுகளில் அல்லாமல் ஒன்றாக மாறும்.

உறுப்பினர் நிலை அல்ல, சேவையைச் சோதியுங்கள்

இலக்கிலிருந்து எது எந்த முகவரியில் கேட்கிறது என்பதை உறுதிசெய்து, பின்னர் திரும்பும் பாதை பற்றிய கேட்வேயின் பார்வையை உறுதிசெய்யுங்கள்:

$ ss -ltnp | grep 8080
LISTEN 0 128 10.80.0.23:8080 0.0.0.0:*
$ ip -4 addr show tun0 | grep inet
inet 10.80.0.23/24 scope global tun0
$ ip route get 10.80.0.1
10.80.0.1 dev tun0 src 10.80.0.23

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

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

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