VPN კონტეინერის შიგნით ვებ ინტერფეისზე მისვლა: აირჩიეთ პორტის მფლობელი

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

ვის ეკუთვნის პორტის სახელთა სივრცე

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

services:
  vpn:
    image: vpn-client-image
    cap_add: [NET_ADMIN]
    ports:
      - "127.0.0.1:8080:8080"
  app:
    network_mode: "service:vpn"

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

აიძულეთ აპლიკაცია იმ ადგილას მოუსმინოს, სადაც სახელთა სივრცე ელოდება

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

docker compose exec app ss -lntp
docker port vpn
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/

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

აირჩიეთ, როგორ შემოვა მართვის ბილიკი

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

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

გახსენით მართვის პორტი ყველაფრის გახსნის გარეშე

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

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

შეამოწმეთ მართვის მოწყობილობიდან, შემდეგ კიდევ ერთხელ შეამოწმეთ მოგვიანებით

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

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