დააკავშირეთ QGIS PostGIS-თან VPN-ის მიღმა: ნაბიჯ-ნაბიჯ

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

დაიწყეთ ფენიდან და არა VPN-იდან

ფენის თითოეული ტიპი სხვადასხვა სახის საბოლოო წერტილს აღწევს. PostGIS ფენა ხსნის PostgreSQL კავშირს ჰოსტით, პორტით, მონაცემთა ბაზით და როლით. WMS ან WFS ფენა იღებს სერვისის URL-ს და შემდეგ აანალიზებს შესაძლებლობების დოკუმენტს. ქსელური წილი shapefile-ს სჭირდება მხოლოდ ფაილის გზა, რომლის გახსნაც ოპერაციულ სისტემას შეუძლია. რადგან ეს სამი სხვადასხვა მექანიზმია, ცარიელი პროექტი არაფერს გეუბნებათ, სანამ არ გაიგებთ, რომელს ამუშავებთ.

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

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

შეიყვანეთ ოპერატორის მიერ გაცემული კერძო საბოლოო წერტილი

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

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

VPN gateway:   vpn.gis.lab.example       (profile only, not a data source)
Database host: db.gis.lab.example:5432   (PostGIS service)
Database name: gis_prod
TLS mode:      verify-full

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

შეინარჩუნეთ მონაცემთა ბაზის TLS რეჟიმი გვირაბისგან ცალკე

SSL VPN პროდუქტის სახელში აღწერს გვირაბს და არა მონაცემთა ბაზის სესიას. QGIS გადასცემს PostgreSQL-ის SSL რეჟიმს libpq-ს, და ეს რეჟიმი აკონტროლებს, ამოწმებს თუ არა კლიენტი სერვერის სერტიფიკატს და ამოწმებს თუ არა მასში არსებულ ჰოსტის სახელს. verify-fullაკეთებს ორივეს, ამიტომ ეს არის რეჟიმი, რომლის შენარჩუნებაც ღირს, როცა სერტიფიკატი სერვისის სახელს ატარებს.

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

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

შეამოწმეთ ყოველი საზღვარი რიგრიგობით და წაიკითხეთ პირველი ჩავარდნა

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

getent hosts db.gis.lab.example
nc -vz db.gis.lab.example 5432
psql "host=db.gis.lab.example port=5432 dbname=gis_prod sslmode=verify-full" -c 'select 1'
curl -sS 'https://wms.gis.lab.example/ows?service=WMS&request=GetCapabilities' | head -c 200

ცარიელი პასუხი getent-დან სახელების გადაწყვეტის პრობლემაა და არა მონაცემთა ბაზის პრობლემა. უარყოფილი ან ვადაგასული nc ნიშნავს, რომ მარშრუტი ან firewall-ის წესი აკლია, რაც კარიბჭის მხრიდან გამოსწორებაა. TLS შეცდომა psql-დან ნიშნავს, რომ სერტიფიკატი ან სახელი არასწორია, ხოლო password authentication failed ნიშნავს, რომ PostgreSQL-ს მიაღწიეთ და პრობლემა სერტიფიკატშია. WMS ფენისთვის curl გამოძახება აბრუნებს შესაძლებლობების XML-ს, რომელსაც QGIS გააანალიზებდა, ამიტომ ამ გამოსავალში HTML შესვლის გვერდი მაშინვე ხსნის ცარიელ ფენას.

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

როცა პროექტი ცარიელი ფენებით იხსნება

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

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

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