რატომ საჭიროებს DNAT 127.0.0.1-ზე განსაკუთრებულ ყურადღებას
გაიგეთ route_localnet, როცა გარე ტრაფიკს გადაამისამართებთ loopback-ზე მიბმულ პროქსი კომპონენტზე.
სერვისი უსმენს 127.0.0.1:1080-ზე. DNAT წესი შემომავალ ტრაფიკს ამ მისამართზე აგზავნის, მაგრამ კავშირი მაინც ვერ დამყარდება. სერვისი შეიძლება ჯანმრთელი იყოს და NAT წესიც ემთხვეოდეს: IPv4 loopback მისამართებს მარშრუტიზაციისას განსაკუთრებული დამუშავება აქვთ.
Linux-ის route_localnet განსაზღვრავს, განიხილება თუ არა 127/8 მისამართები მარსიან მისამართებად მარშრუტიზაციის დროს. ნაგულისხმევი მნიშვნელობა ინარჩუნებს ჩვეულ loopback საზღვარს. კონკრეტული ინტერფეისის გამონაკლისი შეიძლება მნიშვნელოვანი იყოს განზრახ ლოკალური გადამისამართების დიზაინისთვის.
ეს ხსნის, თუ რატომ შეიძლება სხვა მანქანაზე მომუშავე წესი დამოკიდებული იყოს sysctl-ზე, რომელიც არ გადმოგიკოპირებიათ. მაგრამ ეს არ ამართლებს ამ პარამეტრის ყველგან ჩართვას.
უსაფრთხოების დაშვება მარშრუტთან ერთად იცვლება
loopback-ზე მიბმა ხშირად გამოიყენება იმიტომ, რომ დამხმარე კომპონენტს დამოუკიდებელი კლიენტის ავთენტიფიკაცია არ აქვს. თუ სხვა ინტერფეისიდან მომავალი ტრაფიკი იქ შეიძლება მარშრუტირდეს, მხოლოდ მიბმის მისამართი აღარ აღწერს მისაღწევ აუდიტორიას. შეზღუდეთ შემომავალი წყაროები, დანიშნულება და პორტი ფაქტობრივ წესთა ნაკრებში, მათ შორის ტრაფიკი, რომელიც აცხადებს loopback წყაროს ან დანიშნულების მისამართებს, სადაც ეს შესაბამისია.
გადახედეთ ქსელის სახელთა სივრცეს, რომელიც შეიცავს სერვისს. კონტეინერის loopback არ არის ჰოსტის loopback, და ჰოსტის ინტერფეისის პარამეტრის შეცვლა ავტომატურად არ ქმნის მსმენელს კონტეინერში.
rp_filter პასუხობს სხვა კითხვას წყაროს გზის ვალიდაციის შესახებ. მისი გლობალურად გამორთვა არ არის loopback მარშრუტიზაციის გაგების ზოგადი შემცვლელი. ანალოგიურად, ip_nonlocal_bind სოკეტების არალოკალურ მისამართებზე მიბმას ეხება და არა ამ DNAT გზის გამართულობას.
დაბოლოს, გადამისამართებული პროტოკოლი მსმენელს უნდა შეესაბამებოდეს. ნედლი HTTP ან TLS ტრაფიკის SOCKS პორტზე გაგზავნა კვლავ საჭიროებს მთარგმნელს; მარშრუტიზაციის გამონაკლისი ვერ უზრუნველყოფს დაკარგულ მოლაპარაკებას.