Dante SOCKS VPN-ის გავლით: სრული გვირაბი თუ წყაროზე დაფუძნებული მარშრუტიზაცია
ორი გზა, რომ მხოლოდ SOCKS პროქსი გაატაროთ გვირაბში: ნაგულისხმევი მარშრუტის შეცვლა ან ერთი წყარო-მისამართის საკუთარ ცხრილზე მიბმა. ისინი სხვადასხვაგვარად ფუჭდება.
გსურთ, რომ SOCKS პროქსის ტრაფიკი VPN-ის გავლით გავიდეს, ხოლო ჰოსტის დარჩენილი ნაწილი ჩვეულ ბილიკს ინარჩუნებდეს. ამის ორი დიზაინი არსებობს და ისინი იმით განსხვავდებიან, თუ რა ფუჭდება რაღაცის არასწორად წასვლისას. ერთი ნაგულისხმევ მარშრუტს გვირაბში უშვებს და შემდეგ მას გვერდს უვლის; მეორე მთავარ ცხრილს ხელუხლებლად ტოვებს და ერთ წყარო-მისამართს მეორე ცხრილში აგზავნის. მეორე უფრო სუფთაა და საკუთარი ხაფანგები აქვს.
ორი დიზაინი, ორი განსხვავებული დაზიანების რადიუსი
სრული გვირაბის დიზაინი ის არის, რასაც VPN-კლიენტების უმეტესობა ნაგულისხმევად აკეთებს: ცვლის ნაგულისხმევ მარშრუტს, რომ ყველაფერი გვირაბს მიჰყვეს, შემდეგ კი გამორიცხავს იმას, რაც არ უნდა მოჰყვეს. მისი გააზრება იოლია და ვიწროდ შენარჩუნება ძნელი, რადგან ყოველი ლოკალური სერვისი, რომელსაც დაამატებთ, გვირაბს მემკვიდრეობით იღებს, სანამ არ გამორიცხავთ. მარცხის რეჟიმი ფართოა, რადგან ერთი არასწორი მარშრუტი თან მიაქვს თავად ჰოსტის კავშირსაც.
წყაროზე არჩეული დიზაინი საპირისპირო მიმართულებით მიდის. მთავარი ცხრილი ისე რჩება, როგორც იყო, და ერთი პოლიტიკის წესი კონკრეტული ლოკალური მისამართიდან პაკეტებს გვირაბის ნაგულისხმევის მქონე ცხრილში აგზავნის. სხვა არაფერი იცვლება, რაც ნიშნავს, რომ დაზიანების რადიუსი ერთი მისამართია.
ეს სივიწროვე ამავე დროს შეზღუდვაა: დიზაინი მუშაობს მხოლოდ მაშინ, თუ პროქსის გამავალი პაკეტები ნამდვილად ატარებენ ამ მისამართს.
რას აკეთებს Dante-ის external პარამეტრი
პარამეტრი external ირჩევს მისამართებს, რომლებსაც პროქსი გამავალი კავშირებისთვის იყენებს; ის ბირთვის მარშრუტიზაციის პოლიტიკას არ ეხება. სწორედ ეს განცალკევება ხდის მეორე დიზაინს შესაძლებელს და სწორედ აქ კითხულობენ ადამიანები დოკუმენტაციას არასწორად. external-ის გვირაბის მისამართზე მითითება პროქსის აიძულებს, კავშირების წყაროდ ეს მისამართი გამოიყენოს, შემდეგ კი მარშრუტების ცხრილი წყვეტს, სად წავიდეს ეს პაკეტები.
მსმენელი ცალკე საკითხია. შეზღუდეთ internal მხოლოდ იმ კლიენტებზე, რომლებმაც პროქსი უნდა გამოიყენონ, მოითხოვეთ ავთენტიფიკაცია და პორტი ფაირვოლით დაფარეთ, რადგან ღია მსმენელი VPN-ის გასასვლელის ფუნქცია არ არის.
დაადასტურეთ, რომ კონფიგურირებული მისამართი ნამდვილად ეკუთვნის გვირაბს პროქსის ქსელის სახელთა სივრცის შიგნით.
წყაროზე არჩეული ცხრილის აგება
TUN მისამართისთვის 10.90.0.2/24, მისაწვდომი მეწყვილეთი 10.90.0.1-ზე, და ცხრილის ნომრით, რომელსაც სხვა არაფერი იყენებს, განლაგება ასეთია:
ip -4 route add table 100 10.90.0.0/24 dev tun0 src 10.90.0.2
ip -4 route add table 100 default via 10.90.0.1 dev tun0 metric 10
ip -4 route add table 100 unreachable default metric 32760
ip -4 rule add priority 1000 from 10.90.0.2/32 lookup 100
მიუწვდომელი მარშრუტი ის ნაწილია, რომელსაც ხალხი გამოტოვებს. მის გარეშე ცხრილი, რომლის გვირაბის მარშრუტიც ქრება, ჩვეულებრივ ნაგულისხმევზე გადადის და პროქსი ჩუმად გადის WAN-ით. მასთან ერთად ძიება ვერ სრულდება, რაც ხილული მარცხია ჩუმი გაჟონვის ნაცვლად. წესის პრიორიტეტი ასევე უნდა იყოს ყველაფერზე წინ, რაც ამ წყაროს ემთხვევა.
ეს მნიშვნელობები ერთ ტოპოლოგიას აღწერს. point-to-point მეწყვილეები, net30 მისამართები და კლიენტები, რომლებიც სხვა პრეფიქსს ანიჭებენ, ყველას საკუთარი მარშრუტები სჭირდება, ამიტომ ფორმა გადაიტანეთ და არა მისამართები.
სად ჟონავს წყაროს წესი
წყარო-მისამართზე მორგებული წესი ყველა პროცესზე მოქმედებს, რომელიც მას იყენებს და არა მხოლოდ პროქსიზე. თუ სხვა დემონი იმავე მისამართს იკავებს, მისი ტრაფიკიც გვირაბში გადის და მარცხი დაუკავშირებელი სერვისის პრობლემას დაემსგავსება. მიეცით პროქსის მისამართი, რომელსაც სხვა არაფერი იყენებს, ან დაეთანხმეთ, რომ ფარგლები მისამართია და არა პროცესი.
DNS მეორე გაჟონვაა. რეზოლვერის სოკეტი სულაც არ იყენებს პროქსის external მონაცემთა კავშირის წყაროს, ამიტომ სახელების ძიება მაინც შეიძლება WAN-ით გავიდეს. რეზოლუცია კავშირის დამყარებისგან ცალკე შეამოწმეთ და გადაწყვიტეთ, მისაღებია თუ არა ეს შედეგი.
IPv6-ს საკუთარი წესები და მარშრუტები სჭირდება, რადგან IPv4-ის განლაგება ამაზე არაფერს ამტკიცებს.
აირჩიეთ იმ მარცხის მიხედვით, რომელსაც იტანთ
აირჩიეთ სრული გვირაბი, როცა ჰოსტი მთლიანად უნდა იყოს დაცული და გამორიცხვების სიის შენახვა შეგიძლიათ. აირჩიეთ წყაროზე დაფუძნებული მარშრუტიზაცია, როცა ჰოსტმა საკუთარი ბილიკი უნდა შეინარჩუნოს და მხოლოდ ერთი სერვისი უნდა გადამისამართდეს. ორივე ლეგიტიმურია; შეცდომაა აირჩიოთ ერთი და შემდეგ შეამოწმოთ ისე, თითქოს მეორე იყოს.
რომელსაც აირჩევთ, ორივე მხრიდან შეამოწმეთ: მოთხოვნა პროქსის გავლით და პირდაპირი მოთხოვნა ჰოსტიდან, თითოეულისთვის დაკვირვებული გასასვლელი მისამართის ჩაწერით.
თუ გვირაბი ჩავარდა, წინასწარ გადაწყვიტეთ, პროქსი უნდა ჩავარდეს თუ სარეზერვოზე გადავიდეს, და ეს გადაწყვეტილება მარშრუტების ცხრილმა გამოხატოს.