WireGuard-ის ხელის ჩამორთმევა მუშაობს, მაგრამ ინტერნეტი არ არის: მიჰყევით პაკეტს
ხელის ჩამორთმევა მხოლოდ გასაღებებსა და ხელმისაწვდომობას ადასტურებს. მიჰყევით ერთ პაკეტს AllowedIPs-იდან გადაგზავნის, NAT-ისა და უკუგზის გავლით, რომ ნახოთ სად ჩერდება.
გვირაბი აქტიურია, wg show ცოტა ხნის წინანდელ ხელის ჩამორთმევას აჩვენებს, შეგიძლიათ სერვერის გვირაბის მისამართს პინგი გაუკეთოთ, და მის იქით არაფერი პასუხობს. პირველი ინსტინქტი გასაღებების ხელახლა გენერაცია ან კონფიგურაციის ხელახლა გაზიარებაა. ეს ცვლის ზუსტად იმ ნაწილს გზისა, რომლის მუშაობაც უკვე დამტკიცებულია.
დასრულებული ხელის ჩამორთმევა ამბობს, რომ ორი მხარე გასაღებებზე შეთანხმდა, რომ UDP საბოლოო წერტილს აღწევს და რომ კრიპტო მარშრუტიზაცია პაკეტს იღებს. ის არაფერს ამბობს იმაზე, შეუძლია თუ არა პაკეტს შემდეგ სერვერის დატოვება.
ამიტომ გამოცნობის ნაცვლად მიჰყევით ერთ პაკეტს. ოთხი ადგილია, სადაც ის შეიძლება მოკვდეს, და თითოეული განსხვავებულ კვალს ტოვებს.
რას ადასტურებს ხელის ჩამორთმევა სინამდვილეში
WireGuard არის UDP პროტოკოლი, რომელიც Noise ხელის ჩამორთმევით სესიას ამყარებს და შემდეგ პაკეტებს პარტნიორისთვის შიფრავს. როცა wg show რამდენიმე წამის ხელის ჩამორთმევას და მზარდ გადაცემის მრიცხველს აჩვენებს, საბოლოო წერტილი, გასაღებები და პარტნიორის საჯარო გასაღები ყველა სწორია.
რასაც ის არ ადასტურებს: რომ თქვენი კლიენტი საერთოდ აგზავნის ინტერნეტისკენ მიმართულ ტრაფიკს ინტერფეისში, რომ სერვერი მზადაა მისი გადაგზავნისთვის, ან რომ პასუხმა შეიძლება უკანა გზა იპოვოს. ეს kernel-ის მარშრუტიზაციისა და firewall-ის გადაწყვეტილებებია და გვირაბის გარეთ მიიღება.
ამიტომ სერვერის გვირაბის მისამართზე პინგი ასეთი შემცდარი ტესტია. ის პაკეტი მიმართული თავად სერვერზე, ამიტომ ის ლოკალურად სრულდება. მას არასდროს სჭირდება გადაგზავნა, არასდროს თარგმნა და არასდროს ინტერნეტიდან უკუგზა.
AllowedIPs მარშრუტიზაციის გადაწყვეტილებაა
კლიენტზე AllowedIPs ორ საქმეს ასრულებს. ეს არის კრიპტოგასაღების მარშრუტიზაციის ცხრილი, რომელიც წყვეტს, რომელი დანიშნულების მისამართები იგზავნება ამ პარტნიორის გვირაბში, და ეს არის წყაროს მისამართების სია, რომელსაც პარტნიორი მიიღებს თქვენგან. თუ კლიენტის კონფიგურაციაში მხოლოდ 10.8.0.0/24 წერია, საჯარო დანიშნულებები ინტერფეისში არასდროს შედის და თქვენი ჩვეულებრივი ნაგულისხმევი მარშრუტი მათ გვირაბის გარეთ მიჰყავს. მაშინ გვირაბი იდეალურად მუშაობს და არაფერს აკეთებს იმისგან, რაც გსურდათ.
შეხედეთ, რა დააინსტალირა კლიენტმა სინამდვილეში და არა რას ამბობს კონფიგურაციის ფაილი:
wg show wg0 allowed-ipsip route get 1.1.1.1
მეორე ბრძანებაა გადამწყვეტი. თუ პასუხი ასახელებს თქვენს ფიზიკურ ინტერფეისს და ჩვეულებრივ კარიბჭეს, პაკეტი გვირაბში არ მიდის და სერვერის მხრიდან არც ერთი ცვლილება არ გამოასწორებს. დაამატეთ 0.0.0.0/0 IPv4-ისთვის და ::/0 IPv6-ისთვის ცალ-ცალკე; წესი, რომელიც ერთი ოჯახისთვის ყველაფერს იჭერს, მეორეს თავის თავდაპირველ გზაზე ტოვებს, და ეს მუშა IPv4 გვირაბისა და გაჭედილი IPv6 ძიების ხშირი მიზეზია.
სად კვდება პაკეტი კარიბჭეზე
თუ მარშრუტი სწორია და პაკეტი მაინც არსად მიდის, ის სერვერზე აღწევს და იქ ჩერდება. ოთხი შემოწმება ფარავს კარიბჭეების უმეტესობას.
გადაგზავნა. sysctl net.ipv4.ip_forward, რომელიც 0-ს აბრუნებს, კლასიკური პასუხია, და ბევრი დისტრიბუტივი ნაგულისხმევად კვლავ 0-ზეა. ის უნდა იყოს 1 და მუდმივად უნდა დაყენდეს sysctl ფაილში და არა ბრძანებით, რომელიც გადატვირთვისას ქრება. IPv6-ის გადაგზავნა ცალკე გადამრთველია.
ფილტრის პოლიტიკა. ნაგულისხმევი drop პოლიტიკის მქონე FORWARD ჯაჭვი გვირაბის ტრაფიკს გადააგდებს, სამაგიეროდ თავად ჰოსტისკენ ტრაფიკს დაუშვებს, რაც სიმპტომს ზუსტად ემთხვევა. წაიკითხეთ ცოცხალი წესების ნაკრები და არა შენახული ფაილი: nft list ruleset ან iptables -S.
თარგმნა თუ მარშრუტიზაცია. კერძო გვირაბის მისამართების მქონე კლიენტებს სჭირდებათ ან წყაროს NAT სერვერის გამომავალ ინტერფეისზე, ან მარშრუტიზებული პრეფიქსი, რომლის უკან დაბრუნებაც ზედა ქსელმა იცის. არჩევანი მათ შორის მისამართების გეგმას მიჰყვება. MASQUERADE-ის დამატება ქსელში, რომელიც თქვენს პრეფიქსს უკვე უკან მარშრუტიზებს, უვნებელია, მაგრამ უაზრო, ხოლო მისი გამოტოვება იქ, სადაც მარშრუტი არ არსებობს, პასუხებს არამარშრუტიზებად კერძო დიაპაზონზე მიმართული ტოვებს.
უკუგზა. მარშრუტიზებულ დიზაინებში ზედა როუტერს სჭირდება მარშრუტი, რომელიც თქვენს სერვერზე მიუთითებს. პროვაიდერის ქსელსაც შეუძლია ამის დაბლოკვა: რამდენიმე ღრუბელი ჩართავს წყაროსა და დანიშნულების შემოწმებას ინსტანსზე, რომელიც ჩუმად აგდებს პაკეტებს, რომელთა წყარო ინსტანსის საკუთარი მისამართი არ არის, სანამ ეს შემოწმება არ გამოირთვება.
DNS მარშრუტიზაციისგან განსხვავებულად ვარდება
პაკეტი ცნობილ მისამართზე და სახელის ძიება ორი ცალკე მარცხია, და შეცდომის შეტყობინებები საპირისპირო მიმართულებით აცდენენ. თუ ping 1.1.1.1 მუშაობს და ბრაუზერი ვერაფერს იტვირთავს, მარშრუტი წესრიგშია, სახელების გარჩევა კი არა. თუ პინგი თავად ვარდება, DNS უადგილოა და წინა განყოფილებას უბრუნდებით.
wg-quick-ს შეუძლია resolver-ის დაყენება კონფიგურაციის DNS = სტრიქონიდან, და systemd-resolved-ს თითოეული კავშირისთვის საკუთარი ქცევა აქვს. VPN, რომელიც resolver-ს ცვლის მისამართით, რომელიც მხოლოდ გვირაბის შიგნითაა ხელმისაწვდომი, ყოველ ძიებას ჩააგდებს იმ წამს, როცა გვირაბი ვარდება, რაც ისე გამოიყურება, თითქოს გვირაბი ინტერნეტს ამტვრევს.
| Symptom | Layer to inspect |
|---|---|
| Tunnel address pings, nothing else does | Client route, then gateway forwarding |
| Public IP pings, hostnames fail | Resolver selection and reachability |
| Handshake completes, no reply ever | FORWARD policy or missing NAT on the server |
| Small requests work, large transfers stall | MTU and TCP MSS clamping |
თანმიმდევრობა, რომელიც მტკიცებულებას იძლევა
ჯერ კლიენტის მხრიდან შემოწმება ჩაატარეთ, რადგან ეს ერთი ბრძანებაა და შესაძლებლობების ნახევარს გამორიცხავს. შემდეგ დაადასტურეთ, საერთოდ ინტერნეტის გასასვლელადაა სერვერი განკუთვნილი; კერძო წვდომისთვის აშენებული კარიბჭე არ არის გატეხილი, როცა საჯარო დანიშნულებები ვარდება.
სერვერზე დააკვირდით ინტერფეისს, სანამ კლიენტიდან პინგს აგზავნით: tcpdump -ni wg0 icmp უნდა აჩვენოს მოთხოვნა, და tcpdump -ni eth0 icmp უნდა აჩვენოს, რომ ის გადის, თარგმნილი თუ არა. თუ ის პირველზე გამოჩნდება და მეორეზე არასდროს, გაჩერება სერვერზეა ლოკალური. თუ გადის და პასუხი არ ბრუნდება, პრობლემა ზემოთაა, და ეს სხვა საუბარია.
ბოლოს, ისე მოაწყვეთ, რომ შესწორებამ გადატვირთვა გადაიტანოს. გადაგზავნა sysctl ფაილში უნდა იყოს, firewall-ის წესები იმ სერვისში, რომელიც მათ ტვირთავს, და კლიენტის მარშრუტები იმ კონფიგურაციაში, რომელიც ინტერფეისს აწევს, და არა shell-ში, რომელსაც დაივიწყებთ. ხელახლა დაუკავშირდით, გაიმეორეთ იგივე ორი ტესტი და დაადასტურეთ, რომ მრიცხველები მოძრაობენ.