MariaDB VPN-ით: რომელ user@host-ს ხედავს სერვერი?
ანგარიში ირჩევა მომხმარებლისა და ჰოსტის მიხედვით ერთად. იპოვეთ ის წყარო, რომელიც სერვერმა დაინახა, წაიკითხეთ CURRENT_USER(), შემდეგ შეასწორეთ ის სტრიქონი და არა ნებართვა.
შეიყვანეთ იგივე მომხმარებლის სახელი ორი განსხვავებული გზიდან და MariaDB შეიძლება დაგააუთენტიფიციროს როგორც ორი განსხვავებული ანგარიში. ანგარიშები იკვრება მომხმარებელსა და ჰოსტზე ერთად, ამიტომ 'reporter'@'localhost' და 'reporter'@'10.90.0.23' ცალკე სტრიქონებია ცალკე პაროლებით და ცალკე ნებართვებით. VPN-ის გავლით საინტერესო კითხვა არ არის, რომელი სახელი შეიყვანა მომხმარებელმა, არამედ რომელი წყაროს მისამართი დაინახა სერვერმა.
განსაზღვრეთ წყარო, რომელსაც სერვერი რეალურად ხედავს
იმუშავეთ უკუსვლით მონაცემთა ბაზის ჰოსტიდან და არა ლეპტოპიდან. მისამართი, რომელიც კლიენტს ჰგონია, რომ აქვს, მხოლოდ ერთია რამდენიმე შესაძლებლობიდან:
| Path | Source MariaDB sees |
|---|---|
| Routed tunnel, no translation | The client's inner VPN address |
| Gateway source translation | The gateway's translated address |
| SSH local forward | The SSH server's address |
| Public exit, no tunnel | Whatever the ISP handed out |
გამოიყენეთ სერვერის მხრიდან მტკიცებულებები გადასაწყვეტად. კავშირების ჟურნალი, აქტიური სესიების სია ან საერთო ჟურნალში დროებითი ჩანაწერი გვიჩვენებს იმ მისამართს, რომელიც სერვერმა მიიღო. ლეპტოპის საჯარო IP ბრაუზერიდან სხვა ფაქტია და ხშირად შემცდარი.
შეუსაბამეთ ანგარიში, რომელიც MariaDB-მ აირჩია
ანგარიშის არჩევა მიჰყვება დოკუმენტირებულ წესრიგს და არა ნებართვების გაერთიანებას. ჰოსტის ზუსტ დამთხვევას უპირატესობა აქვს ველურ ნიშანზე, და ანონიმური მომხმარებლის სტრიქონები მონაწილეობენ დამთხვევაში ისე, რაც აოცებს მათ, ვინც თვლის, რომ მხოლოდ სახელი წყვეტს. სერვერი ირჩევს ერთ სტრიქონს; ის არ აერთიანებს ყოველი მსგავსი სახელის სტრიქონის პრივილეგიებს. მითითების ერთხელ წაკითხვა უფრო ღირს, ვიდრე ნახევარი დღე ვარაუდების ცდას.
ეს ნიშნავს, რომ 'reporter'@'%'-ზე ნებართვის დამატებამ შეიძლება ვერაფერი შეცვალოს, თუ სესია აუთენტიფიცირდა როგორც 'reporter'@'10.90.0.23'. შესწორება უნდა დაეცეს იმ სტრიქონს, რომელიც აირჩიეს, ამიტომ ანგარიშის იდენტიფიკაცია წინ უსწრებს ნებართვების რედაქტირებას.
წაიკითხეთ ანგარიში, რომელსაც სესია რეალურად იყენებს
SELECT USER(), CURRENT_USER();
SHOW GRANTS;CURRENT_USER() ასახელებს ანგარიშს, რომელმაც დაააუთენტიფიცირა სესია; USER() იუწყება, რა მოითხოვა კლიენტმა და შეიძლება განსხვავდებოდეს. გაუშვით ისინი როგორც ჩვეულებრივი ზედა დონის მოთხოვნები, და არა განმსაზღვრელი კონტექსტის მქონე შენახული რუტინიდან, თორემ პასუხები აღწერენ რუტინის მფლობელს და არა თქვენს სესიას.
წარუმატებელი შესვლა ვერ შეასრულებს ამიდან არაფერს, და ეს არის ის შემთხვევა, როცა ადმინისტრატორმა უნდა შეამოწმოს ანგარიშების განსაზღვრებები და სერვერის კავშირის მტკიცებულებები. დაგეგმეთ ეს: უარყოფილი შესვლის გამართვის მცდელ ადამიანს ჩვეულებრივ არ აქვს SQL სესია მოსაკითხად.
გამოყავით ხელმისაწვდომობა აუთენტიფიკაციისგან
შეცდომის ტექსტი გეუბნებათ, რომელ ფენაში ხართ. უარყოფილი კავშირი ან დროის ამოწურვა ნიშნავს, რომ კლიენტმა ვერასდროს მიაღწია მსმენელს, ამიტომ ანგარიში და მისი პაროლი ჯერ არ არის კითხვის ნიშნის ქვეშ. წვდომის უარყოფის პასუხი ნიშნავს, რომ სერვერმა უპასუხა, რაც ამტკიცებს ხელმისაწვდომობას და მიუთითებს ანგარიშზე, ჰოსტის დამთხვევაზე ან რწმუნებაზე.
ქსელის წინაპირობები საკუთარი სიაა: მსმენელი, რომელიც მიბმულია განზრახ მისამართზე და არა მხოლოდ loopback-ზე, დაშვებული ტრაფიკი კონფიგურირებულ პორტზე და დაბრუნების მარშრუტი პასუხისთვის. თითოეული დამოუკიდებლად შეიძლება ჩავარდეს, და მომუშავე გვირაბი არც ერთს არ გულისხმობს. loopback-ის მსმენელი იღებს ლოკალურ კავშირებს და უარყოფს ყოველ დისტანციურს, რაც წარმოქმნის უარყოფილ კავშირს, რომელიც ჰგავს firewall-ის ბლოკს.
შეამოწმეთ მიბმის მისამართი, სანამ ქსელის გუნდთან ბილეთს გახსნით. ss -lntp მონაცემთა ბაზის ჰოსტზე გვიჩვენებს, რომელი მისამართი და პორტი რეალურად უსმენს, და ეს ერთი სტრიქონი გამორიცხავს ვარაუდების მთელ კატეგორიას.
შეასწორეთ ვიწროდ, შემდეგ გამოსცადეთ ორივე მიმართულებით
შექმენით განზრახ ჰოსტით კვალიფიცირებული ანგარიში ორგანიზაციის დამტკიცებული პროცესით, საწყობიდან რწმუნებით და არა ბილეთში ჩასმული საერთოთი. მიანიჭეთ მხოლოდ ის სქემის ოპერაციები, რაც დავალებას სჭირდება. წარუმატებელი დისტანციური შესვლის root ანგარიშად, ყველას-მიცემის პოლიტიკად ან ზოგად ველურ ჰოსტად გადაქცევა ტესტს გაატარებს და აშორებს იმ კონტროლს, რომელსაც ამოწმებდით. ნაჩქარევად დამატებული ნებართვა ის არის, რომელსაც შემდეგ არავინ არ ხსნის.
ხელახლა გამოსცადეთ ახალი სესიით განზრახ გზით, შემდეგ შეამოწმეთ უარყოფითი შემთხვევები. გზა, რომელიც უნდა დაიბლოკოს, უნდა დარჩეს დაბლოკილი, და ოპერაცია, რომელიც არ მიენიჭა, უნდა დარჩეს უარყოფილი. ეს ორი შემოწმება გამოჰყოფს შესწორებულ ანგარიშს გაფართოებულისგან.
დაბოლოს, ჩაწერეთ დაკვირვებული წყაროს მისამართი და ანგარიშის სახელი ერთად. გვირაბი უზრუნველყოფს ხელმისაწვდომობას; MariaDB მაინც ირჩევს და ავტორიზებს საკუთარ ანგარიშს, და შემდეგ ადამიანს ორივე ფაქტი სჭირდება თქვენი შედეგის გასამეორებლად.