როგორ მოვემსახუროთ webpack-ის განვითარების სერვერს VPN მისამართზე

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

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

დაიწყეთ სოკეტით და არა კონფიგურაციის ფაილით

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

ss -ltn '( sport = :8080 )'
ss -ltnp | grep node

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

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

აირჩიეთ მიბმის მისამართი იმის მიხედვით, ვის უნდა მიაღწიოს მას

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

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

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

devServer: {
  host: "10.77.0.20",
  port: 8080,
  allowedHosts: ["dev.corp.example"],
}

ამ ფრაგმენტში მისამართი საილუსტრაციოა და აღნიშნავს VPN მისამართს, რომელსაც ჰოსტი ფლობს. თუ პროექტი სერვერს აშენებს new WebpackDevServer(options, compiler)-ით, მაშინ პარამეტრები გადაიტანეთ კონსტრუქტორის არგუმენტით, რადგან ცალკე devServer თვისება webpack-ის კონფიგურაციაში ამ გზაზე არ განიხილება. კონფიგურაციის ფაილსა და Node API-ს შორის ეს განსხვავება იჭერს მათ, ვინც ფრაგმენტს იმ პროექტში აკოპირებს, რომელიც მას არასდროს კითხულობს. dev-server-ის დოკუმენტაცია ჰყოფს გაშვების ორ სტილს და არის ის ცნობარი, რომელთანაც გამოყენებული ვერსია უნდა შემოწმდეს.

შეუსაბამეთ ჰოსტის სახელის შემოწმება თქვენ მიერ დამტკიცებულ სახელებს

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

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

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

ერთად გაამოწმეთ გვერდი და პირდაპირი გადატვირთვის სოკეტი

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

curl -sS -o /dev/null -w "%{http_code} %{remote_ip}\n" http://dev.corp.example:8080/
curl -sS -i http://10.77.0.20:8080/ | head -n 5

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

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