OpenVPN push-peer-info: კლიენტების იარლიყირება წვდომის მიცემის გარეშე
UV_ ველი ავტორიზებული გვირაბით მოძრაობს, მაგრამ მნიშვნელობა მაინც კლიენტის მტკიცებაა. შეაერთეთ, შეამოწმეთ რა ჩამოვიდა და ავტორიზაცია სერვერზე დატოვეთ.
განლაგების ტეგები ის ჩვეულებრივი მიზეზია, რის გამოც ხალხი ამ ფუნქციას მიმართავს: ყოველ კავშირს უნდა ატაროს რაღაც, მაგალითად საიტი ან როლი, და სერვერმა უნდა წაიკითხოს ის მეორე სერტიფიკატის ფორმატის გამოგონების გარეშე. საზოგადოებრივ OpenVPN-ს ეს მექანიზმი უკვე აქვს და ის პატარაა. მტკივნეული ნაწილი მოლოდინებია. კლიენტის პროფილში ჩვეულებრივი ცვლადის დაყენება სერვერზე არაფერს აკეთებს და მოსული მნიშვნელობა მხოლოდ იმას ამტკიცებს, რომ კლიენტმა გამოგზავნა ის.
ეს არის სამუშაო გზის, იმის საჩვენებელი შემოწმების ნაბიჯის და იმ უკუქცევის სახელმძღვანელო, რომელიც ნახევრად კონფიგურირებულ კაუჭს არ ტოვებს. აქ არაფერი მოითხოვს ახალ სერტიფიკატს, ახალ დანამატს ან პროტოკოლის გაფართოებას.
დააყენეთ ცვლადი და ჩართეთ გზა
კლიენტის პროფილში ორი ხაზი აკეთებს საქმეს და ორივე აუცილებელია. პირველის გარეშე გასაგზავნი არაფერია; მეორის გარეშე კლიენტი საერთოდ არ გვთავაზობს პირის ინფორმაციას. თანმიმდევრობას მნიშვნელობა არ აქვს და ეს სასარგებლოა იცოდეთ, რადგან ორი ხაზი ხშირად გენერირებული პროფილის სხვადასხვა ნაწილში ხვდება. მთავარია, რომ ორივემ გადაიტანოს ნებისმიერი გადაწერა, სანამ კლიენტი წაიკითხავს მას.
setenv UV_DEPLOY field-support
push-peer-info
UV_ პრეფიქსი დეკორაცია არ არის. ჩვეულებრივი DEPLOY ცვლადი რჩება ლოკალურად კლიენტის პროცესში და არასოდეს გადაეცემა, ხოლო პრეფიქსიანი ფორმა არის ის სახელთა სივრცე, რომელსაც პროტოკოლი ინახავს მომხმარებლის მიერ განსაზღვრული ველებისთვის. დატოვეთ დამტკიცებული პროფილის დარჩენილი ნაწილი ხელუხლებელი და განლაგებამდე დარწმუნდით, რომ თქვენ მიერ განლაგებული კლიენტის აწყობა ორივე დირექტივას უჭერს მხარს.
ერთი პრაქტიკული შემოწმება აქ უნდა მოხდეს და არა ბოლოს: დარწმუნდით, რომ დირექტივა აღწევს კლიენტის ბინარულ ფაილამდე და არ იყლაპება გარსით. გრაფიკული კლიენტი, რომელიც თავისივე ბრძანების ხაზს ქმნის, ან შენახულ პროფილს თავიდან ტვირთავს მართვის ინტერფეისი, შეიძლება გადააგდოს ხაზები, რომლებსაც არ ცნობს. თუ სერვერი ვერაფერს ხედავს, ეს პირველი ადგილია, სადაც უნდა შეხედოთ.
წაიკითხეთ ველი სერვერის კაუჭიდან
სერვერის მხარეს მიღებული პირის ინფორმაცია მოწმდება და ჩასმულია კავშირის სამუშაო პროცესის გარემოში, და სწორედ ეს ხდის მას კაუჭიდან წაკითხვად თქვენი მხრიდან პროტოკოლური სამუშაოს გარეშე. სერვერს არ სჭირდება საკონტროლო არხის გარჩევა ან თქვენთვის რაიმეს შენახვა; მნიშვნელობა უბრალოდ იქ არის, სანამ კავშირი მყარდება. მინიმალური client-connect სკრიპტი, რომელიც იარლიყს ავტორიზებული სახელის გვერდით წერს, ასე გამოიყურება.
#!/bin/sh
# /etc/openvpn/server/hooks/label.sh
printf '%s %s\n' "$common_name" "${UV_DEPLOY:-unset}" \
>> /var/log/openvpn/deploy-labels.log
წაიკითხეთ ცვლადი გარემოს მეშვეობით და არა ლოგის გარჩევით, და ყოველთვის მიეცით ნაგულისხმევი მნიშვნელობა. ${UV_DEPLOY:-unset} სკრიპტს მუშა მდგომარეობაში ინახავს იმ კლიენტებისთვის, რომლებიც ველს არასოდეს აგზავნიან, რაც ეტაპობრივი განლაგების დროს ნორმალური მდგომარეობაა. სახელის საპოვნელად მთელი გარემო ლოგში ნუ გადააქცევთ; მასში იარლიყზე გაცილებით მეტია, მათ შორის ის მნიშვნელობებიც, რომელთა შენახვასაც არ აპირებდით.
გაუშვით სკრიპტი ხელით და ის ყველაფერზე unset-ს შეატყობინებს, რადგან ხელით გაშვებული ჭურვი კავშირის გარემოს არ ატარებს. ეს სკრიპტის ხარვეზი არ არის და იმის მტკიცებაც არ არის, რომ ველი აკლია. შეამოწმეთ ის რეალური კავშირის მეშვეობით, რაც ერთადერთი კონტექსტია, სადაც ცვლადი არსებობს.
შეამოწმეთ რა ჩამოვიდა სინამდვილეში
დააკავშირეთ ერთი კლიენტი იარლიყით და ერთიც მის გარეშე, შემდეგ წაიკითხეთ ფაილი. წყვილია გამოცდა: ერთი ხაზი უნდა ატარებდეს მნიშვნელობას, მეორე კი ნაგულისხმევს, და ორივემ უნდა დაასახელოს ის იგივე ავტორიზებული იდენტობა, რომელსაც ელოდებით.
tail -n 5 /var/log/openvpn/deploy-labels.log
# field-support deployed-client-07
# unset legacy-laptop-02
ის კომენტარის ხაზები გამოსავლის ფორმაა და არა თქვენი სერვერის ჩანაწერი; წაიკითხეთ თქვენი ფაილი. თუ მეორე კლიენტიც აჩვენებს მნიშვნელობას, ცვლადი გარემოში სხვაგან არის დაყენებული და თქვენ ძველ პარამეტრს კითხულობთ და არა პირის ველს.
შეამოწმეთ სერვერის ლოგიც კავშირისთვის. პირის ინფორმაცია იქ შეიძლება გამოჩნდეს, რაც მოხერხებულია გამართვისას და მიზეზია მნიშვნელობების მოსაწყენად შესანარჩუნებლად: ადამიანების სახელები არა, ბილეთის ნომრები არა, არაფერი, რისი დანახვაც ლოგის მკითხველს არ გსურდათ.
იარლიყს მოეპყარით როგორც მტკიცებას და არა იდენტობას
ვისაც შეუძლია კლიენტის პროფილის რედაქტირება, შეუძლია ტეგის შეცვლაც, და ის ფაქტი, რომ გვირაბი ავტორიზებულია, ტეგს არ ხდის უფლებამოსილს. ტრანსპორტი იცავს მნიშვნელობას გზაში; ის არ ადასტურებს მტკიცებას. ავტორიზაცია მაინც ეკუთვნის ავტორიზებულ იდენტობას და სერვერის საკუთრებაში არსებულ რეგისტრაციის ჩანაწერს, და იარლიყი ამ ჩანაწერს შედარებულია მაშინ, როცა ეს მნიშვნელოვანია.
ეს განსხვავება წყვეტს, სად შეიძლება იარლიყის გამოყენება. კარგი გამოყენებაა სესიის სწორ ლოგ ფაილზე მიმართვა, დაფაზე ჩვენების ჯგუფის არჩევა, ან მხარდაჭერის სესიის მონიშვნა, რათა ადამიანმა მოგვიანებით იპოვოს ის. ცუდი გამოყენებაა მოწყობილობის ქვექსელში დაშვება, firewall-ის პოლიტიკის არჩევა, ან იმის გადაწყვეტა, რომელი მომხმარებლის მონაცემების წაკითხვა შეუძლია სესიას.
გადაამოწმეთ მნიშვნელობა სანამ ის მიაღწევს ბილიკს, მოთხოვნას ან ჭურვის ბრძანებას. მოსალოდნელი სტრიქონების ნებადართული სია საკმარისია განლაგების იარლიყისთვის და არაფერი ღირს. არასოდეს ჩასვათ პირის მიერ მოწოდებული სტრიქონი ჭურვის ბრძანების ხაზში, და ნებისმიერი შენახული დაკვირვება შემოიფარგლეთ სესიით და არა გვირაბის მისამართით, რომელსაც შემდეგი კლიენტი ხელახლა გამოიყენებს.
case "${UV_DEPLOY:-}" in
field-support|field-qa|lab) : ;;
*) UV_DEPLOY=unknown ;;
esac
სუფთად დააბრუნეთ უკან
ფუნქციის მოცილება ორი წაშლა და ერთი შემოწმებაა. ამოიღეთ setenv და push-peer-info ხაზები კლიენტის პროფილიდან, შემდეგ ამოიღეთ ან გამორთეთ კაუჭი და მისი ლოგის დანიშნულება სერვერზე.
grep -rn 'UV_DEPLOY\|push-peer-info' /etc/openvpn/
tail -n 3 /var/log/openvpn/deploy-labels.log
ამის შემდეგ ხელახლა დააკავშირეთ ერთი კლიენტი და დაადასტურეთ, რომ ლოგის ხაზი აღარ ჩნდება. კაუჭი, რომელიც პროფილის ცვლილების შემდეგაც აგრძელებს მუშაობას, ჩვეულებრივ მეორე პროფილია, რომელიც ჯერ კიდევ განლაგებულია სატესტო მოწყობილობაზე, და მისი ახლა პოვნა იაფია, ვიდრე აუდიტის დროს.
ბოლოს რჩება სესიის მეტამონაცემების პატარა, შეზღუდული ნაწილი დოკუმენტირებული წარმოშობით: კლიენტი ამტკიცებს მას, სერვერი იწერს მას, და წვდომასთან დაკავშირებით არაფერია დამოკიდებული მასზე. ეს არის ფუნქციის სასარგებლო ვერსია და იქ მისასვლელად ახალი სერტიფიკატი არ არის საჭირო.