OpenVPN-ի հաճախորդների անունները dnsmasq-ում՝ սկրիպտ, թե՞ ստատիկ գրառումներ։
Հաճախորդների հասցեները փոխվում են, ծառայությունների անունները՝ ոչ։ Ստեղծեք հաճախորդների անուններ 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= և տիրույթի ընդլայնում
Ուղղեք dnsmasq-ը ստեղծված ֆայլին՝ համակարգի hosts ֆայլի փոխարեն, և տվեք նրան տիրույթ, որպեսզի կարճ անունները ընդլայնվեն լրիվ որակավորված անունների՝
domain=corp.example
no-hosts
addn-hosts=/etc/openvpn/hosts.lan
listen-address=127.0.0.1,10.8.0.1
bind-interfacesԵրբ domain-ը սահմանված է, 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Եթե ուղղակի հարցումները պատասխանում են, իսկ հավելվածը՝ ոչ, մեղքը հաճախորդին հանձնելու մեջ է, ոչ թե զոնայում։ Եթե անունը լուծվում է, իսկ կապը դեռ ձախողվում է, անունը լավն է, և հաջորդը, ինչ պետք է նայել, երթուղին կամ ֆայրվոլն է։
Գրեք երկու կատեգորիաները կարգավորման կողքին՝ որ անուններն են ստեղծվում, որոնք են ամրացված, և յուրաքանչյուրը որ վկայագրին պետք է համապատասխանի։ Հաջորդ մարդը, ով սերվեր կավելացնի, կպատճենի առաջին իսկ օրինակը, որը կգտնի։