როგორ გავუშვათ ერთი Linux პროცესი WireGuard-ის გვირაბის გარეთ

თქვენ ვერ გამორიცხავთ პროგრამას სრული გვირაბის მქონე WireGuard ჰოსტიდან მარშრუტების რედაქტირებით. მარშრუტები გზას დანიშნულების მიხედვით ირჩევენ, თქვენ კი პროცესის გამორიცხვა გსურთ, ამიტომ ბირთვს შესადარებელი არაფერი აქვს. სამუშაო მიდგომაა ამ პროცესს მივცეთ საკუთარი ქსელური კონტექსტი: სახელთა სივრცე საკუთარი ინტერფეისით, მისამართებითა და ნაგულისხმევი მარშრუტით, რომელიც veth წყვილით უკავშირდება ჰოსტს. მე ეს გავუშვი Ubuntu 24.04-ზე wireguard-tools 1.0.20210914-ით, და სახელთა სივრცე არასოდეს ყოფილა პრობლემა — პრობლემა ჰოსტის გადაცემის პოლიტიკა და გვირაბის მარკირების წესები იყო.

ჯერ აირჩიეთ თქვენთვის საჭირო კონტექსტის სახეობა

პრაქტიკაში ორი ფორმა გვხვდება. თუ ჰოსტი სრულ გვირაბს უშვებს და ერთი პროგრამა ISP-ის გზით უნდა გავიდეს, თქვენ აშენებთ მეორე სახელთა სივრცეს, უკავშირებთ ჰოსტს და ჰოსტს აძლევთ საშუალებას მისთვის გადასცეს და გადათარგმნოს ტრაფიკი. თუ სახელთა სივრცეს უკვე აქვს VPN ინტერფეისი და თქვენ მხოლოდ მის შიგნით გაშვებული ბრძანება გჭირდებათ, ეს ჩვეულებრივი ip netns exec შემთხვევაა და მარშრუტიზაციის სამუშაოს უმეტესი ნაწილი უკვე დასრულებულია.

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

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

ააშენეთ მეორე კონტექსტი და დაუკავშირეთ ჰოსტს

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

ip netns add clearnet
ip link add veth-clear-out type veth peer name veth-clear-in
ip addr add 192.168.100.1/24 dev veth-clear-out
ip link set veth-clear-out up
ip link set veth-clear-in netns clearnet
ip netns exec clearnet ip addr add 192.168.100.2/24 dev veth-clear-in
ip netns exec clearnet ip link set veth-clear-in up
ip netns exec clearnet ip route add default via 192.168.100.1

ეს სახელთა სივრცე ახლა ჰოსტს აღწევს და სხვა არსად. ჰოსტმა უნდა გადასცეს ტრაფიკი და გადაწეროს წყაროს მისამართი, რადგან 192.168.100.0/24 კერძოა და ზემდგომ მარშრუტიზატორს მასში უკან დაბრუნების მარშრუტი არ აქვს:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o <wan-interface> -j MASQUERADE

სანამ გააგრძელებთ, დაადასტურეთ სახელთა სივრცის მხარე.ip netns exec clearnet ip route უნდა აჩვენოს veth მარშრუტი და ნაგულისხმევი მარშრუტი 192.168.100.1-ის გავლით, და ამ მისამართზე ping-მა უნდა უპასუხოს. თუ ჰოსტის მისამართზე ping ვერ გაიარა, მისამართები ან ბმულის მდგომარეობა არასწორია და არც ერთი firewall წესი არ დაგეხმარებათ.

როცა სახელები წყდება, მაგრამ არაფერი ბრუნდება, წაიკითხეთ FORWARD

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

სანამ რამეს დაამატებთ, წაიკითხეთ ჯაჭვი:

iptables -S FORWARD
nft list chain inet filter forward

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

