NAT-க்குப் பின்னால் உள்ள OpenVPN கிளையண்ட் எவ்வாறு இணைய வெளியேற்றமாகிறது
வெளியேற்றம் தானே வெளியே அழைக்கிறது, எனவே அதன் ரவுட்டருக்கு எந்த உள்வரும் போர்ட்டும் தேவையில்லை. ஹப் எதை ரூட் செய்கிறது, வெளியேற்றம் எதை அனுப்புகிறது, திரும்பும் பாதை எங்கிருந்து வருகிறது என்பதைப் பின்தொடருங்கள்.
மூன்று Linux ஹோஸ்ட்கள், ஒரு வடிவமைப்பு: பொதுவில் அணுகக்கூடிய OpenVPN ஹப், ஒரு மடிக்கணினி மற்றும் உள்ளே எதையும் அனுப்பாத சாதாரண வீட்டு ரவுட்டருக்குப் பின்னால் இருக்கும் வெளியேற்ற இயந்திரம். வெளியேற்றம் தானே ஹப்பை அழைக்கிறது. பின்னர் நுகர்வோரின் இணைய டிராஃபிக் மடிக்கணினியில் சுரங்கப்பாதைக்குள் நுழைந்து வெளியேற்றத்தின் சொந்த மேல்நிலை இணைப்பு வழியாக வெளியேறுகிறது. இந்த ஏற்பாட்டில் ஆச்சரியமான அனைத்தும் ஒரு விவரத்திலிருந்து வருகிறது: இணைப்பைத் தொடங்கியது வெளியேற்றமே, எனவே உள்ளே செல்லும் பாதை ஏற்கனவே உள்ளது, அதை உருவாக்க போர்ட் பார்வர்டிங் தேவையில்லை.
பின்வருவது கட்டமைப்பின் வரிசையை அல்ல, பாக்கெட்டின் பாதையைப் பின்தொடர்கிறது, ஏனெனில் எந்தக் கூறு எந்த முடிவை எடுக்கிறது என்று தெரிந்த பிறகே கட்டமைப்புக்கு அர்த்தம் உண்டு. ஒவ்வொரு அடுக்கும் சரியாக ஒரு முடிவை எடுக்கிறது, இரண்டு அடுக்குகள் ஒன்றாகக் கருதப்படும் இடத்தில் பிழைகள் குவிகின்றன.
இரண்டு போக்குவரத்து அமர்வுகள், ஒரு உள் பாதை
ஒவ்வொரு ஹோஸ்டும் ஹப்புடன் தனது சொந்த வெளிப்புற இணைப்பை வைத்திருக்கிறது, அவற்றில் எதுவும் மற்றொன்றைப் பற்றி அறியாது. நுகர்வோரின் இணைய நோக்கிய டிராஃபிக் ஒரு தனி உள் ஓட்டம், அது நுகர்வோரின் சுரங்கப்பாதைக்குள் எடுத்துச் செல்லப்பட்டு பின்னர் வெளியேற்றத்தின் சுரங்கப்பாதையிலிருந்து மீண்டும் வெளியிடப்படுகிறது. ஹப் இந்த உள் ஓட்டத்தையே ரூட் செய்ய வேண்டும், வெளியேற்றம் அதையே அனுப்ப வேண்டும்.
outer: consumer --TLS--> hub
outer: exit --TLS--> hub
inner: consumer --tun--> hub --internal--> exit --tun--> uplink
இரண்டு வெளிப்புற இணைப்புகளும் கிளையண்ட் பக்கத்திலிருந்து வெளியே செல்வதால், வெளியேற்றத்தின் ரவுட்டர் ஒருபோதும் உள்வரும் SYN பார்ப்பதில்லை, ஒருபோதும் இலக்கு NAT விதி தேவைப்படுவதில்லை. நிறுவப்பட்ட போக்குவரத்தை உயிரோடு வைத்திருக்க மட்டுமே வேண்டும், எந்த நீண்ட இணைப்புக்கும் அதை ஏற்கனவே செய்கிறது. பொது இணையத்தில் எதுவும் முதலில் வெளியேற்றத்தை அடைய வேண்டியதில்லை, அதனால்தான் அந்த மேல்நிலை இணைப்பில் மாறும் முகவரி பிரச்சினையல்ல. ரவுட்டர் வெளிச்செல்லும் அமர்வை அனுமதிக்க வேண்டும், ஆனால் அது உலாவி ஏற்கனவே பயன்படுத்தும் அதே அனுமதி.
iroute சேவையகத்தின் உள்ளே உண்மையில் எதை நிறுவுகிறது
எந்தத் துணை எந்த இலக்கைக் கொண்டுள்ளது என்பதைத் தீர்மானிக்கும் ஒரே சாதனம் ஹப் மட்டுமே, அந்த முடிவை அது கர்னலில் அல்ல, தனது சொந்த பயனர் இடைவெளி ரூட்டிங் அட்டவணையில் எடுக்கிறது. வெளியேற்றத்திற்கான exit-node எனப்படும் client-config-dir உள்ளீடு அங்கு இயல்புநிலை முன்னொட்டைக் கோரலாம்:
# /etc/openvpn/server/ccd/exit-node
iroute 0.0.0.0 0.0.0.0
அந்த வரி சேவையக செயல்முறையிடம் "எந்த இலக்கையும் கொண்ட உள் பாக்கெட்டுகள் இந்தக் கிளையண்டுக்குரியவை" என்று கூறுகிறது. அது ஹப்பின் இயக்க முறைமைக்கு இயல்புநிலை பாதையைச் சேர்ப்பதில்லை, ஹப்பை இணைய நுழைவாயிலாகவும் ஆக்குவதில்லை. OpenVPN 2.6 குறிப்பு கிளையண்டுக்குரிய உள் ரூட்டிங்கையும் கர்னல் ரூட்டிங்கையும் தனித்தனி முறைகளாக வைத்திருக்கிறது, இந்தப் பிரிவே இந்த வடிவமைப்பு ஹப்பின் இயல்புநிலை பாதையைத் தொடாமல் செயல்படுவதற்கான காரணம்.
நுகர்வோருக்கு கண்ணாடிப் போன்ற அறிவுறுத்தல் தேவை, push ஆக வழங்கப்படுகிறது, அதனால் அவர்களின் சொந்த டிராஃபிக் உள்ளூர் நுழைவாயில் வழியாக வெளியேறுவதற்குப் பதிலாக சுரங்கப்பாதைக்குள் நுழையும். துணை வலை இடவியலில் குளம் வெளியேற்றத்தின் tun சாதனத்தில் இணைக்கப்பட்ட பாதையாகும், எனவே திரும்பும் திசைக்கு கூடுதல் push தேவையில்லை; வெளியேற்றம் பெறக்கூடாதது கீழே உள்ள திருப்பிவிடல், அது அதன் சொந்த மேல்நிலை டிராஃபிக்கை அது பயன்படுத்த முயலும் சுரங்கப்பாதைக்குத் திருப்பி அனுப்பும். அதை நுகர்வோருக்கு மட்டும் அனுப்புங்கள், CCD கோப்பு தேர்ந்தெடுக்கப்பட்டது என்று நம்புவதற்குப் பதிலாக கிளையண்டில் பயன்படுத்தப்பட்ட பாதைகளைப் படியுங்கள்.
# /etc/openvpn/server/ccd/consumer-01
push "redirect-gateway def1"
அனுப்புவதை வெளியேற்றத்தின் கர்னல் செய்கிறது
வெளியேற்றத்தின் உள்ளே நுகர்வோரின் பாக்கெட் tun இடைமுகத்தில் ஏதோ ஒரு இணைய ஹோஸ்டின் முகவரிக்கு வருகிறது. கர்னல் தனது ரூட்டிங் அட்டவணையைப் பார்க்கிறது, சிறந்த பொருத்தமாக உண்மையான மேல்நிலை இணைப்பைக் கண்டுபிடித்து, பின்னர் இரண்டு சுயாதீன கொள்கைகளைப் பயன்படுத்துகிறது: இந்தப் பாக்கெட்டை அனுப்பவே முடியுமா, மற்றும் அந்த மூல முகவரியுடன் அந்த இடைமுகத்திலிருந்து வெளியேற முடியுமா. அனுப்புதல் ஒரு sysctl, பல விநியோகங்களில் இயல்பாகவே அணைக்கப்பட்டுள்ளது.
எனவே வெளியேற்றத்திற்கு தொடர்ந்து இயக்கப்பட்ட IPv4 அனுப்புதல், நுகர்வோரின் சுரங்கப்பாதை மூலங்களை மேல்நிலை இணைப்பை நோக்கி அனுமதிக்கும் விதி, மற்றும் tun வழியாகத் திரும்பும் பதில் பாதை தேவை. முழு ஹோஸ்டிற்கும் அனுப்புதலை இயக்குவது அதன் வழியாக ரூட் செய்யப்படும் மற்ற அனைத்தின் நடத்தையையும் மாற்றும், எனவே விதி அனைத்தையும் ஏற்காமல் மூலங்களையும் இடைமுகங்களையும் பெயரிட வேண்டும்.
திரும்பும் பாதையை மூல மொழிபெயர்ப்பு வாங்குகிறது
இணைய ஹோஸ்ட்டுக்கு 10.90.0.x முகவரிக்கு எந்தப் பாதையும் இல்லை, எனவே பதில்கள் வெளியேற்றத்தை அடையும் முன்பே நிராகரிக்கப்படும். பாக்கெட் மேல்நிலை இணைப்பை விட்டு வெளியேறும்போது மூலத்தை மீண்டும் எழுதுவது அதைத் தீர்க்கிறது, இணைப்புக் கண்காணிப்பு திரும்பும் போது அந்த மீளெழுத்தைத் திருப்புகிறது.
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o enp1s0 -j MASQUERADE
ip -4 route get 10.90.0.9 # run on the exit: must point at the tun
மேலே உள்ள விதி ஒரு மேல்நிலை இடைமுகத்திற்கான தொடக்கப் புள்ளி, ஃபயர்வால் கொள்கை அல்ல. மூலத்தை நீங்கள் உண்மையில் அங்கீகரித்த ஒதுக்கீடுகளுக்குச் சுருக்கி, வெளியேற்றத்தின் சொந்த உள்ளீட்டுக் கொள்கையைத் தனியாக வைத்திருங்கள், அதனால் சுரங்கப்பாதை டிராஃபிக்கிற்கான மறைப்பு உள்ளூர் சேவைகளை அமைதியாக வெளிப்படுத்தாது. மாறும் மேல்நிலை முகவரி கொண்ட ஹோஸ்ட்டில், மறைப்பு முகவரியை கைமுறையாகக் கண்காணிப்பதிலிருந்தும் உங்களைக் காப்பாற்றுகிறது.
ஹப் எங்கே நடைமுறைப்படுத்த முடியும், எங்கே முடியாது
client-to-client மற்றும் பாரம்பரிய பயனர் இடைவெளி தரவுப் பாதையுடன், ஹப் சேவையக செயல்முறைக்குள் துணைகளுக்கிடையே உள் பாக்கெட்டுகளை ஒப்படைக்கிறது. அவை ஒருபோதும் ஹப்பின் கர்னல் FORWARD சங்கிலியைக் கடப்பதில்லை, எனவே அங்குள்ள கர்னல் விதி எவ்வளவு கவனமாக எழுதப்பட்டிருந்தாலும் துணைகளுக்கிடையேயான போக்குவரத்தைக் கட்டுப்படுத்த முடியாது. நடைமுறைப்படுத்தல் சேவையகத்தின் சொந்தக் கொள்கையிலேயே இருக்க வேண்டும்: யாருக்கு இணைக்க அனுமதி, எந்த CCD கோப்பு கிடைக்கும், வெளியேற்றத்தின் இயல்புநிலை உரிமை ஏதேனும் வழங்கப்படுகிறதா.
அதனால்தான் இயல்புநிலை iroute ஒரு பரந்த நம்பிக்கை முடிவு. வெளியேற்றம் தன்னிச்சையான இணைய முகவரிகளிலிருந்து திரும்பும் டிராஃபிக்கை சட்டப்பூர்வமாக ஏற்க வேண்டும், அது நீங்கள் கட்டுப்படுத்தும், இணைக்கும், கண்காணிக்கும் இயந்திரமாக இருக்க வேண்டும். அதே உரிமையை நீங்கள் ரவுட்டரை ஒப்படைக்காத துணைக்கு வழங்குவது இந்த வடிவமைப்பு அழைக்கும் தவறு.
உறுப்பினர் தன்மையே உண்மையான கட்டுப்பாடு. தனது சொந்தப் பாதைகளை அமைக்கக்கூடிய எந்தக் கிளையண்டும் வெளியேற்றத்தைப் பயன்படுத்த முயலலாம், எனவே யார் இணைக்கலாம் அல்லது வெளியேற்றம் எந்தத் துணைகளுக்குச் சேவை செய்யும் என்பதைக் கட்டுப்படுத்துவது வடிவமைப்பின் பகுதி, பின்னர் வந்த சிந்தனை அல்ல.
வெளியேற்றம் மறையும்போது பாதுகாப்பாகத் தோல்வியடைதல்
வெளியேற்றத்தை ஆஃப்லைனில் வையுங்கள், உள் இயல்புநிலை உரிமை அதன் அமர்வுடன் மறைந்துவிடும். நடக்கக்கூடாதது என்னவென்றால் ஹப் அமைதியாக மாற்று வெளியேற்றமாக மாறுவது: VPN குளத்திலிருந்து ஹப்பின் மேல்நிலை இணைப்புக்கு எந்த இயல்புநிலை பாதையும் இல்லை, ஹப்பில் அதே டிராஃபிக்கை மகிழ்ச்சியுடன் அனுப்பும் பரந்த மறைப்பு விதியும் இல்லை. அந்தத் தோல்வியை வேண்டுமென்றே சோதியுங்கள், பின்னர் ஏற்கனவே திறந்திருந்த பக்கத்திற்குப் பதிலாக புதிய ஓட்டத்துடன் மீட்பைச் சோதியுங்கள்.
# on the consumer, with the exit up and then down
ip -4 route get 1.1.1.1
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com
வெளியேற்றம் சென்ற பிறகும் நுகர்வோரின் டிராஃபிக் இணையத்தை அடைந்தால், வேறு ஏதோ அதை எடுத்துச் செல்கிறது, நீங்கள் கருதிய எல்லை இல்லை. DNS மற்றும் IPv6 ஆகியவற்றையும் தனி முடிவுகளாகக் கருதுங்கள்: IPv4 பாதையும் மறைப்பும் AAAA டிராஃபிக் பற்றி எதுவும் கூறுவதில்லை, ஹப் தள்ளும் தீர்வி வினா உண்மையில் எங்கிருந்து வெளியேறுகிறதோ அங்கிருந்து பதிலளிக்கும்.