ერთი VPN ბოლო წერტილი Squid-ის გავლით: ვიწრო CONNECT გამონაკლისი

ნება დართეთ ერთ დამტკიცებულ წყაროს, გავიდეს Squid-ის გავლით ერთ VPN კარიბჭემდე 1194 პორტზე, შეინარჩუნეთ პორტების გლობალური მცველები და დაამტკიცეთ, რომ სხვა არაფერი გახსნილა.

Squid CONNECT მოთხოვნას პასუხობს პირველი შესაბამისი http_access სტრიქონით და ეს სტრიქონი შეიძლება უარი იყოს. სწორედ ეს ერთი ფაქტი ხსნის, თუ რატომ ხშირად ვერ ახერხებს VPN ბოლო წერტილის გამონაკლისი პირველივე ცდაზე, რადგან მოთხოვნა ვერასოდეს აღწევს იმ ნებართვამდე, რომელიც ვიღაცამ ბოლოში დაამატა. ვიწრო შესწორება ინარჩუნებს არსებულ პორტის მცველებს და ასწავლის მათ ერთ გადამოწმებულ წყაროს, დანიშნულებასა და პორტს. პროქსიზე დარჩენილი ყველაფერი იქცევა ზუსტად ისე, როგორც ადრე.

როგორ წყვეტს Squid CONNECT მოთხოვნას

CONNECT მოთხოვნა ასახელებს ჰოსტსა და პორტს, და Squid რიგრიგობით გადის http_access სტრიქონებს, სანამ ერთი მათგანი არ დაემთხვევა. შესაბამისი უარი დაუყოვნებლივ ამთავრებს შეფასებას და კლიენტი პროქსისგან იღებს 403-ს. სწორედ ამიტომ წესის პოზიცია უფრო მნიშვნელოვანია, ვიდრე მისი ფორმულირება. იმავე სტრიქონის ერთი საფეხურით ზემოთ გადატანამ შეიძლება შედეგი სრულიად შეცვალოს.

ჩვეულებრივი მცველები უარყოფენ ყველაფერს Safe_ports-ის გარეთ და უარყოფენ CONNECT-ს SSL_ports-ის გარეთ. ეს სახელები თქვენს საკუთარ კონფიგურაციაში განსაზღვრული ACL-ებია, ამიტომ მათი შიგთავსი თქვენია და არა პროტოკოლის. დისტრიბუციამ შეიძლება დაუშვას პორტების ფართო დიაპაზონი როგორც Safe_ports, ხოლო CONNECT ცალკე შეზღუდოს. წაიკითხეთ ცოცხალი მნიშვნელობები, სანამ ჩათვლით, რომ პორტი დიზაინით არის დაბლოკილი.

დაადასტურეთ, რომ პროქსია ის კომპონენტი, რომელიც უარყოფს მოთხოვნას. Squid-ის მიერ შექმნილი 403 საერთოდ არ ჰგავს VPN სერვერის TLS გაფრთხილებას, და ორივეს ერთ პრობლემად გაერთიანება პირველი საათი ღირს. შეამოწმეთ მოთხოვნის წვდომის ჟურნალის სტრიქონი, რადგან ის აფიქსირებს როგორც მოქმედებას, ისე იმ წესს, რომელმაც ის წარმოშვა.

ააგეთ ერთი გაერთიანებული დამთხვევა სამი ცალკეული ACL-ის ნაცვლად

გამონაკლისი ააგეთ სამი ფაქტისგან: დამტკიცებული წყაროს დიაპაზონი, ერთი დამტკიცებული დანიშნულების მისამართი და ერთადერთი პორტი, რომელზეც ბოლო წერტილი უსმენს. ორი ცალკეული ACL და ერთი გაერთიანებული დამთხვევა ძალიან განსხვავებულ პოლიტიკას იძლევა, რადგან სწორედ კომბინაცია ფასდება. გაერთიანებულ ACL-ს დაარქვით სახელი იმის მიხედვით, რასაც უშვებს და არა იმ მეთოდის მიხედვით, რომელსაც ატარებს.

