PostgreSQL VPN-ის გავლით: რომელ წყაროს მისამართს დაინახავს pg_hba

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

სამი გადაწყვეტილება, რომლებიც არ უნდა გაერთიანდეს

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

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

სად უსმენს სერვერი

დაუკავშირდით მისამართს, რომელიც რეალურად მინიჭებულია მანქანას და არა ინტერფეისის სახელს:

listen_addresses = '10.20.0.30'

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

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

მისამართი, რომელსაც HBA რეალურად ხედავს

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

უკვე TLS და SCRAM-ს იყენებს განლაგებისთვის, განზრახ ვიწრო დისტანციური წვდომის მაგალითი ასე გამოიყურება:

hostssl appdb app_login 10.8.0.0/24 scram-sha-256
host all all 0.0.0.0/0 reject
host all all ::/0 reject

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

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

პირველი დამთხვევა იმარჯვებს, სარეზერვო გზის გარეშე

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

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

HBA ცნობარი განსაზღვრავს როგორც რიგს, ისე განსხვავებას host და hostssl ჩანაწერებს შორის, რაც მნიშვნელოვანია მაშინ, როცა წესის არსი ისაა, რომ კავშირი უნდა იყოს დაშიფრული.

გადატვირთვა, ხელახლა გაშვება და უარყოფილი შემთხვევა

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

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

გამოსცადეთ ახალი სესიებით: დამტკიცებული კლიენტი განზრახული ანგარიშით უკავშირდება, იგივე ანგარიში დაუმტკიცებელი გზიდან — არა, და არაუფლებამოსილი მონაცემთა ბაზის იდენტობა მაინც ფუჭდება VPN-ის შიგნიდან. ეს სამი შედეგი ჰყოფს ქსელურ საზღვარს მონაცემთა ბაზის ავტორიზაციისგან, რაც არის გადაწყვეტილებების ცალ-ცალკე შენახვის მთელი აზრი.