WireGuard-ის ხელის ჩამორთმევა მუშაობს, მაგრამ ოფისის ქვექსელი არ პასუხობს

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

AllowedIPs არის წვდომის სიაც და მარშრუტიზაციის ცხრილიც

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

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

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.66.0.1/32, 192.168.50.0/24

გადაცემა და თარგმნა სერვერზე უნდა იყოს

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

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i wg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

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

როცა LAN გადავიდა, წესი კი არა

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

iptables -t nat -n -L POSTROUTING
ip -br addr show

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

NAT-ის უკან მყოფ ორ საიტს შეხვედრის ადგილი სჭირდება

როცა არც ერთი მხარე არ იღებს შემავალ კავშირებს, პრაქტიკული პასუხია პატარა ჰოსტი საჯარო მისამართით და ორი WireGuard ინტერფეისით. თითოეული საიტი გარეთ უკავშირდება, შუა ჰოსტი თითოეული პარტნიორის LAN-ს საკუთარ AllowedIPs-ში ჩამოთვლის, და გადაცემა პაკეტებს ორ გვირაბს შორის გადააქვს. არც ერთი საიტის ფაირვოლში არაფერი არ უნდა შეიცვალოს, ამიტომ ეს დიზაინი ადვილად ვრცელდება.

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

გაყავით ფენები ოთხი შემოწმებით

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

wg show
ip route get 192.168.50.20
tcpdump -ni wg0 icmp
iptables -vnL FORWARD --line-numbers

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