ლოკალური მონაცემთა ბაზის კლიენტი და კერძო RDS: რატომ იწურება კავშირის დრო

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

წაიკითხეთ ჩავარდნა სწორ ფენაზე

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

dig +short db.internal.example
nc -vz db.internal.example 5432

თუ სახელი საჯარო მისამართს აბრუნებს, ან არაფერს, გვირაბი ჯერ არ არის პრობლემა.

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

გამოყავით გვირაბი მარშრუტისგან

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

ip route get 10.20.40.15
ip addr show tun0

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

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

შეუსაბამეთ უსაფრთხოების ჯგუფი რეალურ წყაროს

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

aws ec2 describe-security-groups --group-ids sg-0123456789abcdef0 \
  --query 'SecurityGroups[].IpPermissions'

ერთი ლეპტოპის სახლის მისამართის წესი ტექნიკური მომსახურების პრობლემაა და არა წვდომის დიზაინი.

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

ანიჭეთ უპირატესობა ვიწრო გზას ფართოსთან შედარებით

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

ssh -N -L 5432:db.internal.example:5432 bastion.internal.example

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

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

დატოვეთ უკან განმეორებადი გზა

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

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

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