ერთი აპლიკაცია WireGuard-ის გავლით: მიბმა მარშრუტიზაცია არ არის

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

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

მიბმა წყაროს მისამართს აყენებს და მეტს არაფერს

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

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

მიეცით გვირაბს საკუთარი ცხრილი

wg-quick მარშრუტებს იქ აყენებს, სადაც პროფილი ეუბნება. [Interface]-ის ქვეშ Table = 40-ის დამატება მათ ძირითადი ცხრილის ნაცვლად 40 ცხრილში გადაიტანს. ასწიეთ ინტერფეისი და დაადასტურეთ, რომ მივიდნენ: ip -4 route ls table 40-მა უნდა აჩვენოს გვირაბის მარშრუტები, ხოლო ip -4 route get 10.66.127.142 აჩვენებს, როგორ ხსნის ბირთვი ახლა ერთ-ერთ მათგანს. მარშრუტები საკუთარ ცხრილში რომ არიან, ძირითადი ცხრილი დანარჩენი ყველაფრისთვის აგრძელებს მუშაობას.

იგივე გააკეთეთ IPv6-ისთვის, ფართო პრეფიქსის შედარების ნაცვლად. ip -6 rule add from fd00::2/128 lookup 40 ერთ მისამართს ამაგრებს; fc00::/8 შეიძლება ჰოსტის სხვა ინტერფეისებს შეეჯახოს და შექმნას წესი, რომელიც განზრახულზე მეტს ემთხვევა.

დაამატეთ წყაროს წესი და დააკვირდით მთვლელებს

შემდეგ დააკავშირეთ ორი ნახევარი: ip -4 rule add from 10.66.127.142/32 lookup 40, იმავე მისამართით WireGuard-ის ინტერფეისზე დართული. ორივე წესი ჩასვით PostUp-ში, რომ ხელახალი დაკავშირება მათ აღადგენდეს. გადაამოწმეთ რეალური მოთხოვნით და არა პარამეტრით: ip route get 1.1.1.1 from 10.66.127.142-მა უნდა დაასახელოს გვირაბის მოწყობილობა, ხოლო curl --interface wg0 ifconfig.me-მა უნდა შეატყობინოს გვირაბის მისამართი სახლის მისამართის ნაცვლად.

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

საპირისპირო შემთხვევა: შეინარჩუნეთ SSH გვირაბის გარეთ

საპირისპირო პრობლემა ისეთივე გავრცელებულია: wg-quick ფლობს ნაგულისხმევ მარშრუტს და სერვერთან SSH სესია შუაში წყდება. მისი წესები დაბალ პრიორიტეტულ ნომერზე დგას, ამიტომ გამონაკლისი მათზე ადრე უნდა შეფასდეს. ip rule add dport 22 ipproto tcp table main priority 123 ამას ახალ iproute2-ზე აკეთებს; სადაც სელექტორი მიუწვდომელია, მონიშნეთ ნაკადი nftables-ში და ნიშანს დაემთხვიეთ.

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

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