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თუ პირდაპირი მოთხოვნები პასუხობს, აპლიკაცია კი არა, ბრალი კლიენტისთვის გადაცემაშია და არა ზონაში. თუ სახელი წყდება და კავშირი მაინც ვერ მყარდება, სახელი რიგზეა და შემდეგი სანახავი მარშრუტი ან ფაირვოლია.
ჩამოწერეთ ორი კატეგორია კონფიგურაციის გვერდით: რომელი სახელები იქმნება, რომელია დამაგრებული და რომელ სერტიფიკატს უნდა შეესაბამებოდეს თითოეული. შემდეგი ადამიანი, ვინც სერვერს დაამატებს, დააკოპირებს პირველივე ნიმუშს, რომელსაც იპოვის.