nginx உடைவதற்கு முன் OpenVPN SNAT விதியின் எல்லையை நிர்ணயிக்கவும்

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

கொள்கலன் tun சாதனத்தை உருவாக்க முடியுமா என்பதை உறுதிப்படுத்தவும்

சுரங்கப்பாதை இடைமுகம் இருக்க முடியாதென்றால் வேறு எதுவும் முக்கியமல்ல. /dev/net/tun உள்ளதா மற்றும் சோதனைச் சாதனம் உருவாக்குவது வெற்றியடைகிறதா என்பதைச் சரிபார்க்கவும், ஏனெனில் பல வழங்குநர்கள் கொள்கலன்களுக்குள் tun ஐ இயல்பாக முடக்குகிறார்கள். ஒருபோதும் உருவாக்கப்படாத சாதனத்திற்கு எந்த firewall வேலையும் ஈடு செய்யாது.

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

இந்த இடைமுகத்தில் MASQUERADE என்ன செய்கிறது என்பதைத் தீர்மானிக்கவும்

சாதாரண மெய்நிகர் இயந்திரத்தில் வழக்கமான வெளியேற்ற விதி பிரதான இடைமுகத்திலிருந்து POSTROUTING MASQUERADE ஆகும். OpenVZ கொள்கலனில் தெரியும் சாதனம் பெரும்பாலும் venet0, அதாவது புரவலனால் நிர்வகிக்கப்படும் மெய்நிகர் இடைமுகம், வழிமாற்றப்பட்ட NIC அல்ல, மேலும் MASQUERADE அங்கு பயிற்சிக் குறிப்புகள் கருதுவது போல எப்போதும் நடந்துகொள்வதில்லை.

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

iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

விதியை ஒரு pool மற்றும் ஒரு இடைமுகத்திற்கு வரம்பிடவும்

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

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

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

விதிகளை நிரந்தரமாக்கி அவற்றை வேறு யார் வைத்திருக்கிறார்கள் என்பதைக் கண்டறியவும்

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

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

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

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

சேவையகத்தில் iptables -t nat -L -v -n பயன்படுத்தி NAT மற்றும் FORWARD விதிகளின் பாக்கெட் எண்ணிகளைப் படித்து, ஒரு பிடிப்பில் ஒரு ஓட்டத்தைக் கவனிக்கவும். பிடிப்பில் வாடிக்கையாளரின் முகவரி தோன்றி பதில் வரவில்லை என்றால், இடைவெளி திரும்பும் பாதையில் அல்லது வழங்குநரின் வடிகட்டலில் உள்ளது, வாடிக்கையாளர் சுயவிவரத்தில் அல்ல. பிடிபட்ட மூலத்தை விதி மொழிபெயர்க்கும் முகவரியுடன் ஒப்பிடவும், ஏனெனில் பொருந்தாமை என்பது வேறொரு விதி முதலில் பொருந்தியது என்பதாகும். ஒரு கவனிக்கப்பட்ட ஓட்டம் ஒரு பக்க உள்ளமைவுப் படிப்பை விட அதிகத்தைத் தீர்மானிக்கிறது.

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