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

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

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

அந்தப் பதிவே விளைவு. ஒரு பங்குதாரருக்கு அதை எழுத முடியாவிட்டால், அந்தப் பங்குதாரர் மையப்படுத்தலுக்குத் தயாரில்லை.

இலக்கால் மட்டுமல்ல, சூழலால் வழித்தடம் அமைக்கவும்

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

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

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

பணியாளர் என்ன தட்டச்சு செய்கிறார், பங்குதாரர் என்ன பதிவு செய்கிறார் என்பதை முடிவு செய்யுங்கள்

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

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

பங்குதாரர்-க்கு-பங்குதாரர் கடத்தலை வெளிப்படையாக மறுக்கவும்

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

மறுப்பை அனுமதிகளுக்கு அடுத்ததாகப் பங்குதாரரின் பதிவில் எழுதுங்கள், அதனால் நோக்கம் பணியாளர் மாற்றங்களையும் தாண்டி நீடிக்கும்.

இதை ஒரு பெரிய மடிக்கணினியாக அல்ல, பங்கிடப்பட்ட சேவையாக இயக்குங்கள்

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

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

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

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