VPN மாற்றத்திற்குப் பிறகு ரவுட்டரின் நிர்வாகப் பக்கம் பதிலளிப்பதை நிறுத்துவது ஏன்
VPN மாற்றம் ரவுட்டரின் நிர்வாகப் பாதையை வெட்டலாம் அல்லது அமைதியாக விரிவாக்கலாம். சுரங்கப்பாதையை நம்புவதற்கு முன் பாதை, உள்ளீட்டு விதி மற்றும் கேட்பான் ஆகியவற்றைச் சரிபார்க்கவும்.
சுரங்கப்பாதையைச் சோதிக்க ஒரு பாதையையோ ஃபயர்வால் விதியையோ மாற்றினீர்கள், இப்போது பத்து நிமிடங்களுக்கு முன் நன்றாக இயங்கிய மடிக்கணினியிலிருந்து நிர்வாகப் பக்கம் பதிலளிக்கவில்லை. முதல் எதிர்வினை VPN-ஐக் குறைகூறுவது. பெரும்பாலும் சுரங்கப்பாதை ஆரோக்கியமாக இருக்கும், மற்ற மூன்றில் ஒன்று உடைந்திருக்கும்: ரவுட்டரின் சொந்த முகவரிக்குத் திரும்பும் பாதை இல்லை, ஒரு உள்ளீட்டுக் கொள்கை கோரிக்கையை வீசுகிறது, அல்லது நீங்கள் அழைக்கும் முகவரியில் வலைச் சேவை கேட்கவில்லை. மூன்றும் உலாவியில் ஒரே மாதிரி தெரிகின்றன, அதனால் மக்கள் ஒரு மணி நேரம் சுரங்கப்பாதையை மீண்டும் தொடங்குகிறார்கள், எதையும் கற்றுக்கொள்வதில்லை.
முதலில் கொல்ல வேண்டிய கட்டுக்கதை இதுதான்: இயங்கும் சுரங்கப்பாதை உள்ளே திரும்பும் வழி அல்ல. அது தனது சொந்த நம்பிக்கைக் கேள்விகளைக் கொண்ட புதிய பிணைய இணைப்பு, யாரும் பரிசோதிக்காத புதிய பாதையைத் திறக்கும்போது பழைய நிர்வாகப் பாதையை அமைதியாக அகற்றலாம்.
சுரங்கப்பாதை ஒருபோதும் நிர்வாகப் பாதையாக இருக்கவில்லை
முன்னனுப்புதல் மற்றும் உள்ளீடு வெவ்வேறு வேலைகள். "ஒரு வாடிக்கையாளர் சுரங்கப்பாதை வழியாக NAS-ஐ அடைய முடியுமா?" என்பது ரவுட்டர் வழியாகச் செல்லும் பொதிகளைப் பற்றிய முன்னனுப்புதல் கேள்வி. "ரவுட்டரின் SSH துறையைத் திறக்க முடியுமா?" என்பது ரவுட்டருக்கே முகவரியிடப்பட்ட பொதிகளைப் பற்றிய உள்ளீட்டுக் கேள்வி. முன்னனுப்பப்பட்ட போக்குவரத்துக்காக எழுதப்பட்ட அனுமதி விதி இரண்டாவது கேள்விக்கு எதுவும் செய்யாது, போக்குவரத்தைச் சிறப்பாகக் கொண்டு செல்லும் சுரங்கப்பாதையும் உங்கள் நிர்வாக அமர்வை மறுப்பதற்கு இதுவே பொதுவான காரணம்.
எதிர் தவறு இடைமுகப் பெயரை நம்புவது. சுரங்கப்பாதை இணைக்கு மறையாக்கம் செய்யப்படுகிறது, அதன் பின்னால் உள்ள ஒவ்வொரு சேவைக்கும் அல்ல, இடைமுகக் குறிச்சொல்லில் உள்ள VPN என்னும் சொல் எந்த மூலங்கள் உள்நுழைய அனுமதிக்கப்பட வேண்டும் என்பதைப் பற்றி எதுவும் சொல்லவில்லை.
முதல் அடுக்கு: ரவுட்டரின் சொந்த முகவரிக்குப் பாதை உள்ளதா?
வாடிக்கையாளரில் தொடங்கி பொதி எங்கே செல்லும் என கர்னலிடம் கேளுங்கள். Linux-இல் ip route get 10.6.0.1 தேர்ந்தெடுத்த பாதை, வெளிச் செல்லும் இடைமுகம் மற்றும் மூல முகவரியை அச்சிடுகிறது. அது உங்கள் வழங்குநரை நோக்கிய இயல்புநிலைப் பாதையைத் தெரிவித்தால், பொதி ஒருபோதும் சுரங்கப்பாதைக்குள் நுழையாது, ரவுட்டரின் எந்த விதியும் அதைக் காப்பாற்ற முடியாது.
சுரங்கப்பாதைப் பக்கத்திற்கு கேள்வியின் சொந்தப் பதிப்பு உண்டு. WireGuard AllowedIPs-ஐ மறையாக்க விசை வழித்தட அட்டவணையாகக் கருதுகிறது: ஒவ்வொரு முனையிலும் இணை எந்த மூல முகவரிகளைப் பயன்படுத்தலாம், எந்த இலக்குகள் அந்த இணைக்கு அனுப்பப்படுகின்றன என்று அறிவிக்கிறது. வாடிக்கையாளர் உள்ளீட்டில் ரவுட்டரின் சுரங்கப்பாதை முகவரி இல்லையென்றால், வாடிக்கையாளருக்கு அங்கு பாதை இல்லை. அந்த வாடிக்கையாளருக்கான சேவையக உள்ளீடு வாடிக்கையாளரின் சுரங்கப்பாதை முகவரியை மறைக்கவில்லை என்றால், எந்த ஃபயர்வால் விதியையும் பார்ப்பதற்கு முன்பே சேவையகம் பொதியை வீசுகிறது.
கொள்கையைப் பிழைத்திருத்துவதற்கு முன் நீங்கள் அடைய விரும்பும் சரியான முகவரியை உறுதிப்படுத்துங்கள். பழைய DNS பதிவு அல்லது மாற்றத்திற்கு முன் தேக்ககப்படுத்தப்பட்ட அண்டைப் பதிவு ரவுட்டரிடம் ஒருபோதும் இல்லாத முகவரிக்கு உங்களை அனுப்புகிறது.
இரண்டாம் அடுக்கு: உள்ளீட்டுக் கொள்கை, முன்னனுப்புதல் கொள்கை அல்ல
ஃபயர்வால்கள் பொதி வரும் இடைமுகத்தில் விதிகளை மதிப்பிடுகின்றன. pfSense மற்றும் OPNsense-இல் இடைமுகத் தாவலும் விதிகளின் வரிசையும் ஃபயர்வாலின் சொந்தச் சேவைகளுக்கான போக்குவரத்து அனுமதிக்கப்படுகிறதா என்பதைத் தீர்மானிக்கின்றன; LAN வாடிக்கையாளர்களை இணையத்திற்கு அனுப்பும் விதி சுரங்கப்பாதை இணைக்கு வலை GUI திறக்க அனுமதிக்கும் விதி அல்ல. firewall4 உள்ள OpenWrt-இல் ஒவ்வொரு மண்டலமும் உள்ளீட்டுக் கொள்கையைக் கொண்டுள்ளது, option input 'ACCEPT' அல்லது 'REJECT', உள்ளீடு REJECT உள்ள மண்டலத்தில் உள்ள சுரங்கப்பாதை இடைமுகம் நிர்வாக இணைப்புகளை மறுக்கும், ஆனால் முன்னனுப்புதல் அனுமதிக்கப்பட்டால் போக்குவரத்தை இன்னும் முன்னனுப்பும்.
புதிய பாதை வேலை செய்ய பூட்டுத் தடுப்பு விதியை முடக்க வேண்டாம். அந்த விதி மோசமான விதி LAN நிர்வாக முகவரியைப் பூட்டுவதைத் தடுக்கிறது; அது LAN துணைப் பிணையத்தைப் பாதுகாக்கிறது, நீங்கள் இப்போது உருவாக்கிய சுரங்கப்பாதை துணைப் பிணையத்தை அல்ல. நிர்வாகியின் மூலத்திற்கு ஒரு குறுகிய விதியைச் சேர்த்து பாதுகாப்பு வலையைத் தனியாக விடுங்கள். pfSense-இன் நிர்வாக அணுகல் ஆவணம் அந்தக் கட்டுப்பாடுகள் எங்கே உள்ளன என்பதை விளக்குகிறது.
# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b' # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b' # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input' # firewall4
pfctl -sr | head -40 # pf / pfSense
மூன்றாம் அடுக்கு: அந்த முகவரியில் ஏதாவது கேட்கிறதா?
ஒரு சேவை இயங்கிக்கொண்டிருந்தும் ஒரே முகவரியில் பிணைந்துள்ளதால் அடைய முடியாமல் இருக்கலாம். OpenWrt-இன் uhttpd /etc/config/uhttpd-இல் வெளிப்படையான கேட்புப் பதிவுகளை வைத்திருக்கிறது, எடுத்துக்காட்டாக list listen_http '0.0.0.0:80'; LAN முகவரியில் மட்டும் பிணைக்கும் கட்டுமானம் சுரங்கப்பாதை முகவரியில் எதையும் ஏற்காது, கேட்பு இடைமுக அமைப்பைக் காட்டும் தயாரிப்புகளும் அதேபோல் செயல்படும். மேலே உள்ள கேட்புக் கட்டளைகள் இதற்கு நேரடியாகப் பதிலளிக்கின்றன.
பின்னர் மறுப்பை அமைதியிலிருந்து பிரிக்கவும். nc -vz 10.6.0.1 443 மறுக்கப்பட்ட இணைப்பைத் திருப்பித் தந்தால் பொதி ரவுட்டரை அடைந்தது, ஏதோ அதை மறுத்தது, மூடிய துறை அல்லது வெளிப்படையான மறுப்பு விதி. காலாவதி வரை தொங்குவது பொதி வீசப்பட்டது அல்லது ஒருபோதும் வழித்தடப்படுத்தப்படவில்லை என்பதாகும். இந்த வேறுபாடு அடுத்து எந்த அடுக்கைச் சரிபார்க்க வேண்டும் எனக் கூறுகிறது, அதற்கு ஐந்து வினாடிகள் ஆகும்.
VPN இடைமுகம் ஒரு எல்லை, மீட்புப் பாதை அல்ல
மறையாக்கம் கம்பியைப் பாதுகாக்கிறது; நிர்வாகப் பக்கத்தை யார் திறக்கலாம் என்பதைப் பற்றி எதுவும் சொல்லவில்லை. சுரங்கப்பாதை இயங்கத் தொடங்கியதும், சுரங்கப்பாதை இடைமுகத்தில் எல்லாவற்றையும் அனுமதித்து அணுகலைத் தீர்க்கும் தூண்டுதலை எதிர்த்து நில்லுங்கள். நிர்வாகிகளுக்கு அவர்களின் சொந்த சுரங்கப்பாதை முகவரியில் பிணைந்த விதியை அல்லது தனி நிர்வாகி-மட்டும் சுரங்கப்பாதையைக் கொடுங்கள், சாதாரணப் பயனர்கள், NAS, கேமராக்கள், குடும்ப மடிக்கணினிகளை நிர்வாகத் துறையிலிருந்து விலக்கி வையுங்கள். கோப்புப் பகிர்வு தேவைப்படும் இணை ரவுட்டர் உள்நுழைவிலிருந்து ஒரு விதி தூரத்தில் கூட இருக்கக் கூடாது.
ரவுட்டரின் பங்கு பதிலை மாற்றுகிறது. சுரங்கப்பாதையை முடிக்கும் ரவுட்டர் அதிலிருந்து நிர்வாகிகளைச் சட்டப்படி ஏற்கலாம், ஆனால் சுரங்கப்பாதையை இணைய வெளியேற்றமாக மட்டும் பயன்படுத்தும் ரவுட்டர் வழக்கமாக அவ்வாறு செய்யக் கூடாது. இரண்டு நிலைகளிலும் துணைப் பிணைய அனுமதி உள்நுழைவு அல்ல, எனவே கணக்கு அங்கீகாரம் மற்றும் போக்குவரத்துப் பாதுகாப்பை இயக்கத்தில் வையுங்கள்.
பூட்டப்பட்ட பிறகு மக்கள் எடுக்கும் ஈடுசெய் நடவடிக்கை மோசமானது: WAN நிர்வாகத்தை இயக்குவது அல்லது ஒரு துறையை வலை GUI-க்கு முன்னனுப்புவது. இது குறுகிய இடையூறை நிரந்தர வெளிப்பாடாக மாற்றுகிறது, உள்நுழைவுப் பக்கம் அப்போது இணையத்தின் ஒவ்வொரு ஸ்கேனருக்கும் அணுகக்கூடியதாகிறது. அனுமதிக்கப்பட்ட பக்கத்தைப் போலவே மறுக்கப்பட்ட பக்கத்தையும் சோதியுங்கள், இதனால் நிர்வாக அணுகல் இருக்கக் கூடாத இணை உள்நுழைவுக் கோரிக்கைக்குப் பதிலாக காலாவதி அல்லது மறுப்பைப் பெறும்.
புதிய இணைப்பிலும் சோதியுங்கள். நிலைமை ஃபயர்வால் தற்போதைய ஓட்டங்களைத் தனது நிலை அட்டவணையில் வைத்திருக்கிறது, எனவே ஏற்கனவே திறந்துள்ள SSH அமர்வு ஒவ்வொரு புதிய இணைப்பையும் தடுக்கும் மாற்றத்தைத் தாண்டி நீடிக்கலாம். அதனால்தான் பூட்டுதல் அடுத்த மறுதொடக்க அல்லது அடுத்த மடிக்கணினி உறக்கம் வரை கண்ணுக்குத் தெரியாமல் இருக்கிறது.
கொள்கையைத் தொடுவதற்கு முன் திரும்பும் பாதையைத் தயாரிக்கவும்
முதல் மாற்றத்திற்கு முன் நான்கு விஷயங்களை எழுதுங்கள்: சுரங்கப்பாதை இறந்தால் சாதனத்தை எப்படி அடைவீர்கள், எடுத்துக்காட்டாக தொடர் பணியகம், வழங்குநர் பணியகம் அல்லது LAN-இல் உள்ள இயந்திரம்; தற்போதைய உள்ளமைவு எங்கு ஏற்றுமதி செய்யப்படுகிறது; நீங்கள் மாற்றப்போகும் ஒரே விதி அல்லது பாதை; அந்த உருப்படியைச் சரியாக எப்படித் திருப்பிக் கொடுப்பீர்கள். OpenWrt-இல் sysupgrade -b /tmp/backup.tar.gz உள்ளமைவைப் பிடிக்கிறது, திருத்தங்கள் uci commit வரை நிலுவையில் இருக்கும், சரியான நேரத்தில் கவனித்தால் மலிவான மீளமைப்பைத் தருகிறது. pfSense உள்ளமைவு வரலாற்றை வைத்திருக்கிறது, AutoConfigBackup முன்பே இயக்கப்பட்டிருந்தால் மட்டுமே உதவும். ரவுட்டர் fail-closed விதித் தொகுப்பை இயக்கினால், நீங்கள் திட்டமிட்ட பராமரிப்புப் பாதை அந்த விதி தடுக்கும் போக்குவரத்திற்குள் இல்லை என்பதை உறுதிப்படுத்துங்கள், மறுதொடக்கம் நிலையான விதிகளை அழிப்பதற்குப் பதிலாக மீண்டும் பயன்படுத்துகிறது என்பதை நினைவில் வையுங்கள்.
ஒவ்வொரு முயற்சியிலும் ஒரு எல்லையை மாற்றுங்கள், பின்னர் திறந்து வைத்திருக்கும் ஷெல்லுக்குப் பதிலாக புதிய இணைப்பிலிருந்து சோதியுங்கள். சோதனை தோல்வியடைந்தால் அடுத்த அடுக்கைத் தொடுவதற்கு முன் அந்த ஒரு மாற்றத்தைத் திருப்புங்கள். சுரங்கப்பாதை எப்போதும் மேலே இருக்கலாம், ஆனால் அதன் பச்சை நிலைச் சின்னம் நீங்கள் இன்னும் உள்ளே செல்ல முடியும் என்பதற்கான சான்று அல்ல.
புறப்படுவதற்கு முன் விரைவான சரிபார்ப்பு:
- நீங்கள் இப்போது திருத்திய விதியைச் சார்ந்திராத மூலத்திலிருந்து ரவுட்டரை அடைய முடியுமா?
- சுரங்கப்பாதை இடைமுகத்தின் உள்ளீட்டுக் கொள்கை நிர்வாகியின் மூலத்தை மட்டும் அனுமதிக்கிறதா?
- நிர்வாகச் சேவை சுரங்கப்பாதையில் உள்ள முகவரியில் பிணைந்துள்ளதா?
- ஒரு மறுக்கப்பட்ட இணை மற்றும் ஒரு புதிய அமர்வைச் சோதித்தீர்களா?
- WAN நிர்வாக மேற்பரப்பு இன்னும் மூடப்பட்டுள்ளதா?