VPN மட்டுமே உள்ள iptables ஹோஸ்ட்: tun சாதனத்தைப் பெயரிடுங்கள், tun+ அல்ல

tun+ இயந்திரத்தின் ஒவ்வொரு சுரங்கப்பாதையுடனும் பொருந்தும். ஒரு சாதனப் பெயரை நிலைநிறுத்துங்கள், endpoint விலக்கை முதலில் வைத்து, கொள்கையைச் சோதிக்கும்போது மீட்டெடுப்புப் பாதையை வைத்திருங்கள்.

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

படி 1: இப்போது உள்ள விதிகளைப் பதிவு செய்யுங்கள்

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

பின்னர் இடைமுகங்களைப் பட்டியலிடுங்கள், ஏனெனில் நீங்கள் கருதிய பெயர் நீங்கள் படித்திருக்க வேண்டிய பெயர்: ip -br link இப்போது என்ன இருக்கிறது என்பதைக் காட்டுகிறது, சுரங்கப்பாதை மேலே வரும் வரை தெரியாது. படிக்கும்போதே சாதனங்களின் பெயர்களை எழுதிக்கொள்ளுங்கள்.

படி 2: சுரங்கப்பாதைக்கு அதன் சொந்தப் பெயரைக் கொடுங்கள்

OpenVPN கிளையண்ட் உள்ளமைவில் dev tun_work ஏற்கிறது, பின்னர் Linux tun0 ஒதுக்குவதற்குப் பதிலாக அதே பெயரில் இடைமுகத்தை உருவாக்குகிறது. வேறு எதுவும் அதைக் கோராத வரை மறுஇணைப்புகளுக்கு இடையில் பெயர் நிலையாக இருக்கும், சாதனத்தைப் பெயரிடும் விதியை அர்த்தமுள்ளதாக்குவது அதுவே.

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

படி 3: endpoint விலக்கை முதலில் வைத்துக் கொள்கையை எழுதுங்கள்

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

# allow the tunnel to be built, then everything the tunnel carries
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -o tun_work -j ACCEPT
iptables -A INPUT  -i tun_work -j ACCEPT
iptables -A INPUT  -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

endpoint இன் நேரடி முகவரியும் துறையும் உங்கள் வழங்குநருக்குச் சொந்தம், இந்தப் பக்கத்துக்கல்ல. endpoint ஒரு ஹோஸ்ட்பெயராக இருந்தால், ஒருமுறை தீர்த்து முடிவை நிலைநிறுத்துங்கள், ஏனெனில் ஒரு விதியால் பெயரைத் தேட முடியாது, சுழலும் பதில் அடுத்த DNS மாற்றத்துக்குப் பின் கொள்கையை அமைதியாக உடைக்கும். துறையையும் சரிபாருங்கள், ஏனெனில் உங்களை TCP 443 க்கு நகர்த்தும் வழங்குநர்களுக்கு இல்லாவிட்டால் யாரும் எழுதாத ஒரு விதி தேவைப்படும். ஒரே நெறிமுறையில் மட்டும் இயங்கும் சுரங்கப்பாதை பொதுவாக இந்த விடுபடலே, ஃபயர்வால் குறைபாடு அல்ல.

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

படி 4: இருப்பை மட்டுமல்ல, வரிசையையும் சரிபாருங்கள்

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

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

படி 5: தொடக்கம் மற்றும் முகவரிக் குடும்பம் இரண்டையும் தாண்டி நிலைக்கச் செய்யுங்கள்

கையால் உள்ளிட்ட விதிகள் மறுதொடக்கத்தில் மறைந்துவிடும், எனவே விநியோகத்தின் ஃபயர்வால் சேவையிலிருந்தோ சுரங்கப்பாதை இடைமுகம் இருந்த பின் இயங்கும் unit இலிருந்தோ அவற்றை ஏற்றுங்கள். OpenVPN தொடங்கும் முன் இயங்கும் ஸ்கிரிப்டில் tun_work ஐக் குறிப்பிடுவது விழுந்த டிராஃபிக்கின் தொடக்கச் சுழற்சியை உருவாக்கும் பொதுவான வழி.

பின்னர் IPv6 ஐத் தனியாகச் சரிபாருங்கள், ஏனெனில் IPv4 க்கான நல்ல இயல்புநிலை-மறுப்புக் கொள்கை மற்ற குடும்பத்தைப் பற்றி எதுவும் சொல்லாது. IPv4 மட்டும் கையாளும் சுரங்கப்பாதையைச் சுற்றி டிராஃபிக்கைக் கொண்டு செல்லக்கூடிய பாதை ஹோஸ்டுக்கு உள்ளதா என ip -6 route சொல்லும், ip6tables அல்லது nftables க்கு அதற்கு இணையான விதிகள் தேவை. விதித்தொகுப்பின் சமச்சீர்மையை நம்புவதற்குப் பதிலாக IPv6-only இலக்குடன் சோதியுங்கள்.

படி 6: சரிபார்த்து மீட்டெடுக்கத் தயாராக இருங்கள்

சுரங்கப்பாதையை மேலேற்றுங்கள், நீங்கள் நோக்கும் சேவை இயங்குகிறதா என உறுதிசெய்யுங்கள், பின்னர் கொள்கை மறுக்க வேண்டிய ஒன்றை முயற்சியுங்கள். பதில் உங்களை ஆச்சரியப்படுத்தினால் iptables-restore < /root/iptables.pre மூலம் மீட்டெடுங்கள், அதன் பின்னரே விதிகளைத் திருத்தத் தொடங்குங்கள். நிலைத்தன்மையும் சோதிக்கப்பட்ட மீட்டெடுப்புப் பாதையும் சேர்ந்தே இதை நீங்கள் இருமுறை செய்யக்கூடிய மாற்றமாக்குகின்றன.

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