VPN பின்னால் உள்ள சேவைக்கு ufw allow 443 எதுவும் செய்யவில்லை

VPN கிளையண்டிலிருந்து ping வெற்றியடைகிறது, TCP சேவை நேரம் முடிந்துவிடுகிறது, மேலும் ufw allow 443/tcp எதையும் மாற்றவில்லை. பயன்பாடு நுழைவாயிலிலேயே அல்லாமல் நுழைவாயிலுக்குப் பின்னால் உள்ள ஹோஸ்ட்டில் இயங்கும்போது, அந்த அனுமதி தவறான போக்குவரத்து பாதைக்கு எழுதப்பட்டது. தொகுப்பு ஃபயர்வாலுக்கு முகவரியிடப்படவில்லை, உள்ளூர் செயல்முறைக்கு வழங்கப்படவும் இல்லை, எனவே உள்ளீட்டு விதிகள் அதை ஒருபோதும் பார்ப்பதில்லை. தீர்வு முன்னனுப்பப்படும் ஓட்டத்தை இலக்காகக் கொண்ட வழி விதி, அதற்கான ஆதாரம் ஏற்கனவே பதிவில் உள்ளது.

இலக்கு உள்ளூரா அல்லது முன்னனுப்பப்பட்டதா என்பதைத் தீர்மானியுங்கள்

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

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

எந்த விதியையும் சேர்ப்பதற்கு முன் தொகுதியைப் படியுங்கள்

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

sudo dmesg | grep "UFW BLOCK" | tail -n 5
sudo ufw status numbered

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

பொருந்தும் மிகக் குறுகிய வழி விதியை எழுதுங்கள்

இந்த எடுத்துக்காட்டில் வாடிக்கையாளர்கள் 172.20.8.0/24 இலிருந்து tun0 க்கு வருகிறார்கள், சேவை 8443 துறையில் 10.30.0.15 இல் கேட்கிறது, மேலும் நுழைவாயில் ens5 வழியாக வெளியேறுகிறது. அந்த மதிப்புகள் மேக VPC இன் இயல்புநிலை 10.0.0.0/16 அல்லது வீட்டு 192.168.0.0/16 போல ஒருபோதும் தோன்றாதிருக்கத் தேர்ந்தெடுக்கப்பட்டன, மேலும் 8443 எடுத்துக்காட்டை நுழைவாயிலின் சொந்த 443 கேட்பவரிடமிருந்து விலக்கி வைக்கிறது.

sudo ufw --dry-run route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443

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

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

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

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

sudo ufw route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443
sudo ufw status numbered

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

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

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

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

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