Access Server வாடிக்கையாளர்கள் LAN-இலிருந்து ஏன் அணுக முடியாதவை

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

சேவை பார்க்கும் மூல முகவரியை படியுங்கள்

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

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

ip -br addr show
ss -tnp state established '( dport = :443 )'
ip route get 10.90.0.25

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

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

பதில் தீர்மானிக்கப்படும் இடத்தில் பாதையை சேர்க்கவும்

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

ip route add 10.90.0.0/24 via 10.0.1.5
ip route get 10.90.0.25

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

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

ஃபார்வேர்டிங் மற்றும் வடிகட்டிகள் பாதையுடன் ஒத்துப்போக வேண்டும்

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

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A5 forward

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

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

ரூட்டட் அல்லது மாஸ்க்ட்: வேண்டுமென்றே தேர்ந்தெடுக்கவும்

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

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

வாடிக்கையாளருக்குப் பின்னால் உள்ள துணைநெட்வொர்க் தனி வேலை

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

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

ஒரு ஓட்டம் மற்றும் ஒரு பதிவுடன் சரிபார்க்கவும்

பொதுவான அணுகல் சோதனைக்குப் பதிலாக ஒரே இணைப்பால் பாதையை நிரூபியுங்கள். இரு முனைகளிலும் அதே ஓட்டத்தைக் கவனியுங்கள்: சேவைக்கு வரும் கோரிக்கையும் அதை விட்டுச் செல்லும் பதிலும்.

tcpdump -ni any host 10.90.0.25 and port 443

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

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