உள்ளூர் Wi-Fi மற்றும் Ethernet வாடிக்கையாளர்கள் Pi இன் ஹாட்ஸ்பாட்டுடன் இணைந்து, அதன் DHCP வரம்பிலிருந்து முகவரியைப் பெற்று, புகார் இல்லாமல் இணையப் பக்கங்களை ஏற்றுகிறார்கள். பின்னர் அதே வாடிக்கையாளர்கள் வீட்டு LAN இல் கோப்புப் பங்கீடு அல்லது வலை இடைமுகத்தைத் திறக்கும்போது நேரம் முடிந்துவிடுகிறது; அதேசமயம் Pi தானே சுரங்கம் வழியாக அந்த LAN ஐ அடைகிறது. வயர்லெஸ் அடுக்கில் எதுவும் உடைந்துவிடவில்லை. குறைவாக இருப்பது வழிமாற்றப்பட்ட ஒப்பந்தம்: ஹாட்ஸ்பாட் முன்னொட்டு TUN இடைமுகத்திற்குள் எடுத்துச் செல்லப்பட வேண்டும், மேலும் வீட்டுப் பக்கம் ஏதாவது பதில்களை அங்கே எப்படித் திருப்பி அனுப்புவது என்று தெரிந்திருக்க வேண்டும். ஒரு பாக்கெட் பயணத்தை முடிக்க இரண்டு பகுதிகளும் இருக்க வேண்டும்.

மூன்று வெவ்வேறு வேலைகளைக் கொண்ட மூன்று இணைப்புகள்

Linux Ethernet பாலம் இலக்கு MAC முகவரியின்படி பிரேம்களை அனுப்புகிறது. OpenVPN TUN பயன்முறையில் IP பாக்கெட்டுகளை எடுத்துச் செல்கிறது, MAC அடுக்கே இல்லை, எனவே உள்ளூர் பாலம் சேர்த்தால் சுரங்கம் ஒருபோதும் துறையாகப் பதிவாகாது. கர்னல் TUN/TAP ஆவணங்கள் அந்தப் பிரிவை விளக்குகின்றன: TAP சாதனம் Ethernet இடைமுகம் போலத் தெரிகிறது, TUN சாதனம் அப்படித் தெரியாது. இரண்டு உள்ளூர் துறைகளைப் பாலமிட்டு பின்னர் வழிமாற்றும் வடிவமைப்பு, இடைமுகங்களின் பெயர்கள் என்ன சொன்னாலும், ஒரு வழிமாற்றி.

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

மோடத்தையும் வாடிக்கையாளர் பாலத்திற்கு வெளியே வைத்திருங்கள். PPP இணைப்பு வேறு லேபிளுடன் கூடிய Ethernet சாதனம் அல்ல, மேலும் pppd இன் ஆவணப்படுத்தப்பட்ட இயல்புநிலை வழி தர்க்கம் IPCP பேச்சுவார்த்தைக்குப் பிறகு இயங்கி, அந்த இணைப்பு விழும்போது அதன் வழியைத் திரும்பப் பெறுகிறது. DHCP வார்ப்புருவை நகலெடுத்து ஒவ்வொரு usb0 ஐயும் ppp0 என மறுபெயரிடுவது நுழைவாயில், அளவீடு அல்லது வாழ்க்கைச் சுழற்சி பற்றி எதையும் நிரூபிக்காது.

எந்தக் கட்டமைப்பையும் திருத்தும் முன் முன்னொட்டுகளைத் தேர்ந்தெடுக்கவும்

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

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

முதல் குளம், இயக்குபவர் மோடத்திற்குக் கொடுத்த underlay முகவரி; அது வாடிக்கையாளர்களை நோக்கிய எந்தத் திட்டத்திற்கும் வெளியே இருக்க வேண்டும். இரண்டாவது, சேவையகம் தேர்ந்தெடுத்த சுரங்கத் துணை வலை, பெரும்பாலும் அதன் சொந்த தனியார் /24 வலை. மூன்றாவது ஹாட்ஸ்பாட் பாலம், நான்காவது நீங்கள் அடைய விரும்பும் வீட்டு முன்னொட்டு. இந்தப் பயணத்தில் ஹாட்ஸ்பாட்டிற்கு 172.28.90.0/24 கிடைக்கிறது, பாலம் 172.28.90.1 இல் உள்ளது, மேலும் வீட்டு சேவை LAN 192.168.77.0/24 ஐத் தக்கவைக்கிறது, இது நுகர்வோர் வழிமாற்றிகளுடன் வரும் 192.168.1.0/24 மற்றும் 10.0.0.0/24 இயல்புநிலைகளையும் 100.64.0.0/10 இயக்குபவர் வரம்பையும் தவிர்க்கிறது.

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

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

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

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

ip route get இன்னும் underlay இடைமுகத்தைப் புகாரளித்தால், அங்கேயே நிறுத்துங்கள்; பாதையில் மேலே எதுவும் தவறான தேடலைச் சரிசெய்ய முடியாது.

வீட்டுச் சாதனங்களுக்கு 172.28.90.0/24 க்கு வழி இல்லை, எனவே அவற்றின் பதில்கள் இயல்புநிலை நுழைவாயிலைப் பின்பற்றி வழிமாற்றியில் இறந்துவிடுகின்றன. இரண்டு ஆதரவு பெற்ற பழுதுகள் உள்ளன. ஒன்று, வீட்டு வழிமாற்றியில் ஹாட்ஸ்பாட் முன்னொட்டை VPN சேவையகத்தின் LAN முகவரிக்கு இயக்கும் நிலையான வழியைச் சேர்க்கவும்; அல்லது, சேவையகமே நுழைவாயிலாக இருக்கும்போது, வாடிக்கையாளர் முன்னொட்டை சேவையகத்தின் சொந்த வழிமாற்றல் அட்டவணையில் பதிவு செய்யவும். OpenVPN இன் பல-வாடிக்கையாளர் பயன்முறையில் வாடிக்கையாளர்-குறிப்பிட்ட கோப்பகம் அந்தத் தொடர்பைக் கொண்டுள்ளது: வாடிக்கையாளர் சான்றிதழின் பொதுப் பெயரால் பெயரிடப்பட்ட கோப்பு, அதில் iroute 172.28.90.0 255.255.255.0 மற்றும் அதை சேவையகக் கர்னலில் நிறுவும் பொருந்தும் route வரி உள்ளன. சேவையகத்தில் ஊகிக்கப்பட்ட கர்னல் வழி, எந்த வாடிக்கையாளர் முன்னொட்டை உடையவர் என்று சேவையகத்திற்குச் சொல்வதற்குச் சமமான கூற்று அல்ல.

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

ஃபயர்வாலை ஊகிக்காமல் அனுப்புதலைத் திறக்கவும்

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

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

br0 இலிருந்து tun0 வரை ஏற்பு விதியையும் பொருந்தும் பதில் திசையையும், மூலத்தை மீண்டும் எழுதக்கூடிய postrouting விதியையும் தேடுங்கள். சங்கிலிக் கொள்கை drop ஆக இருந்து எந்த விதியும் பொருந்தவில்லை என்றால், கொள்கையை accept ஆகத் திருப்புவதற்குப் பதிலாக குறுகிய ஏற்புகளைச் சேர்த்து மீண்டும் சோதிக்கவும்.

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

பயணத்தைச் சரிபார்த்து, பின்னர் வேண்டுமென்றே உடையுங்கள்

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

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

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

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

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

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