ஒரு OpenVPN கிளையண்ட் SSH வழியாக மற்றொன்றை அடைய அனுமதிக்கவும், குளத்தைத் திறக்காமல்

ஒரு கிளையண்ட் மற்றொரு கிளையண்டின் SSH சேவையை அடைய வேண்டும், குளத்தின் மீதிப் பகுதி இன்று இருப்பதைப் போலவே தனிமைப்படுத்தப்பட்டிருக்க வேண்டும். கவர்ச்சிகரமான சுவிட்ச் client-to-client ஆகும், இது அனைவருக்கும் ஒரே நேரத்தில் சக-அணுகலை இயக்கி, முடிவை கர்னலுக்குப் பதிலாக OpenVPN-க்கு அளிக்கிறது. குறுகிய பதில் அந்த சுவிட்சை அணைத்து வைத்து, சேவையகத்தின் சொந்த வழித்தடம் மற்றும் தீச்சுவரை சரியாக ஒரு ஓட்டத்தைச் சுமக்க அனுமதிக்கிறது.

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

client-to-client பாக்கெட்டை எங்கு நகர்த்துகிறது

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

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

சகாவின் பாக்கெட் உண்மையில் செல்லும் பாதை

Linux Community OpenVPN 2.6 சேவை, DCO-க்குப் பதிலாக பயனர் இடத்தில் TUN செயலாக்கம், சப்நெட் இடவியல், tun0, மற்றும் கிளையண்ட் A 10.44.0.21-இலும் கிளையண்ட் B 10.44.0.37-இலும் உள்ள 10.44.0.0/24 குளம் என வைத்துக்கொள்ளுங்கள். சப்நெட் இடவியலில் A பெற்ற முகவரியும் நெட்மாஸ்க்கும் ஏற்கனவே குளத்தை மூடுகின்றன, எனவே A கூடுதல் தள்ளப்பட்ட வழித்தடம் இல்லாமல் பாக்கெட்டை சுரங்கச் சாதனத்திற்கு அனுப்புகிறது. A-வில் உண்மையான வழித்தடத்தைச் சரிபார்க்கவும், ஊகிக்க வேண்டாம்.

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

சேவையகத்தில் இரண்டு விதிகள், இந்த வரிசையில்

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

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o tun0 -s 10.44.0.21 -d 10.44.0.37 -p tcp --dport 22 -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -j DROP

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

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

B இன்னும் எதை அனுமதிக்க வேண்டும்

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

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

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