OpenVPN SOCKS5-ზე: ვერსიის, ტრანსპორტისა და DNS-ის შეხამება

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

შეათანხმეთ SOCKS ვერსია ფაირვოლამდე

საზოგადოებრივი OpenVPN socks-proxy-ისთვის SOCKS5-ს საუბრობს. მიუთითეთ ის პროქსიზე, რომელიც მხოლოდ SOCKS4-ს გთავაზობთ და TCP კავშირი გაიხსნება, შემდეგ კი გაჩერდება, რადგან კლიენტი ელოდება პასუხს მისალმებაზე, რომელსაც მეორე მხარე არასოდეს აანალიზებს. გარედან ეს გაჩერება ზუსტად გაფილტრულ პორტს ჰგავს, ამიტომ ვერსიის კითხვა ნებისმიერ ფაირვოლის წესზე ადრე დგას. SOCKS-ის მცოდნე ერთი მოტანა ამას ერთი ბრძანებით წყვეტს.

curl --socks5-hostname 127.0.0.1:9050 gw.lab.example

დასრულებული მოთხოვნა ერთდროულად ორ რამეს ამტკიცებს: პროქსიმ SOCKS მოთხოვნა მიიღო და მან სახელი გადაჭრა. URL სქემა არ არის საჭირო, რადგან curl შიშველ ჰოსტს HTTP-ად თვლის, და ეს ამ ტესტისთვის საკმარისია.

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

ტრანსპორტი ორივე მხარეს TCP უნდა იყოს

SOCKS5 აქ TCP ნაკადს ატარებს, ამიტომ თავად გვირაბს proto tcp-client სჭირდება. პროფილი, რომელიც ჯერ კიდევ UDP-ზეა, ამ გზით არ იმუშავებს, რადგან კლიენტი პროტოკოლის UDP ასოციაციის რეჟიმს არ იყენებს. პროფილის გადაბრუნება ნამდვილი ცვლილებაა და არა ფორმალობა: შორეულმა მხარემ იმავე პორტზე TCP უნდა მოუსმინოს. შემდეგ დატვირთვა TCP-ში TCP ხდება, სადაც დაკარგული სეგმენტი ორჯერ ხელახლა იგზავნება და ტემპი უარესდება, რასაც ინტერაქტიური სესიები ბევრად უფრო ძლიერად გრძნობენ, ვიდრე დიდ გადაცემებს.

proto tcp-client
remote gw.lab.example 8443
socks-proxy 127.0.0.1 9050

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

მთელი ჯაჭვი ერთ კონტეინერში ჩასვით

ჯაჭვის ჰოსტზე კეთება ნიშნავს მისი ნაგულისხმევი მარშრუტის ხელში ჩაგდებას და გამხსნელის ისეთ მდგომარეობაში დატოვებას, რომელსაც მოგვიანებით ვერავინ ახსნის. სახელთა სივრცე ან კონტეინერი მას ზღუდავს, ამიტომ ჰოსტი თავის გზას ინარჩუნებს, ხოლო SOCKS ნაბიჯი და გვირაბი ერთად ცხოვრობენ. მის შიგნით ვერაფერი ადგება გვირაბის მოწყობილობის, მისი კონფიგურაციის უფლების და მისაწვდომი პროქსის გარეშე. Compose სერვისი ამას cap_add: NET_ADMIN-ით და bind-მიბმული /dev/net/tun-ით იღებს.

cap_add:
  - NET_ADMIN
devices:
  - /dev/net/tun:/dev/net/tun

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

სახელის გარჩევაა ის ადგილი, სადაც იზოლაცია ვარდება

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

docker compose exec vpn cat /etc/resolv.conf
docker compose exec vpn getent hosts internal.lab.example

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

დაამტკიცეთ თითოეული ნაბიჯი რიგით

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

curl --socks5-hostname 127.0.0.1:9050 gw.lab.example
docker compose exec vpn ip route get 203.0.113.10
docker compose exec vpn getent hosts internal.lab.example

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

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