Redsocks loopback-ზე ისმენს, მაგრამ VPN ტრაფიკი არასოდეს აღწევს

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

სად ეშვება გადამისამართებული პაკეტი სინამდვილეში

გამჭვირვალე პროქსი გეითვეიზე იყენებს REDIRECT-ს nat ცხრილში PREROUTING-ზე, რომ შემომავალი კავშირის დანიშნულება ლოკალურ პორტზე გადაწეროს. გადაწერილი დანიშნულება არის ლოკალური მისამართი, როგორც მას ხედავს ის ინტერფეისი, რომელზეც პაკეტი მოვიდა, და არა სხვაგან გაშვებული პროცესის loopback მისამართი. მხოლოდ 127.0.0.1-ზე მიბმული მსმენელი იღებს კავშირებს, რომლებიც უკვე ლოკალური იყო ჰოსტზე, და ეს ზუსტად ის შემთხვევაა, რომელიც აგრძელებს მუშაობას, სანამ გვირაბის ტრაფიკი იშლება. კლიენტის საკუთარი loopback მესამე მისამართია და არასოდეს არის გეითვეის წესის სამიზნე.

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

წაიკითხეთ მსმენელი და გადამისამართების წესი ერთად

ამობეჭდეთ socket-ების ცხრილი და nat წესები ერთ გავლაში, რადგან წესი, რომელიც იმ პორტზე მიუთითებს, რომლის მფლობელიც არავინაა, ზუსტად ისე გამოიყურება, როგორც არასწორ მისამართზე მიუთითებელი წესი. sudo ss -ltnp | grep redsocks აჩვენებს მიბმის მისამართს და მფლობელ პროცესს. sudo iptables -t nat -S PREROUTING აჩვენებს REDIRECT-ის სამიზნეს, და sudo iptables -t nat -L PREROUTING -v -n აჩვენებს, დაემთხვა თუ არა რამე მას.

REDSOCKS-ის სახელწოდების მომხმარებლის ჯაჭვზე გადახტომა არაფერს აღწევს, თუ ეს ჯაჭვი არ არსებობს და არ ატარებს განზრახ გამონაკლისებს და REDIRECT მოქმედებას. წაიკითხეთ ჯაჭვი, რომელზეც ის გადახტება, sudo iptables -t nat -S REDSOCKS-ით, იმის ნაცვლად, რომ ჩათვალოთ, თითქოს სახელი ასრულებს საქმეს.

შემდეგ შეადარეთ ორი მნიშვნელობა. თუ წესი გადამისამართებს გეითვეის მისამართზე 12345 პორტზე და მსმენელი იუწყება 127.0.0.1:12345, შეუსაბამობა ხსნის წარუმატებლობას ყოველგვარი დამატებითი დიაგნოსტიკის გარეშე.

შეაკავეთ ვიწროდ, შემდეგ შეზღუდეთ, რა შეიძლება მივიდეს მასთან

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

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

დაამტკიცეთ ეს კლიენტიდან ახალი კავშირით

შეამოწმეთ რეალური VPN კლიენტიდან ახალი TCP კავშირით და არა გეითვეის shell-იდან. კლიენტზე curl -sS -o /dev/null -w '%{http_code}\n' http://example.com გადის გადამისამართებულ გზას თავიდან ბოლომდე.

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

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