MySQL localhost VPN-ის გავლით: ეს მაინც ლოკალურ პროცესს ნიშნავს

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

ნაბიჯი 1: გადაწყვიტეთ, რომელ საბოლოო წერტილამდე უნდა მიაღწიოს ლეპტოპმა

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

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

ნაბიჯი 2: პორტი გადასცეთ მხოლოდ მაშინ, როცა მსმენელი ლოკალური რჩება

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

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:13306:127.0.0.1:3306 [email protected]
ss -ltn 'sport = :13306'

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

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

ნაბიჯი 3: კლიენტი TCP-ზე აიძულეთ

Unix-ზე localhost-ის მიმღები MySQL კლიენტი ნაგულისხმევად Unix სოკეტს ირჩევს, ამიტომ მხოლოდ პორტის შეცვლა შეიძლება მას სოკეტის ძიებაში დატოვოს, რომელსაც თქვენს გადაცემასთან არაფერი აქვს საერთო. გამოიყენეთ გამოკვეთილი TCP პროტოკოლი და loopback მისამართი, რომ კლიენტმა თქვენს გადაცემის პორტზე კავშირი გახსნას.

mysql --protocol=TCP --host=127.0.0.1 --port=13306 --user=DB_USER --password

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

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

ნაბიჯი 4: დაამტკიცეთ, რომელ საბოლოო წერტილამდე რეალურად მიაღწიეთ

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

mysql --protocol=TCP -h 127.0.0.1 -P 13306 -u DB_USER -p -e "SELECT @@hostname, @@port, @@socket"

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

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