இரண்டு OpenVPN சேவையகங்களில் உள்ள வாடிக்கையாளர்கள் ஒருவரையொருவர் அடைய முடியுமா?

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

கட்டுக்கதை: ஒரு கணக்கு பட்டியல், ஒரு நெட்வொர்க்

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

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

ஒவ்வொரு நுழைவாயிலுக்கும் அதன் சொந்த தொகுப்பையும் கடத்தல் முகவரியையும் கொடுங்கள்

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

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

இரு பக்கங்களிலும் வழித்தடத்தை நிறுவுங்கள்

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

sysctl net.ipv4.ip_forward
ip route add 10.64.20.0/24 via 172.28.44.2 dev transit0
ip route get 10.64.20.37

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

உரிமையைப் போலியாகக் காட்டாமல் வாடிக்கையாளர் வழித்தடத்தைத் தள்ளுங்கள்

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

push "route 10.64.20.0 255.255.255.0"

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

ஒரு கோரிக்கையை நிரூபித்து மற்றொன்றை மறுக்கவும்

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

iptables -A FORWARD -i tun0 -o transit0 -s 10.64.10.21 -d 10.64.20.37 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i transit0 -o tun0 -d 10.64.10.21 -s 10.64.20.37 -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

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

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