ZeroTier-ის გასასვლელი კვანძი არ მუშაობს? შეამოწმეთ მარშრუტი, NAT და კლიენტი
0.0.0.0/0 მარშრუტი კლიენტში გასასვლელი არ არის. კვანძმა უნდა გადაამისამართოს და თარგმნოს, ქსელმა უნდა გამოაცხადოს მარშრუტი, კლიენტმა კი უნდა მიიღოს ის.
მარშრუტების ცხრილი აჩვენებს ნაგულისხმევ მარშრუტს ZeroTier-ის ინტერფეისით, ქსელი იტყობინება, რომ ონლაინ არის, და ბრაუზერი მაინც გადის ლოკალური ISP-ის მისამართიდან. ეს კომბინაცია გავრცელებულია და ეს კლიენტის შეცდომა არ არის. ნაგულისხმევი მარშრუტი მხოლოდ ამბობს, სად უნდა წავიდეს პაკეტები; მეორე მხარეს რაღაცამ უნდა გადაამისამართოს და თარგმნოს ისინი. სამი ცალკე ნაწილი უნდა იყოს ჭეშმარიტი, სანამ გასასვლელი კვანძი იმუშავებს.
მარშრუტი არსებობს, მაგრამ არაფერი გადის
ჯერ შეამოწმეთ კლიენტის მარშრუტების ცხრილი. default via 10.147.20.5 dev zt0-ის მსგავსი ხაზი ამტკიცებს, რომ მარშრუტი დაყენდა, და არა იმას, რომ დანიშნულება ტრაფიკს მიიღებს. შემდეგი ნახტომი უნდა იყოს წევრი, რომელიც მზადაა და შეუძლია მისი გადამისამართება.
თუ იგივე მოთხოვნა კვლავ ფიზიკური ინტერფეისიდან გადის, კლიენტმა მარშრუტი არ დააყენა, ან დააყენა ისეთი მეტრიკით, რომელიც ლოკალურ ნაგულისხმევს დაუთმო. თუ მოთხოვნა მარშრუტის დაყენების შემდეგ ქრება, გასასვლელი წევრი იღებს პაკეტებს და ვერ ახერხებს მათ გადამისამართებას ან თარგმნას. კლიენტი, რომელიც ფიზიკურ ნაგულისხმევს ინარჩუნებს, გასასვლელს საერთოდ არ უგზავნის პაკეტს.
ეს განსხვავება წყვეტს, სად უნდა იმუშაოთ. საჯარო მისამართის შედარება ცვლილებამდე და შემდეგ ჰყოფს არასოდეს გამოყენებულ მარშრუტს გამოყენებულ და გადაგდებულისაგან, და მოითხოვს ერთ ბრძანებას მთელი კონფიგურაციის გადახედვის ნაცვლად. შეადარეთ სხვა რამის შეცვლამდე, რომ ორივე შედეგი ერთი საწყისი მდგომარეობიდან მოვიდეს.
სამი ნაწილი, რომლებიც ყველა უნდა იყოს ჭეშმარიტი
გასასვლელი ჯაჭვია და ყველაზე სუსტი რგოლი განსაზღვრავს სიმპტომს. ქვემოთ მოცემული ცხრილი ჩამოთვლის რგოლებს იმ თანმიმდევრობით, რომლითაც ისინი ჩვეულებრივ ფუჭდებიან.
| Part | Where it lives | What a failure looks like |
|---|---|---|
| Forwarding and NAT | Exit node kernel and firewall | Traffic arrives, no reply |
| Managed default route | ZeroTier network controller | No default via the tunnel on the member |
| Client acceptance | Member's per-network setting | Route offered but not installed |
| DNS behavior | Client resolver configuration | Pages fail by name, IP works |
პირველი სტრიქონი არის ის, რასაც ოფციის სახელი მალავს. წევრი გასასვლელი ხდება მხოლოდ მაშინ, როცა მისი ბირთვი პაკეტებს გადაამისამართებს ZeroTier-ის ინტერფეისსა და ინტერნეტისკენ მიმართულ ინტერფეისს შორის, და როცა პასუხის გზა უკან გვირაბში ითარგმნება. ამ გადამისამართების გარეშე წევრი პარტნიორია და არა კარიბჭე.
კონტროლერის სტრიქონი ნებართვაა და არა კონფიგურაცია. 0.0.0.0/0-ის წევრის მეშვეობით გამოცხადება ყველა კლიენტს ეუბნება, სად არის გასასვლელი; ეს იმ წევრს ტრაფიკის ტარების უნარს არ აძლევს. ის ასევე არ ამოწმებს, რომ წევრს ინტერნეტამდე მოქმედი გზა აქვს. ZeroTier-ის გასასვლელი კვანძის დოკუმენტაცია იმავე განცალკევებას განიხილავს კვანძს, მარშრუტსა და კლიენტს შორის.
დააყენეთ გასასვლელი კვანძი გადამისამართებისა და თარგმნისთვის
ჩართეთ IPv4-ის გადამისამართება მუდმივად, შემდეგ დაამატეთ წყაროს NAT WAN-ის ინტერფეისიდან გამომავალი ტრაფიკისთვის. ფილტრის წესებმა უნდა დაუშვას გადამისამართებული ნაკადი ორივე მიმართულებით, რადგან გადამისამართება და თარგმნა ნებართვისგან დამოუკიდებელია:
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i zt0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o zt0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPTშეცვალეთ zt0 და eth0 ჰოსტზე არსებული სახელებით; მაგალითის ინტერფეისისთვის შენახული წესი რეალურ ინტერფეისზე პაკეტებს არ მიყვება. ცვლილებები მუდმივი გახადეთ იმ firewall-მენეჯერის მეშვეობით, რომელიც წესებს ფლობს, რადგან ინტერაქტიულ გარსში მიცემული ბრძანება შემდეგ გადატვირთვაზე ქრება.
თუ ჰოსტი ამუშავებს firewall-მენეჯერს, როგორიცაა UFW ან firewalld, დაამატეთ წესები ამ მენეჯერის მეშვეობით და არა iptables-ის ხაზების გვერდით დაწყობით. ერთი და იმავე ჯაჭვების რედაქტირება ორ მფლობელს ქმნის პოლიტიკას, რომელიც ჩატვირთვის თანმიმდევრობაზეა დამოკიდებული. თანმიმდევრობა მნიშვნელოვანია, როცა მენეჯერი საკუთარ ჯაჭვებს ქმნის. შეამოწმეთ კლიენტიდან მენეჯერის ხელახლა ჩატვირთვის შემდეგ და არა მანამდე.
გამოაცხადეთ მარშრუტი და მიიღეთ ის კლიენტში
ქსელის კონტროლერზე დაამატეთ მართული მარშრუტი 0.0.0.0/0-ისთვის, რომლის შემდეგი ნახტომი გასასვლელი წევრის ZeroTier-ის მისამართია. შემდეგ იმ წევრზე, რომელმაც უნდა გამოიყენოს ის, დაუშვით გადაფარვა ამ ქსელისთვის. ნებართვა ლოკალურია: ის სხვა წევრებს არ გადააკონფიგურირებს და კონტროლერს არ ცვლის.
zerotier-cli listnetworks
zerotier-cli set <network-id> allowDefault=1
ip route get 1.1.1.1ბოლო ბრძანებამ უნდა მოგვცეს ZeroTier-ის ინტერფეისი და გასასვლელი წევრის მისამართი. თუ ის კვლავ ფიზიკურ ინტერფეისს იტყობინება, მარშრუტი აკლია ან კონკურენტ ნაგულისხმევს უკეთესი მეტრიკა აქვს.
შეზღუდეთ პარამეტრი მხოლოდ იმ ქსელით, რომელსაც ის სჭირდება. ნაგულისხმევი მარშრუტის მიღების ჩართვა გლობალურად, ან ქსელში, რომელმაც მხოლოდ კერძო ქვექსელი უნდა მოგვცეს, ტრაფიკს აგზავნის გასასვლელით, რომელიც ამისთვის არასოდეს გამოუზომიათ.
გადაამოწმეთ გასასვლელი და შეამოწმეთ მისამართების სხვა ოჯახები
მოითხოვეთ საჯარო მისამართი სერვისისგან, რომელიც წყაროს იტყობინება, და შეადარეთ ის გასასვლელი კვანძის WAN-ის მისამართს. შემდეგ ჩატვირთეთ დასახელებული საიტი, რათა დარწმუნდეთ, რომ DNS კვლავ წყვეტს, და შეამოწმეთ ერთი მნიშვნელოვანი აპლიკაცია და არა მხოლოდ ბრაუზერი.
ორმაგი დასტის კლიენტს შეუძლია გააგრძელოს საკუთარი IPv6-ის ბილიკის გამოყენება, სანამ IPv4 ZeroTier-ით გადის. თუ მიზანი მთელი ტრაფიკის დამალვა ან კონტროლია, საჭიროა ცალკე ::/0 მარშრუტი და IPv6-ის გადამისამართება გასასვლელზე, და IPv4-ის ტესტი მათ შესახებ არაფერს ამბობს.
Linux-ის საპირისპირო ბილიკის ფილტრაციამ შეიძლება კლიენტზე ვალიდური გასასვლელი ტრაფიკიც ჩამოაგდოს. ZeroTier ადასტურებს rp_filter-ის გათვალისწინებას მონაწილე წევრებისთვის; შეცვალეთ ეს პარამეტრი განზრახ და მხოლოდ მას შემდეგ, რაც მარშრუტი და NAT დადასტურდება, და არა როგორც პირველი ექსპერიმენტი.
თუ მოთხოვნა NAS-ზე ან ერთ საოფისე ქვექსელზე წვდომაა, ამ პრეფიქსისთვის მართული მარშრუტი უფრო მცირე და უსაფრთხო ცვლილებაა, ვიდრე სრული გასასვლელი. მთელი დათვალიერების სხვა მოწყობილობით გატარება სხვა გადაწყვეტილებაა, ვიდრე ერთ კერძო რესურსზე მიღწევა, და ის ცალკე გადახედვას იმსახურებს.