நீங்கள் ss -lntup ஐ Access Server ஹோஸ்டில் இயக்கி, எதிர்பார்த்ததை விட இரண்டு மடங்கு நீளமான பட்டியலைப் பெறுகிறீர்கள். பாதி உள்ளீடுகள் அமைப்பின் போது யாரும் குறிப்பிடாத டீமன் வடிவ துறைகள். எதிர்வினை 443 அல்லது 1194 அல்லாத அனைத்தையும் மூடுவது, அப்படித்தான் மக்கள் தங்கள் சொந்த வாடிக்கையாளர் போர்ட்டலை உடைக்கிறார்கள்.

Access Server ஒரே கேட்பவர் அல்ல. இது VPN சேவை, வலை சேவை மற்றும் கிளஸ்டர் பங்கேற்பாளர், மேலும் நீங்கள் எத்தனை TCP டீமன்களை உள்ளமைத்தீர்கள் என்பதைப் பொறுத்து கூடுதல் டீமன்-குறிப்பிட்ட துறைகளையும் ஃபயர்வால் மறுவழிப்படுத்தல்களையும் உருவாக்கலாம்.

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

ஒரே படிக்க-மட்டும் கட்டளையுடன் தொடங்குங்கள்

sudo ss -lntup கேட்கும் ஒவ்வொரு சாக்கெட்டிற்கும் போக்குவரத்து, உள்ளூர் முகவரி, துறை மற்றும் உரிமையாளர் செயல்முறையை வழங்குகிறது. கொடிகள் முக்கியம்: -l கேட்பது, -n எண்ணியல், -t TCP, -u UDP, -p செயல்முறை. root இல்லாமல் சாக்கெட்டுகள் கிடைக்கும் ஆனால் செயல்முறைப் பெயர்கள் கிடைக்காது, வகைப்படுத்துதலுக்கு அதே நிரல் தேவை.

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

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

நீங்கள் அடையாளம் காண வேண்டிய கேட்பவர்கள்

இந்த இயல்புநிலை மதிப்புகள் பெரும்பாலான பயன்பாடுகளை உள்ளடக்கி ஒப்பிடுவதற்கு அடிப்படையைத் தருகின்றன. இவை இயல்புநிலைகள், முழுமையான அனுமதிப் பட்டியல் அல்ல.

SocketRole to confirm
UDP 1194OpenVPN UDP tunnel listener
TCP 443OpenVPN TCP listener, optionally forwarded to the web service
TCP 943Admin and client web interfaces, and cluster control in Access Server 3.0 and later
TCP 945Cluster control in older configurations that predate the move to 943

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

அறிந்த ஜோடிக்கு வெளியே உள்ள சாக்கெட்டும் தானாகவே எஞ்சியதல்ல. பல TCP டீமன்கள் உள்ளமைக்கப்பட்டால், Access Server ஒவ்வொரு டீமனுக்கும் கேட்பவர்களை உருவாக்கி போக்குவரத்தை அவற்றுக்கு மறுவழிப்படுத்துகிறது, எனவே அவற்றின் எண்ணிக்கையும் துறை மதிப்புகளும் அந்த உள்ளமைவைப் பின்பற்றுகின்றன.

எதையும் மூடும் முன் வகைப்படுத்துங்கள்

ஒவ்வொரு நிச்சயமற்ற வரிசைக்கும் இந்த வரிசையில் மூன்று கேள்விகளுக்குப் பதிலளியுங்கள்.

  1. உரிமையாளர் மற்றும் நோக்கம். PID ஐ ஒரு அலகு அல்லது செயல்முறையுடன் பொருத்தி அந்தச் சேவையின் உள்ளமைவைப் படியுங்கள். உரிமையாளரைப் பெயரிட முடியாவிட்டால், சாக்கெட் பற்றி எதையும் தீர்மானிக்க நீங்கள் தயாராக இல்லை.
  2. பிணைப்பின் எல்லை. Loopback பெயரிடைக்கு உள்ளூர். Wildcard பிணைப்பு வழித்தல், ஹோஸ்ட் வடிகட்டுதல் மற்றும் எந்தவொரு மேகநிலை விதிகளும் அனுமதித்தால் மட்டுமே அணுக முடியும், எனவே பிணைப்பு முகவரி அவசியம் ஆனால் போதுமானதல்ல. IPv4 மற்றும் IPv6 ஐ தனி முடிவுகளாகச் சரிபார்க்கவும்.
  3. வெளியிடப்பட்ட பாதை. சேவை அனுப்புதல், டீமன்-குறிப்பிட்ட மறுவழிப்படுத்தல்கள், வெளிப்புற ப்ராக்ஸி மற்றும் பயனுள்ள ஃபயர்வால் கொள்கையைத் தேடுங்கள். மக்கள் தவிர்க்கும் படி இதுவே, பாதிப்பில்லாததாகத் தெரியும் பின்தளத் துறையை அணுகக்கூடிய நிர்வாகப் பாதையாக மாற்றுவதும் இதுவே.

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

வெளியிடப்பட்ட பாதை சாக்கெட் பட்டியலில் இருந்து வேறுபடும் இடம்

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

கிளஸ்டர் கட்டுப்பாடு பதிப்பு முக்கியமான இரண்டாவது இடம். 3.0 மற்றும் அதற்குப் பிறகு இது 943 ஐப் பகிர்கிறது; பழைய கிளஸ்டர் உள்ளமைவுகள் 945 ஐப் பயன்படுத்தின. பதிப்பைச் சரிபார்க்காமல் அவற்றில் ஒன்றைத் திறப்பதும் தடுப்பதும் ஒழுங்காகத் தெரியும் ஆனால் தவறான பட்டியலை உருவாக்குகிறது.

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

எந்த மாற்றத்திற்கும் பிறகு சரிபார்க்கவும்

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

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

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

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