dnsmasq இல் OpenVPN கிளையன்ட் பெயர்கள்: ஸ்கிரிப்டா அல்லது நிலையான பதிவுகளா?
கிளையன்ட் முகவரிகள் மாறும், சேவைப் பெயர்கள் மாறாது. VPN அமர்விலிருந்து கிளையன்ட் பெயர்களை உருவாக்கி, drop-in கோப்பில் சேவைப் பெயர்களை நிலைநிறுத்தி, பின்னர் கிளையன்ட்கள் அதைப் பயன்படுத்தச் செய்யுங்கள்.
கிட்டத்தட்ட ஒவ்வொரு சிறிய OpenVPN நுழைவாயிலிலும் இரண்டு பெயர் சிக்கல்கள் தோன்றும். இணைக்கப்பட்ட மடிக்கணினியை அதன் சான்றிதழில் உள்ள பெயரால் அணுக முடியாது, சுரங்கப்பாதையின் பின்னால் உள்ள சேவைகளுக்கு பெயர்களே இல்லை. அவை ஒரே சிக்கலாகத் தெரிகின்றன ஆனால் எதிர் தீர்வு தேவை, ஏனெனில் ஒரு முகவரி ஒவ்வொரு அமர்விலும் நகர்கிறது மற்றொன்று நகராது. எதையும் திருத்தும் முன் நீங்கள் எந்த வகை பெயரைச் சேர்க்கிறீர்கள் என்பதை முடிவு செய்யுங்கள்.
நுழைவாயிலின் அடிப்படையில் அல்ல, பெயரின் அடிப்படையில் முடிவு செய்யுங்கள்
சோதனை எளிது: கிளையன்ட் மீண்டும் இணைக்கும்போது இந்த முகவரி மாறுகிறதா? ஆம் எனில், பெயர் VPN அமர்விலிருந்து உருவாக்கப்பட வேண்டும். இல்லை எனில், அது நீங்கள் படித்து மதிப்பாய்வு செய்யக்கூடிய நிலையான பதிவுக்கு உரியது.
| Name kind | Source of truth | Where it lives |
|---|---|---|
| Connected client | The address OpenVPN just assigned | Generated hosts file, rewritten per session |
| Service behind the tunnel | A fixed address you chose | Static address= drop-in |
| Anything with a certificate name | The certificate, not the pool | Either, but the name must match the certificate |
இரண்டையும் கலப்பதே வழக்கமான தோல்வி. உருவாக்கப்பட்ட கோப்பில் நிலைநிறுத்தப்பட்ட சேவை, ஸ்கிரிப்ட் முதல் முறையாக அதை மீண்டும் எழுதும்போது மறைந்துவிடும், நிலையான பதிவில் எழுதப்பட்ட கிளையன்ட் அந்த முகவரியை கடைசியாக வைத்திருந்தவரைக் காட்டும். இரண்டு தவறுகளும் பெயர் தவறான இயந்திரத்தில் தீர்க்கப்படும் வரை கண்ணுக்குத் தெரியாது. அப்போது பிழைதிருத்துபவர் DNS கெட்டுப்போனதாக நினைக்கிறார், கோப்பு அல்ல.
மாறும் பாதை: learn-address மற்றும் குளம்
OpenVPN ஒதுக்கீட்டை அறியும், எனவே அது உங்களுக்குச் சொல்லட்டும். இந்த சேவையக விருப்பங்கள் ஒதுக்கீட்டை நீடித்ததாகவும் ஸ்கிரிப்ட் செய்யக்கூடியதாகவும் ஆக்குகின்றன:
client-config-dir /etc/openvpn/ccd
ifconfig-pool-persist /etc/openvpn/ip-pool 60
script-security 2
learn-address /etc/openvpn/learn-address.shlearn-address ஒரு முகவரி சேர்க்கப்படும்போது, புதுப்பிக்கப்படும்போது அல்லது நீக்கப்படும்போது ஒவ்வொரு முறையும் உங்கள் ஸ்கிரிப்டை இயக்கி, செயல்பாடு, முகவரி மற்றும் பொதுப் பெயரை அனுப்புகிறது. குறைந்தபட்ச ஸ்கிரிப்ட் ஒவ்வொரு கிளையன்டுக்கும் ஒரு வரியைச் சேர்த்து நீக்கும்போது அதை அகற்றும்:
#!/bin/sh
HOSTS=/etc/openvpn/hosts.lan
case "$1" in
add|update) echo "$2 $3" >> "$HOSTS" ;;
delete) sed -i "/^$2 /d" "$HOSTS" ;;
esac
kill -HUP $(cat /var/run/dnsmasq.pid)
tun சாதனத்தில் இரண்டாவது வாதம் கிளையன்டின் சுரங்க முகவரி, எனவே வரியை நேரடியாகப் பயன்படுத்தலாம். tap சாதனத்தில் OpenVPN அதற்குப் பதிலாக கிளையன்டின் MAC முகவரியை அனுப்புகிறது, ஏனெனில் tap பிரிவு IPv4 அல்லாத நெறிமுறைகளையும் சுமக்கலாம், அப்போது எதையும் எழுதும் முன் பொதுப் பெயரால் குளக் கோப்பில் முகவரியைத் தேட வேண்டும்.
உருவாக்கப்பட்ட கோப்பு என்ன என்பதைத் தெளிவாக வைத்திருங்கள்: இப்போது யார் இணைக்கப்பட்டிருக்கிறார்கள் என்பதன் ஸ்னாப்ஷாட். இணைப்பு துண்டிக்கப்படும்போது பெயர்கள் மறைந்துவிடும், இது வலைப்பிண்ணங்களுக்கு இடையே நகரும் மடிக்கணினிகளுக்கு நீங்கள் விரும்புவதும், இரவு முழுவதும் இயங்கும் சேவையகத்திற்கு நீங்கள் விரும்பாததும் ஆகும்.
நிலையான பாதை: address= மற்றும் கள விரிவாக்கம்
கணினியின் hosts கோப்புக்குப் பதிலாக dnsmasq ஐ உருவாக்கப்பட்ட கோப்பை நோக்கித் திருப்பி, குறுகிய பெயர்கள் முழுமையாகத் தகுதிபெற்ற பெயர்களாக விரிவடைய ஒரு களத்தைக் கொடுங்கள்:
domain=corp.example
no-hosts
addn-hosts=/etc/openvpn/hosts.lan
listen-address=127.0.0.1,10.8.0.1
bind-interfacesdomain அமைக்கப்பட்டிருக்கும்போது, 10.8.0.6 alice போன்ற ஒரு வரி alice மற்றும் alice.corp.example இரண்டிற்கும் பதிலளிக்கிறது. listen-address ஐ சுரங்க நுழைவாயில் மற்றும் loopback க்கு மட்டும் வைத்திருங்கள், ஏனெனில் LAN இடைமுகத்தில் தற்செயலாக வெளியிடப்பட்ட தீர்வி என்பது நீங்கள் வழங்க எண்ணாத சேவையாகும்.
குளத்திலிருந்து ஒருபோதும் வராத சேவைகளுக்கு அவற்றின் சொந்தப் பதிவுகள் உண்டு. விநியோகத்தின் கட்டமைப்பு அடைவில் தனி drop-in கோப்பில் வைக்கவும், அதனால் தொகுப்பு மேம்படுத்தல் அவற்றை மேலெழுத முடியாது:
address=/files.corp.example/10.8.0.20
address=/db.corp.example/10.9.0.5தீர்வியை ஒப்படையுங்கள், இல்லையேல் எதுவும் நடக்காது
யாரும் கேட்காத தீர்வி எதையும் மாற்றாது. சேவையகம் அதை அறிவிக்க வேண்டும்:
push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"Windows கிளையன்ட்கள் இரண்டு விருப்பங்களையும் தாங்களே பயன்படுத்துகின்றன. பெரும்பாலான Linux கிளையன்ட்கள் அவ்வாறு செய்வதில்லை: அவர்களுக்கு ஆதரவளிக்கப்பட்ட தீர்வி ஒருங்கிணைப்பு தேவை, உதாரணமாக விநியோகத்தின் update-resolv-conf கொக்கி அல்லது NetworkManager இன் DNS கையாளுதல், அல்லது கைமுறையாக அமைக்கப்பட்ட தேடல் களம் மற்றும் பெயர் சேவையகம். push கடைப்பிடிக்கப்பட்டதாகக் கருதுவதற்குப் பதிலாக கிளையன்டின் உண்மையான தீர்வியைச் சரிபார்க்கவும், ஏனெனில் புறக்கணிக்கப்பட்ட push பதிலளிக்காத சேவையகம் போலவே தெரிகிறது.
மூன்று அடுக்குகளில் சரிபார்க்கவும்
முதலில் சேவையகத்தை நேரடியாகக் கேளுங்கள், பின்னர் ஒரு கிளையன்டை, பின்னர் பயன்பாட்டை:
dig +short @10.8.0.1 alice.corp.example
getent hosts files.corp.exampleநேரடி வினவல்கள் பதிலளித்து பயன்பாடு பதிலளிக்கவில்லை என்றால், தவறு மண்டலத்தில் அல்ல, கிளையன்டுக்கு ஒப்படைப்பதில் உள்ளது. பெயர் தீர்க்கப்பட்டு இணைப்பு இன்னும் தோல்வியடைந்தால், பெயர் சரியானது, அடுத்து பார்க்க வேண்டியது வழி அல்லது தீச்சுவர்.
இரண்டு வகைகளையும் கட்டமைப்பின் அருகில் எழுதுங்கள்: எந்தப் பெயர்கள் உருவாக்கப்படுகின்றன, எவை நிலையானவை, ஒவ்வொன்றும் எந்தச் சான்றிதழுடன் பொருந்த வேண்டும். அடுத்து ஒரு சேவையகத்தைச் சேர்க்கும் நபர் முதலில் காணும் முறையை நகலெடுப்பார்.