HTTP პროქსი, SSH გვირაბი თუ VPN: აირჩიეთ სწორი ფენა

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

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

პროქსი გადაადგილებს მხოლოდ იმას, რაც ესმის

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

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

ssh -D 1080 user@bastion
ssh -L 8443:fileserver.internal:443 user@bastion

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

ვიღაცამ უნდა ამოხსნას სახელი

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

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

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

როცა ქსელი მხოლოდ ერთ გასასვლელს უშვებს

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

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

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

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

გაყალბებული მისამართი ერთ-ერთი ვარიანტი არ არის

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

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

გადაწყვიტეთ პროტოკოლებითა და სახელებით

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

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