პასუხი LAN-ით გადის, არა გვირაბით: რატომ და როგორ

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

რა განსაზღვრავს სინამდვილეში გამავალ პაკეტს

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

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

რატომ იმარჯვებს ლოკალური ქვექსელი

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

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

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

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

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

აირჩიეთ ცხრილი წყაროს მისამართის მიხედვით

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

ip -6 route add default dev wg0 table 200
ip -6 rule add priority 32000 from 2001:db8:aa::20/128 lookup 200
ip -6 rule add priority 32001 from 2001:db8:aa::20/128 unreachable

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

დაადასტურეთ გზა, შემდეგ სერვისი

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

ip -6 route get 2001:db8:bb::30 from 2001:db8:aa::20

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

რას არ ასწორებს ეს

დატოვეთ გადამისამართება, ცეცხლოვანი კედლის წესები და ICMPv6-ის ქცევა კარიბჭეზე ისე, როგორც იყო, რადგან წყაროს მარშრუტი არცერთ მათგანს არ ცვლის. დაკარგული Packet Too Big შეტყობინება კვლავ ამტვრევს დიდ პასუხებს, რომელი ცხრილიც არ უნდა მოიგოს ძიებამ. გაასწორეთ ეს მარშრუტიზაციის წესების დამატებამდე, თორემ სიმპტომი ცვლილების შემდეგაც გაგრძელდება.

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

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