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

ஒரே கோரிக்கையில் மூன்று அடையாளங்கள் தோன்றலாம்

VPN சகன் வாடிக்கையாளர் சான்றிதழ் அல்லது சகன் விசை போன்ற பதிவுசெய்யப்பட்ட அடையாளத்தைக் கொண்டுள்ளது. உள் IP பாக்கெட் மூல முகவரியைக் கொண்டுள்ளது. கோப்பு செயல்பாடு அதன் NFS பொறிமுறை வழங்கும் பயனர் சான்றுகளைக் கொண்டுள்ளது. முகவரியை மூன்றின் பிரதிநிதியாகக் கருதும் வடிவமைப்பு சரிபார்க்க வேண்டிய பகுதியையே அமைதியாகக் கருதிவிட்டது.

IdentityWhat it provesWhat it does not
VPN peerWhich peer was accepted by the tunnelWhich user runs on that machine
Inner source addressWhere the packet appears to originateThat only the intended client can use it
NFS credentialWhat the file service believes about the callerAnything, if the flavour only asserts local IDs

அந்த மூன்று வரிகளை எழுதுவதே முழுப் பயிற்சி. ஏற்றுமதி பாதுகாப்பானதா என்பதற்கான விவாதத்தின் பெரும்பகுதி எந்தக் கட்டுப்பாடு எந்த வரியில் வாழ்கிறது என்பது தெளிவானதும் சரிந்துவிடும்.

முகவரி உரிமை என்பது செயலாக்க விவரம்

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

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

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

ஏற்றுமதியை நம்புவதற்கு முன் பாதுகாப்பு பிளேவரைப் படியுங்கள்

Red Hat-இன் NFS வழிகாட்டுதல் AUTH_SYS வழியாக உள்ளூர் UNIX UID மற்றும் GID-களைப் பயன்படுத்தும் sec=sys-ஐ Kerberos முறைகளிலிருந்து வேறுபடுத்துகிறது. krb5 பயனர் அங்கீகாரத்தைச் சேர்க்கிறது, krb5i ஒருமைப்பாடு பாதுகாப்பைச் சேர்க்கிறது, krb5p போக்குவரத்துக்குத் தனியுரிமை பாதுகாப்பைச் சேர்க்கிறது.

AUTH_SYS சான்றுகளில் அழைப்பவரின் UID மற்றும் குழு அடையாளங்காட்டிகள் போன்ற புலங்கள் உள்ளன, இந்த பிளேவர் தானாகவே எந்தப் பாதுகாப்பையும் வழங்காது, வெளிப்புற பாதுகாப்பைச் சார்ந்துள்ளது என்று RFC 5531 தெளிவாக எச்சரிக்கிறது. அதை VPN-க்குள் இயக்குவது போக்குவரத்துக்குப் பாதுகாப்பைத் தருகிறது, பாக்கெட்டின் உள்ளேயுள்ள கூற்றில் எதையும் மாற்றவில்லை.

exportfs -v
showmount -e nfs.example.internal

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

மாதிரியைத் தேர்ந்தெடுத்து, பின்னர் அனுமதிகளை வைத்திருங்கள்

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

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

முகவரி விதியை அதன் உண்மையான நோக்கத்திற்குப் பயன்படுத்துங்கள்

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

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

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

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