სერვერის IP-ის შეცვლის შემდეგ SNAT წესი კვლავ ძველს ასახელებს

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

დაკავშირება და გადაგზავნა სხვადასხვა ადგილას იშლება

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

მისამართის ცვლილება მხოლოდ მეორე გადაწყვეტილებას ამტვრევს, და ამიტომ სიმპტომი იკითხება როგორც „დაკავშირებულია, მაგრამ ინტერნეტი არ არის“. ეს ასევე ხსნის, რატომ გამოიყურება კლიენტის მხარეს ჩვეულებრივი შემოწმებები ჯანმრთელად: ხელის ჩამორთმევა სრულდება, კლიენტი იღებს მისამართს, და სერვერის გვირაბის მისამართზე ping-მაც კი შეიძლება უპასუხოს. საათები იხარჯება კლიენტზე იმ გაუმართაობის გამო, რომელიც მეორე მხარეს ცხოვრობს, ამიტომ წესების ცხრილი პირველი ადგილია, სადაც უნდა შევხედოთ.

რედაქტირებამდე წაიკითხეთ წესი და მისი მთვლელები

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

sudo iptables -t nat -L POSTROUTING -n -v --line-numbers
ip -4 addr show

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

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

შეცვალეთ წყარო, ან შეწყვიტეთ ერთის დასახელება

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

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 10.151.0.40

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

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -o eth0 -j MASQUERADE

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

ჩანაცვლების არასწორად გაკეთების ორი გზა

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

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

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

შემომავალ სერვისებს საპირისპირო თარგმანი სჭირდებათ

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

sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 10.9.8.2:8080

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