ქვემოთ მოცემული ფორმა იყენებს დოკუმენტაციის დიაპაზონებს, რომლებიც უნდა შეიცვალოს გადამოწმებული მნიშვნელობებით. Squid არც ერთ ამ სახელს არ იტოვებს თავისთვის, ამიტომ მათი არჩევა და თანმიმდევრულად შენარჩუნება თქვენი საქმეა. ეს რეცეპტი შემოიფარგლება Squid 6-ითა და 7-ით, რომელთა დოკუმენტირებული კონფიგურაცია მხარს უჭერს all-of ჯგუფს. მიმდინარე ცნობარი ამ დირექტივებს Squid 8-ში მიუწვდომლად აღნიშნავს, ამიტომ მოეკიდეთ ამას როგორც ვერსიაზე მიბმულ რეცეპტს და არა მიგრაციის გზას, და გამოყენებამდე შეამოწმეთ დირექტივა თქვენი ვერსიის ცნობარში.

acl pvpn_src src 192.0.2.128/25
acl pvpn_dst dst 198.51.100.77/32
acl pvpn_port port 1194
acl pvpn_ok all-of CONNECT pvpn_port pvpn_dst pvpn_src

all-of ჯგუფი ემთხვევა მხოლოდ მაშინ, როცა ყველა წევრი ემთხვევა, რაც ნიშნავს, რომ წყარო, დანიშნულება და პორტი ერთ სტრიქონზე მოწმდება. ჯგუფი თავისთავად არაფერს იძლევა, და მოთხოვნა, რომელიც სამი ფაქტიდან მხოლოდ ორს ემთხვევა, ვერ დააკმაყოფილებს მას. ეს თვისება გამონაკლისს ვიწროდ ინარჩუნებს, როცა ვინმე მოგვიანებით მეორე კარიბჭეს ამატებს. ან ახალი დანიშნულება განზრახ ემატება, ან მოთხოვნა თავდაპირველ მცველებს უბრუნდება.

მოხარეთ პორტის მცველები მათი მოშორების გარეშე

მათ ამჟამინდელ ადგილებზე ორი ჩვეულებრივი მცველი სტრიქონი ასე გამოიყურება. ისინი ჩვეულებრივ ავტორიზაციის შემდეგ და ყველაფრის ნების დამშვები პოლიტიკის სტრიქონებამდე დგანან.

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

დაამატეთ უარყოფილი გაერთიანებული დამთხვევა თითოეულს, რათა შესაბამისი გამონაკლისი გადაურჩეს მცველს, რომელიც სხვაგვარად უარყოფდა მას. იცვლება მხოლოდ მცველი სტრიქონები და თითოეული მხოლოდ ერთი დამატებითი პირობით.

http_access deny CONNECT !SSL_ports !pvpn_ok
http_access deny !Safe_ports !pvpn_ok

ერთი წვდომის სტრიქონის პირობები გაერთიანდება, ამიტომ სტრიქონი ახლა უარყოფს მხოლოდ იმ მოთხოვნებს, რომლებიც ვერ გადიან არც თავდაპირველ შემოწმებას და არც გამონაკლისს. დამტკიცებული ბოლო წერტილის მოთხოვნა გადის, ხოლო ყველა სხვა მოთხოვნა ინარჩუნებს პორტის ძველ ქცევას. ეს უფრო ვიწროა, ვიდრე პორტის გლობალურ SSL_ports სიაში დამატება, რაც ამ პორტს ყველა დანიშნულებისთვის დაუშვებდა. თუ პორტი უკვე არის ამ სიაში, ეს ACL არაფერს ვიწროვებს და ძველი, უფრო ფართო ნებართვა კვლავ ძალაშია სხვა დანიშნულებებისთვის, ამიტომ წაიკითხეთ ცოცხალი სია, სანამ განაცხადებთ, რომ გამონაკლისმა პორტი გახსნა. ის ასევე შექცევადია, რადგან ორი სტრიქონი უბრუნდება წინანდელ ფორმას. წვდომის კონტროლის ცნობარი აღწერს იმ თანმიმდევრობასა და ჩვეულებრივ მცველებს, რომლებზეც ეს ცვლილებაა დამოკიდებული.

