டனல் உயர்ந்தவுடன் UFW VPN இன் DNS சேவையகத்தை விட்டுவிடுகிறது
UFW இன் இயல்புநிலை மறுப்புக் கொள்கை டனலின் இடைமுகத்தையும் மூடுகிறது. போக்குவரத்தைத் திசையின்படி வரிசைப்படுத்தி, tun0 இல் தள்ளப்பட்ட resolver ஐ அனுமதித்து, பின்னர் வெளிப்பாதையைத் திறக்கவும்.
VPN இணைந்த நொடியே பெயர்கள் தீர்க்கப்படுவது நிற்கிறது, அதே நேரம் பொது முகவரிக்கான ping இன்னும் பதிலளிக்கிறது மற்றும் firewall நிலையில் தவறாகத் தெரியும் எதுவும் இல்லை. கொள்கையில் எதுவும் மாறவில்லை; மாறியது புதிய இடைமுகம் தோன்றியதுதான், மேலும் இயல்புநிலை மறுப்பு முதல் பொதியிலிருந்தே அதை மூடுகிறது. UFW திசை மற்றும் இடைமுகத்தின் அடிப்படையில் முடிவெடுக்கிறது, எனவே கம்பியில்லா இணைப்புக்கு எழுதப்பட்ட விதி டனலில் இருந்து வெளியேறும் போக்குவரத்தைப் பற்றி எதுவும் சொல்லவில்லை. சரிசெய்தல் என்பது ஒரு குறிப்பிட்ட வரிசையில் பயன்படுத்தப்படும் சில குறுகிய விதிகள்.
அறிகுறி டனல் உயர்ந்த பிறகுதான் தோன்றுகிறது
இயல்புநிலை மறுப்புக் கொள்கை சொன்னதைச் சரியாகச் செய்கிறது: பொருந்தும் விதி இல்லாத அனைத்தும், இருக்கும் ஒவ்வொரு இடைமுகத்திலும் மறுக்கப்படுகிறது. விதிகள் எழுதப்பட்டபோது டனல் இல்லை, எனவே அவற்றில் எதுவும் அதைப் பிடிக்க முடியாது, மேலும் எப்போதும் இருந்த மறுப்பு இப்போது பெயர் தீர்வுக்குப் பொருந்துகிறது. எழுத்துப்பூர்வ முகவரிக்கு நேரடிப் போக்குவரத்து, பரந்த அனுமதி அதை மூடும்போது இன்னும் வேலை செய்யலாம், அதனால்தான் பொது resolver க்கான ping வெற்றியடைகிறது ஆனால் பெயர் தேடல் தோல்வியடைகிறது. இடைவெளி என்பது கொள்கை ஒருபோதும் பார்க்காத ஒரு இடைமுகத்திற்கான விதி.
தோல்வி ஏன் சுத்தமாகத் தலைகீழாகிறது என்பதையும் இது விளக்குகிறது: டனலை இறக்குங்கள், பெயர்கள் மீண்டும் தீர்க்கப்படும், ஏனெனில் வினவல் விதிகள் உள்ள இடைமுகத்திற்குத் திரும்புகிறது. டனல் உயர்ந்திருக்கும்போது மட்டும் தோல்வியடையும் கொள்கை DNS பிரச்சினை அல்ல, மேலும் resolver ஐயே சரிசெய்வது இங்கு அதிக நேரத்தை வீணாக்குகிறது. resolver உள்ளமைவைப் படிப்பதற்கு முன் இடைமுகப் பட்டியலைப் படியுங்கள்.
மூன்று திசைகள், மூன்று வெவ்வேறு விதித் தொகுப்புகள்
ஒரு அமர்வு ஒன்றுக்கு மேற்பட்ட திசைகளில் விதிகளைத் தொடுகிறது, மேலும் டனல் அவற்றில் கிட்டத்தட்ட அனைத்திற்கும் இரண்டாவது இடைமுகத்தைச் சேர்க்கிறது. போக்குவரத்தை முதலில் திசை மற்றும் இடைமுகத்தின்படி வரிசைப்படுத்தினால் மீதி இயந்திரத்தனமாகிறது, ஏனெனில் கீழேயுள்ள ஒவ்வொரு வரிசைக்கும் அதன் இடத்தில் அதன் சொந்த விதி தேவை. எடுத்துக்காட்டுகள் tun0 ஐயும் 10.8.0.0/24 தொகுப்பையும் பயன்படுத்துகின்றன, எனவே பெயர்களையும் வரம்புகளையும் வாடிக்கையாளரின் சொந்த வெளியீட்டில் உள்ளவற்றால் மாற்றுங்கள்.
| Direction | Example packet | Rule that admits it | Written on |
|---|---|---|---|
| Client to the pushed resolver | A DNS query to 10.8.0.1 | Destination port 53 over the tunnel | The client's tun0 |
| Client to the VPN server | A handshake to the server's public address | Server address and port on the physical link | The client's physical interface |
| Server to a service | SSH from the pool to port 22 | Source pool, destination port, tunnel interface | The server's tun0 |
| Anyone to the listener | The VPN listener itself | 1194/udp on the public side | The server's public interface |
இரண்டு வரிசைகள் அடிக்கடி குழப்பமடைகின்றன, ஏனெனில் இரண்டும் டனலைக் குறிப்பிடுகின்றன. resolver க்கான விதி வாடிக்கையாளர் டனலுக்குள் அனுப்பும் போக்குவரத்தை அனுமதிக்கிறது, ஆனால் SSH க்கான விதி சேவையகம் அங்கிருந்து பெறும் போக்குவரத்தை அனுமதிக்கிறது; அவை வெவ்வேறு இயந்திரங்களில் வாழ்கின்றன மற்றும் தனித்தனியாகத் தோல்வியடைகின்றன. அதிகம் மறக்கப்படும் வரிசை இரண்டாவது, ஏனெனில் சேவையகத்தின் பொது முகவரிக்கு வாடிக்கையாளரின் போக்குவரத்து அனுமதிக்கப்படும் வரை வாடிக்கையாளர் டனலை உருவாக்கவே முடியாது. மேலிருந்து கீழாக வேலை செய்யுங்கள், ஒவ்வொரு தோல்விக்கும் ஒரு சாத்தியமான காரணம் உண்டு.
தள்ளப்பட்ட resolver க்கு அதன் சொந்த விதி தேவை
டனல் DNS ஐக் கொண்டு செல்கிறதா என்பது சேவையகம் எதை அனுப்புகிறது என்பதைப் பொறுத்தது. resolver விருப்பத்தைத் தள்ளும் சேவையகம் வாடிக்கையாளரின் உள்ளமைவில் தனிப்பட்ட முகவரியை நிறுவுகிறது, அந்த முகவரி டனல் வழியாக மட்டுமே வழிப்படுத்தப்படும். சேவையகம் எதையும் தள்ளவில்லை என்றால், வாடிக்கையாளர் ஏற்கனவே இருந்த resolver ஐ வைத்துக்கொள்கிறார், கீழேயுள்ள விதிகளுக்கு அனுமதிக்க எதுவும் இல்லை. எதையும் எழுதுவதற்கு முன் தள்ளப்பட்ட நிலையையும் தற்போதைய வினவல் முடிவையும் சரிபார்க்கவும்:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedநிலை வெளியீடு பயன்படுத்தப்படும் resolver ஐயும் அது பிணைக்கப்பட்ட இணைப்பையும் பெயரிடுகிறது, அதன் பின்னால் உள்ள வழித் தேடல் அந்த முகவரிக்கு வினவலை எந்த இடைமுகம் எடுத்துச் செல்லும் என்பதைக் காட்டுகிறது. resolver வேறொரு இணைப்பில் அமர்ந்திருக்கும்போது, பிரச்சினை firewall க்கு முந்தையது, எந்த விதியும் உதவாது. இரண்டும் டனலைப் பற்றி ஒப்புக்கொள்ளும்போது, இரண்டு விதிகள் தேவை, ஏனெனில் பெரும்பாலான வினவல்களை UDP எடுத்துச் செல்கிறது, பதில் வெட்டப்படும்போது TCP பொறுப்பேற்கிறது. இரண்டு மதிப்புகளையும் பதிவு செய்யுங்கள், ஏனெனில் விதிகள் பெயரிடப்போவது அவற்றையே:
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto udp comment 'pushed resolver'
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto tcp comment 'truncated answers'உட்பாதைக்கு முன் வெளிப்பாதையைத் திறக்கவும்
டனல் இருப்பதற்கு முன் வாடிக்கையாளர் சேவையகத்தின் பொது முகவரியை அடைய வேண்டும், எனவே அதற்கான விதி இயற்பிய இணைப்பில் அமர்கிறது, முதலில் அதன் இடத்தில் இருக்க வேண்டும். resolver ஐ அனுமதித்து சேவையகத்தை மறக்கும் கொள்கை வாடிக்கையாளரை டனலை உருவாக்கவே முடியாத நிலையில் விட்டுவிடுகிறது, அந்த அறிகுறி பொதுவாக kill switch மீது சுமத்தப்படுகிறது. பின்னர் நீங்கள் உண்மையில் டனல் வழியாக விரும்பிய சேவைகளை அனுமதியுங்கள், ஒரு நேரத்தில் ஒரு குறுகிய விதி, இடைமுகத்தை முழுவதுமாகத் திறப்பதற்குப் பதிலாக. குறுகிய விதிகளே மறுப்பு தன் இடத்தில் தொடர்வதற்கான காரணம்.
sudo ufw allow out to 198.51.100.10 port 1194 proto udp comment 'vpn server'
sudo ufw allow out on tun0 to any port 443 proto tcp comment 'web through tunnel'சோதிக்கும்போது வரிசை முக்கியம், ஏனெனில் டனல் உயர அனுமதிப்பது முதல் விதிதான். அதைச் சேர்த்து, இணைந்து, சேவை விதியைச் சேர்ப்பதற்கு முன் டனல் உயர்ந்திருப்பதை உறுதிசெய்யுங்கள், ஏனெனில் இரண்டையும் ஒரே நேரத்தில் செய்தால் தோல்வி எந்தப் பாதி தவறு என்று எதுவும் சொல்லாது. மேலே உள்ள ஆவண முகவரிக்குப் பதிலாக வாடிக்கையாளர் பயன்படுத்த உள்ளமைக்கப்பட்ட முனைப்புள்ளியை இடுங்கள்.
வேண்டுமென்றே இணைப்பைத் துண்டித்து வாடிக்கையாளர் பக்கத்தை முடிக்கவும். மறுப்பு வேண்டுமென்றே விலக்கிய போக்குவரத்தை இன்னும் மறுக்க வேண்டும், ஏனெனில் டனல் உயர்ந்திருக்கும்போது பதிலளிக்கும் resolver சந்தேகம் வரும்போது மறுக்கும் கொள்கையின் பாதியை மட்டுமே மூடுகிறது.
இணையும் வாடிக்கையாளர் இன்னும் ஏற்கப்படவில்லை
சேவையகத்திற்கும் கருத்தில் கொள்ள வேண்டிய அதன் சொந்த திசை உண்டு, கைக்குலுக்கலை முடிக்கும் வாடிக்கையாளர் சேவையகம் அவரை ஏற்கும் வரை சேவையகத்தில் இயங்கும் எதையும் அடைய முடியாது. பொது ஊடுருவியின் விதி டனல் இருப்பதற்கு மட்டுமே அனுமதிக்கிறது; டனலின் போக்குவரத்தை உள்ளே விடாது. சேவையகத்தில் இவை இரண்டு விதிகள் மற்றும் சேவை உண்மையில் கேட்கிறதா என்பதற்கான ஒரு சரிபார்ப்பு:
sudo ufw allow 1194/udp comment 'openvpn listener'
sudo ufw limit in on tun0 from 10.8.0.0/24 to any port 22 proto tcp comment 'admin over tunnel'
ss -ltn | grep ':22'விதியில் உள்ள தொகுப்பு சேவையகம் ஒதுக்கும் வரம்புக்குச் சமமாக இருக்க வேண்டும், டனல் எண் சேவையகம் உருவாக்கியதற்குப் பொருந்த வேண்டும், ஏனெனில் வேறு இடைமுகத்திற்கான விதி விதி இல்லாததிலிருந்து வேறுபடுத்த முடியாது. limit நிர்வாகப் போர்ட்டுக்கு வேண்டுமென்றே, ஏனெனில் அது மீளும் இணைப்புகளை வரம்பின்றி ஏற்பதற்குப் பதிலாக வரம்பிடுகிறது. ஊடுருவி சரிபார்ப்பு மூடிய போர்ட்டை வீசப்பட்ட பொதியிலிருந்து பிரிக்கிறது, அவை வாடிக்கையாளரிடம் இருந்து ஒரே மாதிரி தெரிகின்றன. எண்ணிடப்பட்ட விதிகளும் முழுப் படம் அல்ல: UFW இன் before விதிகளும் கையால் எழுதப்பட்ட எந்த nftables வரியும் முன்பே பொருந்துகின்றன, பட்டியல் அனுமதிப்பதாகத் தெரியும் பொதியையும் இன்னும் மறுக்கலாம்.