OpenWrt VPN மண்டலம், அனுப்புதல் மற்றும் மறைத்தல்: எது தேவை?
மண்டல உள்ளீடு, அனுப்புதல் மற்றும் மறைத்தல் வெவ்வேறு கேள்விகளுக்கு பதிலளிக்கின்றன. WAN மண்டலத்தைத் திறக்கும் முன் உங்கள் VPN போக்குவரத்துக்கு எது தேவை என்பதை முடிவு செய்யுங்கள்.
VPN ஒரு OpenWrt-ஐ சந்திக்கும் ஒவ்வொரு முறையும் மூன்று மாற்றங்கள் கலக்கின்றன: ஒரு துறையைத் திறப்பது, அனுப்புதலுக்கு அனுமதி அளிப்பது மற்றும் மறைத்தலை இயக்குவது. அவை வெவ்வேறு கேள்விகளுக்கு பதிலளிக்கின்றன, பொதுவாக அவற்றில் ஒன்று மட்டுமே உண்மையான தேவை. ஒவ்வொரு கட்டுப்பாட்டையும் அது நிர்வகிக்கும் போக்குவரத்து பங்கின் அடிப்படையில் படிப்பது ஊகத்தை முடிவாக மாற்றுகிறது, மாற்றம் தவறாக இருக்கும்போது எந்த அறிகுறியை எதிர்பார்க்க வேண்டும் என்பதையும் கூறுகிறது. நீங்கள் நினைவில் வைத்திருக்கும் தேர்வுப்பெட்டியை அல்ல, தோல்வியடைந்த பங்கை பெயரிட்டு தொடங்குங்கள்.
ஒரு கட்டுப்பாட்டைத் தொடுவதற்கு முன் போக்குவரத்து பங்கை பெயரிடுங்கள்
மண்டல உள்ளீடு ரவுட்டரையே எது அடையலாம் என்பதை தீர்மானிக்கிறது. மண்டல வெளியீடு ரவுட்டர் தானே உருவாக்கும் போக்குவரத்தை உள்ளடக்குகிறது, மண்டல அனுப்புதல் ஒரு மண்டலத்தைக் கடக்கும் போக்குவரத்துக்கான இயல்புநிலை மதிப்பு, மறைத்தல் வெளியே செல்லும்போது மூல முகவரி மீண்டும் எழுதப்படுமா என்பதை தீர்மானிக்கிறது. இவை நான்கு வெவ்வேறு கேள்விகள், ஒரு மண்டலக் கொள்கை ஒரே மதிப்புடன் நான்கிற்கும் ஒரே நேரத்தில் பதிலளிக்கிறது, எனவே முழு மண்டலத்திலும் மாற்றம் ஒரு முரட்டுத்தனமான கருவி. பெயரிடப்பட்ட விதி மற்றவற்றைத் தொடாமல் அவற்றில் ஒன்றுக்கு பதிலளிக்க முடியும்.
பயனுள்ள வரைபடம் போக்குவரத்து பங்கின் அடிப்படையில் உள்ளது, ஏனெனில் ஏதாவது தோல்வியடையும்போது நீங்கள் கவனிக்கக்கூடியது அதுவே. கீழே உள்ள ஒவ்வொரு பங்கிற்கும் அதைத் தீர்மானிக்கும் ஒரு கட்டுப்பாடு மற்றும் அதைச் சுட்டிக்காட்டும் ஒரு அறிகுறி உள்ளது:
| Traffic role | Control that decides it | Where it lives in the config | Symptom when it is wrong |
|---|---|---|---|
| A client reaching a listener on the router | Input policy of the zone that carries the connection, or a rule for the port | option input in the zone stanza, or a named rule | The handshake never completes and the tunnel log says nothing |
| A tunnel client reaching the router itself | Input policy of the tunnel zone | option input in the VPN zone | A ping to the gateway fails |
| A tunnel client reaching another LAN host | Forwarding from the tunnel zone to the LAN zone | config forwarding plus the zone assignment | The gateway answers and the file share times out |
| The router's own traffic leaving the WAN | Output policy, and translation if the far side needs it | option output and option masq | The tunnel never establishes, or replies vanish |
ரவுட்டரில் கேட்கும் சேவைக்கு ஒரு குறுகிய உள்ளீட்டு விதி தேவை
ரவுட்டரில் உள்ள OpenVPN சேவையகம் ரவுட்டருக்கு முகவரியிடப்பட்ட போக்குவரத்தைப் பெறுகிறது, எனவே அதன் வெளிப்புற இணைப்பு அதைச் சுமக்கும் மண்டலத்தின் உள்ளீட்டுக் கொள்கையைப் பொறுத்தது. உள்ளமைக்கப்பட்ட போக்குவரத்து மற்றும் துறையை அனுமதித்து, அந்த மண்டலத்தில் மற்ற அனைத்தையும் நிராகரிக்கப்பட்டதாக விடுங்கள். ஒரு துறை விதி முழு மண்டல அனுமதியை விட மிகச் சிறிய மாற்றம், ஒரு வருடம் கழித்தும் நீங்கள் விளக்கக்கூடியது அதுவே.
அந்த விதியை வைத்திருக்க பாதுகாப்பானதாக்கும் இரண்டு விஷயங்கள் உள்ளன: சேவை உண்மையில் பயன்படுத்தும் துறையை அது பெயரிடுகிறது, மண்டல வரையறைக்கு அருகில் நிற்கிறது, அடுத்த நபர் அது ஏன் உள்ளது என்பதைப் பார்க்க முடியும். கீழே உள்ள வரிகள் வடிவம் மட்டுமே, துறை சேவையகத்தில் உள்ளமைக்கப்பட்டதைக் குறிக்கிறது. சேவை இடம்பெயரும்போது அந்தத் துறையை இரண்டு இடங்களிலும் மாற்றுங்கள், பழையதில் தங்கிய விதி தணிக்கை வரை கண்ணுக்குத் தெரியாது.
config zone
option name 'wan'
option input 'REJECT'
option forward 'REJECT'
option output 'ACCEPT'
option masq '1'
config rule
option name 'allow-openvpn'
option src 'wan'
option proto 'udp'
option dest_port '1194'
option target 'ACCEPT'மீண்டும் ஏற்றுவதற்கு முன் சரிபார்க்கவும், ஏனெனில் ஃபயர்வால் கோப்பில் உள்ள தொடரியல் பிழை ரவுட்டரை வேலை செய்யும் விதித்தொகுப்பு இல்லாமல் விட்டுவிடலாம். fw4 பயன்படுத்தும் வெளியீட்டில் சரிபார்ப்பு தனி கட்டளை, அது உடைந்த தொகுதியை அமைதியாக ஏற்றுக்கொள்வதற்குப் பதிலாக சத்தமாக தோல்வியடைகிறது. சரிபார்ப்பு வெற்றிபெற்ற பிறகே மீண்டும் ஏற்றுங்கள், முந்தைய கோப்பை மீண்டும் வைக்கக்கூடிய இடத்தில் வைத்திருங்கள்.
fw4 check
service firewall reloadவாடிக்கையாளர் கோரிக்கை உள்ளீட்டை அல்ல, அனுப்புதலைக் கடக்கிறது
அங்கீகாரத்திற்குப் பிறகு, LAN சேவையைக் கோரும் சுரங்கப்பாதை வாடிக்கையாளரின் கோரிக்கை அனுப்பப்பட்ட ஓட்டத்தை உருவாக்குகிறது, எனவே அதைத் தீர்மானிக்கும் கட்டுப்பாடு சுரங்கப்பாதை மண்டலத்திற்கும் LAN மண்டலத்திற்கும் இடையிலான அனுப்புதல் உறவு. சுரங்கப்பாதை இடைமுகத்தை விரும்பிய மண்டலத்திற்கு ஒதுக்கி, பின்னர் திசை, மூலங்கள் மற்றும் சேவையை அறிவிக்கவும். மண்டல ஒதுக்கீடே அனுப்புதல் விதிக்கு பொருள் தருகிறது, இரண்டும் ஒன்றாகப் படித்தால் மட்டுமே புரியும். சுரங்கப்பாதை மண்டலத்தை மூலமாகவும் LAN மண்டலத்தை இலக்காகவும் பெயரிடும் அனுப்புதல் உறவு ஒரு வேண்டுமென்றே எடுக்கப்பட்ட முடிவாகப் படிக்கப்படுகிறது, அதேசமயம் முழு மண்டலத்தின் இரண்டு அனுமதிகள் ஒரு விபத்தாகப் படிக்கப்படுகின்றன.
ரவுட்டரையே அடைவது இன்னும் உள்ளீட்டுப் பாதையைப் பயன்படுத்துகிறது, எனவே நுழைவாயிலுக்கு ping அதன் பின்னால் உள்ள கோப்புப் பங்கீடு பற்றி எதுவும் கூறுவதில்லை. அந்த இரண்டு தோல்விகளும் வெவ்வேறு தொகுதிகளில் வாழ்கின்றன, வெவ்வேறு மாற்றங்களால் சரிசெய்யப்படுகின்றன. எதையும் மாற்றுவதற்கு முன் இரண்டு பாதைகளையும் தனித்தனியாக எழுதுங்கள்.
மறைத்தல் ஒரு வழிப்பாதை முடிவு, அனுமதி அல்ல
மறைத்தல் தேர்ந்தெடுக்கப்பட்ட வெளிச்செல்லும் போக்குவரத்தின் மூல முகவரியை மீண்டும் எழுதுகிறது. தொலைப் பக்கத்திற்கு திரும்பும் வழி இல்லாத வெளியேற்ற வடிவமைப்பை அது காப்பாற்றலாம், மேலும் முகவரிகளைப் பதிவு செய்யும் அல்லது முகவரியின் அடிப்படையில் அனுமதிக்கும் எந்தச் சேவையிலிருந்தும் தனிப்பட்ட வாடிக்கையாளர் முகவரிகளை மறைக்கிறது. அதை முடக்குவது திரும்பும் பாதை பற்றிய வழிப்பாதைத் தேர்வு, உள்நோக்கிய துளையை மூடும் பாதுகாப்பு சுவிட்சு அல்ல. மொழிபெயர்ப்பு இயக்கப்பட்டிருந்தால் வேலை செய்து, அது முடக்கப்பட்ட நொடியில் தோல்வியடையும் சுரங்கப்பாதையில் பொதுவாக திரும்பும் பாதை இல்லாமல் இருக்கும், ஃபயர்வால் விதி அல்ல.
வழிப்பாதையிடப்பட்ட மாற்றுக்கு மொழிபெயர்ப்புக்குப் பதிலாக தொலைப் பக்கத்தில் திரும்பும் பாதை தேவை. எந்த விருப்பமும் ஃபயர்வால் அனுமதியையோ பயன்பாட்டுக் கணக்கையோ வழங்குவதில்லை, எனவே மறைத்தலை முடக்குவது எங்கும் செல்ல முடியாத சுரங்கப்பாதை வாடிக்கையாளரை எப்போதும் கிட்டத்தட்ட சரிசெய்வதில்லை. IPv4 மற்றும் IPv6 கொள்கைகளையும் தனித்தனியாகக் கையாளுங்கள், ஏனெனில் ஒரு மொழிபெயர்ப்பு அமைப்பு இரு குடும்பங்களையும் விவரிக்காது.
அனுமதிக்கப்பட்ட மற்றும் நிராகரிக்கப்பட்ட கோரிக்கையால் முடிவை நிரூபியுங்கள்
அனுமதிக்கப்பட வேண்டிய ஒரு கோரிக்கையையும் நிராகரிக்கப்பட வேண்டிய ஒன்றையும் அனுப்பி, பின்னர் ஒவ்வொரு முடிவையும் எடுத்த கட்டுப்பாட்டை அடையாளம் காணுங்கள். தற்செயலாக ஏற்றப்படும் பக்கம் சான்று அல்ல; பொருந்திய விதியே சான்று, அது பொருந்திய சங்கிலியில். நிராகரிப்பு வெற்றியைப் போலவே முக்கியம், ஏனெனில் எல்லாம் அனுமதிக்கப்பட்டதல்ல, கொள்கை ஏதோ செய்கிறது என்பதை அது காட்டுகிறது.
தற்போதைய வெளியீட்டில் இரண்டு கட்டளைகள் அந்தச் சான்றைத் தருகின்றன. கோரிக்கை ஏற்கப்படும்போது பொருந்திய விதியின் கணக்கீடு நகர்கிறது, விதிக்கு பதிவு செய்வதை இயக்கியிருந்தால் பதிவு விழுவதைக் காட்டுகிறது:
nft list chain inet fw4 forward_wan
logread -f | grep -i -E 'DROP|REJECT'எந்த ஃபயர்வால் கொள்கையையும் மாற்றுவதற்கு முன் இன்னும் பயன்படுத்தக்கூடிய நிர்வாகப் பாதையை வைத்திருங்கள், உள்ளமைவின் உரிமையாளரின் சரிபார்ப்பு மற்றும் மீளமைப்பு செயல்முறையைப் பின்பற்றுங்கள். உங்களை ரவுட்டருக்கு வெளியே பூட்டும் மாற்றம் சோதனை முடிவு அல்ல, அது இரண்டாவது சம்பவம். ஒவ்வொரு கவனிப்பின் அருகிலும் மண்டலத்தையும் போக்குவரத்து பங்கையும் பதிவு செய்யுங்கள், இதனால் முடிவுகளின் இணை அதிர்ஷ்டமான பக்க ஏற்றுதலை விவரிக்காமல் கொள்கையை விளக்கும்.