iptables -A FORWARD -i veth-clear-out -o <wan-interface> -j ACCEPT
iptables -A FORWARD -i <wan-interface> -o veth-clear-out -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
watch -n1 'iptables -L FORWARD -v -n'

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

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

მოარიდეთ გვირაბის მარკირების წესები ახალ გზას

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

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

iptables -t mangle -I PREROUTING -s 192.168.100.0/24 -j RETURN
ip rule add from 192.168.100.0/24 lookup main priority 100

პრიორიტეტი 100 ჩემს ჰოსტზე გვირაბის წესებზე ადრე დგება, ამიტომ ამ წყაროსთვის ჩვეულებრივი ცხრილი წყვეტს. ნუ დააკოპირებთ რიცხვს ბრმად: ის პრიორიტეტები, რომლებსაც wg-quick ამონტაჟებს, განსხვავდება ვერსიებსა და IPv4 და IPv6 კონფიგურაციებს შორის, ამიტომ გაუშვით ip rule show და აირჩიეთ პრიორიტეტი, რომელიც თქვენს მანქანაზე გვირაბის წესებზე ადრე ჯდება.

დაადასტურეთ წყაროზე სპეციფიკური ძებნით წესების სიის ნდობის ნაცვლად:

ip route get 1.1.1.1 from 192.168.100.2
ip netns exec clearnet ip route get 1.1.1.1

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

გაუშვით პროცესი, რომელიც კავშირს ხსნის

ბრძანების გაშვება ერთი ხაზია, მაგრამ გაუშვით პროცესი, რომელიც სოკეტს ნამდვილად ქმნის.ip netns exec clearnet curl -s https://ifconfig.me ყველაზე პატარა პატიოსანი ტესტია: ის აჩვენებს მისამართს, რომელსაც სახელთა სივრცე მსოფლიოს წარუდგენს, და არა იმას, რომელსაც ჰოსტი გამოიყენებდა.

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

[Service]
NetworkNamespacePath=/run/netns/clearnet

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

readlink /proc/$(pgrep -f clearnet-profile | head -1)/ns/net
readlink /run/netns/clearnet

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

სახელების გარჩევას საკუთარი გადაწყვეტილება სჭირდება. სახელთა სივრცის შექმნა მას resolver-ის კონფიგურაციას არ აძლევს; სახელთა სივრცეზე დამოკიდებული ფაილები მხარდაჭერილია /etc/netns/<name>/resolv.conf მეშვეობით, და მის გარეშე თქვენ მემკვიდრეობით იღებთ ქცევას, რომლის არასწორად წაკითხვა ადვილია. IPv6-ს იგივე მოპყრობა სჭირდება: თუ სახელთა სივრცეს v6-ის ნაგულისხმევი მარშრუტი არ აქვს, მაშინ როცა აპლიკაცია v6-ს ანიჭებს უპირატესობას, მოთხოვნები შეიძლება გაჩერდეს უკან დახევამდე, რაც გატეხილ გვირაბს ჰგავს.

შეამოწმეთ ჩარჩო და არა მხოლოდ გასასვლელი მისამართი

მომუშავე საჯარო მისამართი მარშრუტს ამტკიცებს და არა მთელ მოთხოვნას. დანარჩენი ამ თანმიმდევრობით გაიარეთ:

• ip netns exec clearnet ip route get 1.1.1.1 veth-ის ნაგულისხმევ მარშრუტს აჩვენებს და არა WireGuard ინტერფეისს.
• ორივე წესის FORWARD მრიცხველები იზრდება მოთხოვნის შესრულების დროს.
• აპლიკაციის პროცესი აცნობებს იმ სახელთა სივრცის inode-ს, რომელსაც ელოდებით.
• გადატვირთვის შემდეგ სახელთა სივრცე სერვისის დაწყებამდე არსებობს; უფრო ადრე მომუშავე unit მარცხდება ან, რაც უარესია, სახელთა სივრცის გარეთ მუშაობს.

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