პოლიტიკური მარშრუტიზაცია SOCKS-ის წინააღმდეგ: რომელი შრე ახდენს სინამდვილეში პროქსირებას

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

მარშრუტიზაცია, DNAT და SOCKS სხვადასხვა რამეს ცვლიან

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

ip route add default via 10.50.0.2 table 101
ip rule add from 10.77.0.2 lookup 101

ამის შემდეგ ბირთვი პაკეტს 10.50.0.2-ს გადასცემს და თავდაპირველი დანიშნულება ჯერ კიდევ IP სათაურშია. თუ 10.50.0.2 მარშრუტიზატორია, ის პაკეტს გადაამისამართებს. თუ ეს ჰოსტია SOCKS დემონით 1080-ზე, პაკეტი არ არის მიმართული იმაზე, რაც მას მიიღებს, და DNAT 1080 პორტზე არც ამას შველის, რადგან გარდაქმნილი პაკეტი კვლავ ატარებს აპლიკაციის თავდაპირველ დატვირთვას SOCKS მისალმების ნაცვლად.

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

პირველი შემთხვევა: აპლიკაციას თავად შეუძლია SOCKS-ზე საუბარი

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

curl --socks5 10.50.0.2:1080 https://docs.example.com
curl --socks5-hostname 10.50.0.2:1080 https://internal.example.com

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

მეორე შემთხვევა: ადაპტერი, რომელიც IP ნაკადებს პროქსის სესიებად გარდაქმნის

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

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

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

მესამე შემთხვევა: ჰოსტი სინამდვილეში მარშრუტიზებული კარიბჭეა

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

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

ss -ltnp 'sport = :1080'
tcpdump -ni eth0 -X 'tcp port 1080'

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

აირჩიეთ შრე ოთხი კითხვით

აქვს პროგრამას პროქსის პარამეტრი? გამოიყენეთ და აქვე გაჩერდით. შეიცავს ტრაფიკი UDP-ს ან ICMP-ს, რომლებიც უნდა გადარჩეს? ICMP-ს მხოლოდ მარშრუტიზებული ან NAT კარიბჭე ატარებს, ხოლო UDP-ს სჭირდება SOCKS5 ასოციაცია, რომელსაც ორივე მხარე მხარს უჭერს. უნდა დაიფაროს მანქანის ყველა პროცესი, მათ შორის ისინი, რომლებსაც ვერ აკონფიგურირებთ? მაშინ გჭირდებათ ადაპტერი, რომელიც ინტერფეისს ფლობს და ნაკადებს ამთავრებს. შეგიძლიათ აიღოთ მისი მარშრუტიზაცია, DNS და მარყუჟების თავიდან აცილების გამონაკლისებიც? თუ არა, ჩვეულებრივი კარიბჭე ნაკლები დაჯდება ექსპლუატაციაში.

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