სად არ უნდა განთავსდეს გამონაკლისი

ცდუნება არის მცველებზე ზემოთ ნებართვის დადება და დასრულება. ეს განლაგება ასევე გამოტოვებს ავტორიზაციისა და ლოკალური დანიშნულების დაცვებს, რომლებიც ჩვეულებრივ მუშა კონფიგურაციის ზედა ნაწილთან ახლოს არიან. შედეგი ვიწრო გამონაკლისი არ არის, არამედ ხვრელი ზემოთ კომენტარით. ნებისმიერი ახალი ნებართვა შეინარჩუნეთ იმავე გადამოწმებულ ეტაპზე, როგორც კლიენტის პოლიტიკის დანარჩენი ნაწილი.

შეამოწმეთ, რა სჭირდება მოთხოვნას ჯერ კიდევ პორტის მცველების შემდეგ. ავტორიზებული ანგარიში, დაშვებული კლიენტის მისამართი და დანიშნულების პოლიტიკა ყველა კვლავ მოქმედებს, და გამონაკლისი არც ერთ მათგანს არ ცვლის. თუ თქვენი პროქსი უკვე აძლევს დამტკიცებულ ანგარიშს თვითნებურ დანიშნულებებზე წვდომას, პორტის მცველი არასოდეს ყოფილა ნამდვილი კონტროლი.

დაფიქრდით, არის თუ არა ბოლო წერტილი საერთოდ TCP. CONNECT გამონაკლისი TCP ნაკადებს ატარებს, და UDP-ს გამოყენებული OpenVPN პროფილი მის გავლით მისაწვდომი არ გახდება. შეცვალეთ პროფილი TCP-ზე მხოლოდ მაშინ, თუ სერვერი ასე უსმენს და ოპერატორი ქცევის განსხვავებას იღებს.

შეამოწმეთ საზღვარი პარსერითა და რეალური მოთხოვნით

გააანალიზეთ კონფიგურაცია გადატვირთვამდე და ამ დროს მეორე სესია ღიად შეინახეთ. გადატვირთვის დროს სინტაქსური შეცდომა შეიძლება პროქსი ძველ კონფიგურაციაზე დატოვოს ან ახალი სრულიად უარყოს. პარსერი იუწყება უარყოფილ სტრიქონს, რაც უფრო მეტია, ვიდრე კლიენტის შეცდომა გეტყვით.

შემდეგ გადატვირთეთ და გაგზავნეთ ერთი რეალური CONNECT პროქსის გავლით დამტკიცებული წყაროდან. პარსერის გაშვება პირველი მოდის, რადგან ბეჭდვითი შეცდომით გადატვირთვა პოლიტიკაზე არაფერს გასწავლით.

squid -k parse
squid -k reconfigure
curl -v -p -x http://proxy.lab.internal:3128 https://vpn.lab.internal:1194/ --max-time 5

გამოსცადეთ სამი შემთხვევა: დამტკიცებული წყარო და ანგარიში, დაუმტკიცებელი წყარო, და სხვა დანიშნულება იმავე პორტზე. მესამე შემთხვევა ამტკიცებს გამონაკლისის ვიწრობას, რადგან პორტს დანიშნულების დამთხვევის გარეშე ამოწმებს. წაიკითხეთ წვდომის ჟურნალი სამივესთვის, ნაცვლად კლიენტის შეტყობინების ნდობისა. წარმატებული CONNECT ამყარებს TCP ნაკადს და მეტს არაფერს, ამიტომ VPN ხელის ჩამორთმევა ცალკე გამოცდად რჩება.

დაკავშირებული სტატიები