sshuttle სრული VPN-ის წინააღმდეგ: რას ფარავს სინამდვილეში მისი მეთოდი
sshuttle მხოლოდ იმას გადაიტანს, რასაც მისი გადაგზავნის მეთოდი უჭერს მხარს: ჯერ შეამოწმეთ TCP, DNS და UDP დაფარვა, საჭირო ლოკალური უფლება და დისტანციური დამხმარე.
sshuttle-ს ირჩევენ იმიტომ, რომ SSH უკვე მუშაობს და კრიპტოგრაფია ნაცნობად გამოიყურება, და ეს მსჯელობა გამოტოვებს ერთადერთ კითხვას, რომელიც წყვეტს შესაბამისობას. რომელი პაკეტები ტოვებს მოწყობილობას, რომელი ანგარიში გადააქვს მათ მეორე მხარეს და რამდენ ლოკალურ უფლებას მოითხოვს ინსტრუმენტი. ეს სამი პასუხი გადაგზავნის მეთოდის მიხედვით იცვლება, ამიტომ ერთი აპლიკაციისთვის მომუშავე კონფიგურაცია შემდეგზე ჩუმად ჩავარდეს შეიძლება. ქვემოთ მოცემული მიმოხილვა იწყება იმ პროტოკოლით, რომელიც აპლიკაციას ნამდვილად სჭირდება.
დაიწყეთ იმ პროტოკოლით, რომელიც აპლიკაციას სჭირდება
პროტოკოლების მხარდაჭერა sshuttle 2.0-ში დამოკიდებულია არჩეულ მეთოდზე. Linux-ის NAT და nft მეთოდები TCP-სა და DNS-ს უმკლავდებიან, ხოლო TPROXY ზოგად UDP-ს ამატებს. თითოეულ პლატფორმასა და მეთოდს თავისი ზღვრები აქვს, ხოლო macOS სრულიად სხვა მექანიზმით კვეთს. ჩაწერეთ დაყენებული ვერსია, არჩეული მეთოდი და აპლიკაციისთვის საჭირო პროტოკოლები, სანამ რამეს აირჩევთ.
ამიტომ მომუშავე TCP მოთხოვნა ძალიან ცოტას ამტკიცებს UDP აპლიკაციის ან ყოველი DNS მოთხოვნის შესახებ. sshuttle TCP-ს ნაკადებად განიხილავს, სრული IP პაკეტების გვირაბირების ნაცვლად, ამიტომ ჩვეულებრივი VPN-იდან ნასესხები გამტარუნარიანობის დასკვნა აქ არ გადადის. შეადარეთ რეალურად მოქმედი მექანიზმი იმ დატვირთვას, რომელიც რეალურად გაქვთ.
| Approach | What it carries | What it needs locally |
|---|---|---|
| SSH local forward | One explicitly named TCP destination | Nothing beyond the SSH client |
| sshuttle, nft or nat method | TCP and DNS to the routed prefixes | Root or sudo for firewall rules |
| sshuttle, tproxy method | TCP, DNS and general UDP | Root or sudo, and kernel support |
| IP VPN | Routed IP traffic in a tunnel | A client with the required privileges |
რა სჭირდება კლიენტს ლოკალურად
დოკუმენტირებული კლიენტის კონფიგურაცია root-ს ან sudo-ს მოითხოვს, რადგან ის ლოკალურ ჩარევის წესებს აყენებს და არ ქმნის გვირაბის ინტერფეისს. ეს ერთი ფაქტი ცვლის უსაფრთხოების ისტორიას: ასეთი უფლების მქონე პროცესს შეუძლია მთელი მოწყობილობის ტრაფიკი გადაამისამართოს და არა მხოლოდ ერთი აპლიკაციის. მოეპყარით უფლებას, როგორც დიზაინის ნაწილს და არა როგორც ინსტალაციის დეტალს.
დაადასტურეთ, რომელი წესები დააყენა ინსტრუმენტმა და რომ ისინი გაქრება გასვლისას. ჩავარდნილი სესია, რომელიც ჩარევის წესებს ტოვებს, შეიძლება ტრაფიკი შავ ხვრელში გაგზავნოს დიდი ხნის შემდეგ, რაც ოპერატორი დაიჯერებს, რომ კავშირი წავიდა, და სიმპტომი ქსელის გაუმართაობას ჰგავს და არა დარჩენილ წესს.
sudo sshuttle --method nft --dns 172.19.4.0/24
nft list ruleset | grep -i sshuttle
ip routeპირველი ბრძანება ტიპური გამოძახების ფორმაა, რეალურად საჭირო პრეფიქსით. მეორე აჩვენებს, რა დააყენა ინსტრუმენტმა, ხოლო მესამე ადასტურებს, რომ გვირაბის ინტერფეისი არ გამოჩნდა, რაც ამ დიზაინისთვის მოსალოდნელი შედეგია.
რას უშვებს დისტანციური მხარე
დისტანციური მხარე არის ავტორიზებული SSH ანგარიში და თავსებადი Python დამხმარის გარემო. შეზღუდულ გარსში წარმატებული შესვლა ავტომატურად არ იძლევა იმ დამხმარის გაშვების ნებას, და დამხმარის გაშვება რომ შეუძლია ანგარიშს, ავტომატურად არ აღწევს ყველა სამიზნე სერვისამდე. ორივე ფაქტი წვდომის მოთხოვნას ეკუთვნის და არა პრობლემების აღმოფხვრის ჩანაწერებს.
დაიცავით ჰოსტის იდენტურობის შემოწმება და ანგარიშის ავთენტიფიკაცია. უცნობი ჰოსტის გასაღების მიღება იმისთვის, რომ პირველი კავშირი იმუშაოს, ხსნის იმ შემოწმებას, რომ დისტანციური მხარე თქვენ მიერ განზრახული მოწყობილობაა, და ეს აქ უფრო მნიშვნელოვანია, ვიდრე ერთი მიზნისთვის გადაგზავნისას.
შეზღუდეთ დისტანციური ანგარიში სამუშაო პროცესისთვის საჭირო სერვისებით და ეს ფარგლები შეათანხმეთ ჰოსტის ოპერატორებთან. ისინი ნდობის ურთიერთობის ნაწილი არიან და კლიენტის მხარეს არც ერთი პარამეტრი ამას არ ცვლის.
სად გადის ნდობის საზღვარი
პირადი API კავშირის SSH-ით გადაგზავნა არ ანიჭებს უფლებას ყოველ API ოპერაციაზე. აპლიკაციის TLS და აპლიკაციაში შესვლა კვლავ მოქმედებს და ინსტრუმენტს ავთენტიფიკაციის გარეშე მომსახურება უსაფრთხოდ ვერ გახდის. დისტანციური ჰოსტიდან შემდეგი ნახტომიც ავტომატურად არ არის იგივე დაცული სეგმენტი, რაც SSH არხი, რადგან ის მეორე კავშირი დისტანციური ჰოსტის იმ პოლიტიკას მიჰყვება, რაც მას აქვს.
ჩაწერეთ საზღვარი ერთი წინადადებით: ტრაფიკი ამ პრეფიქსებისკენ გადის ამ ანგარიშით იმ ჰოსტზე. თუ წინადადებას გამონაკლისების აბზაცი სჭირდება, დიზაინი იმაზე მეტს აკეთებს, ვიდრე მისი დოკუმენტაცია ამტკიცებს, და იმსახურებს მეორე შეხედვას წარმოებამდე მისვლამდე.
დაამტკიცეთ პროტოკოლების მიხედვით, შემდეგ აირჩიეთ ინსტრუმენტი
შეამოწმეთ თითოეული საჭირო პროტოკოლი უვნებელი მოთხოვნით, მათ შორის გადამწყვეტის გზა და ის მისამართების ოჯახები, რომლებსაც აპლიკაცია იყენებს. ტესტში ჩართეთ გათიშვაც, რათა აპლიკაციის დაშვებული წარუმატებლობის ქცევა ცნობილი შედეგი გახდეს და არა მოულოდნელობა ინციდენტის დროს. სესია, რომელიც მუშაობის დროს სწორად გადასცემდა, არაფერს ამბობს იმაზე, რაც დაცემის შემდეგ ხდება.
რამდენიმე ცალსახად დასახელებული სერვისისთვის ჩვეულებრივი ლოკალური გადაგზავნა უფრო ადვილად სამართავია და უფრო ადვილად აუდიტირებადი. აპლიკაციური ტრაფიკისთვის, რომელიც მის მეთოდს შეესაბამება, sshuttle კანონიერ შუალედურ გზას გვთავაზობს. როცა მოთხოვნა ფართო IP კავშირია, VPN დიზაინი პატიოსანი პასუხია, და არჩევანი მიჰყვება დაფარვასა და ოპერაციულ პასუხისმგებლობას და არა დაშიფვრის ალგორითმების რანჟირებას.