Dante SOCKS loopback-ზე მხოლოდ WireGuard-ით მომუშავე HTTPS სერვისისთვის

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

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

მაგალითი ვარაუდობს, რომ Dante 1.4.x დაყენებულია როგორც გამოყოფილი, მართული ინსტანცია სანდო Linux სამუშაო სადგურზე, პაკეტის მიერ მოწოდებული სერვისის ანგარიშითა და ლოგირების კონფიგურაციით თავის ადგილზე დატოვებული. სამუშაო სადგური ფლობს 10.77.0.2-ს თავის WireGuard ინტერფეისზე, აღწევს 10.60.0.20:443-მდე ამ გვირაბით, და სერვისის საკუთარი სახელია app.corp.example.

ნაბიჯი 1: მიაბით მსმენელი მხოლოდ loopback-ზე

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

internal: 127.0.0.1 port = 1080
external: 10.77.0.2
external.protocol: ipv4
clientmethod: none
socksmethod: none

client pass {
    from: 127.0.0.1/32 to: 127.0.0.1/32
}

socks pass {
    from: 127.0.0.1/32 to: 10.60.0.20/32 port = 443
    command: connect
    protocol: tcp
}

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

ამ ნაბიჯის უკან დაბრუნება ინსტანციის გაჩერებაა; კონფიგურაციის ფაილი შეიძლება დისკზე დარჩეს, სანამ უკან აბრუნებთ.

ნაბიჯი 2: დაწერეთ ორი წესი, არა ერთი

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

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

ნაბიჯი 3: შეამოწმეთ მარშრუტი სწორი წყაროდან

external ირჩევს გამავალ წყაროს მისამართს; ის WireGuard მარშრუტს არ აყენებს. მხოლოდ-კითხვითი ძებნა მაგალითის წყაროსა და დანიშნულებისთვის:

ip -4 route get 10.60.0.20 from 10.77.0.2

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

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

ნაბიჯი 4: გამოსცადეთ განზრახული იდენტობით

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

curl --proxy socks5h://127.0.0.1:1080 --noproxy '' https://app.corp.example/

ერთად socks5h, Dante ასრულებს დანიშნულების გარჩევას, მაგრამ Dante ამ სამუშაო სადგურზე მუშაობს, ამიტომ პარამეტრი დამოუკიდებლად არ აგზავნის DNS-ს გვირაბის შორეულ ბოლოში. დამტკიცებულმა გამხსნელმა, რომელსაც Dante იყენებს, უნდა დააბრუნოს დაშვებული მისამართი ამ სახელისთვის. ცარიელი no-proxy სია ხელს უშლის მემკვიდრეობით მიღებულ გამონაკლისს ჩუმად გვერდი აუაროს SOCKS-ს.

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

ნაბიჯი 5: გადაწყვიტეთ რა ხდება, როცა გვირაბი ვარდება

გამოსცადეთ გვირაბის დაკარგვა და ინსტანციის გადატვირთვა სანამ ამას წარმოებას უწოდებთ. ზედამხედველი, რომელიც Dante-ს WireGuard-ის შემდეგ უშვებს, fail-closed მარშრუტიზაციას არ ქმნის და fail-closed DNS-საც არ ქმნის; ორივე უნდა აღსრულდეს ქსელის მფლობელის მეშვეობით. დააკვირდით რას აკეთებს აპლიკაცია, როცა გვირაბი გათიშულია: სუფთა შეცდომა კარგი შედეგია, საჯარო გამხსნელზე ჩუმი დაცემა არა.

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

დაკავშირებული სტატიები