LAN სერვისის გამოქვეყნება VPN კარიბჭის საკუთარ მისამართზე

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

დაიწყეთ კლიენტის თვალსაზრისით

ამ მაგალითში კლიენტი VPN აუზში, 10.62.0.0/24-შია და უკავშირდება 10.62.0.1-ს 8080 პორტზე. ეს მისამართი თავად კარიბჭეს ეკუთვნის, ამიტომ პაკეტი კარიბჭის ბირთვში ხვდება და არა სხვა პარტნიორთან. კარიბჭის უკან LAN არის 172.21.4.0/24. კარიბჭეს აქვს 172.21.4.10, ხოლო მოწყობილობა, რომელიც რეალურად ემსახურება HTTP-ს, არის 172.21.4.40.

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

შეზღუდეთ დანიშნულების თარგმნა განზრახ

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

iptables -t nat -A PREROUTING -i tun0 -s 10.62.0.0/24 -d 10.62.0.1 -p tcp --dport 8080 -j DNAT --to-destination 172.21.4.40:80

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

დაე, გადამისამართების საზღვარი შეთანხმდეს

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

iptables -A FORWARD -i tun0 -o lan0 -d 172.21.4.40 -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

მოწყობილობამ როგორმე უნდა უპასუხოს

თარგმნის შემდეგ მოწყობილობა ხედავს წყაროს 10.62.0.0/24-ში. მისი პასუხი მიდის მის ნაგულისხმევ კარიბჭეზე, რომელიც LAN-ის მარშრუტიზატორია და არა VPN კარიბჭე, თუ რამე სხვას არ ეუბნება. ორი მოწყობა ასწორებს ამას და ისინი არ არიან ეკვივალენტური. მარშრუტი მოწყობილობაზე ან LAN-ის მარშრუტიზატორზე აგზავნის 10.62.0.0/24-ს 172.21.4.10-ზე და ინარჩუნებს კლიენტის წყაროს. შეზღუდული წყაროს თარგმნა სამაგიეროდ მალავს კლიენტს კარიბჭის LAN მისამართის უკან.

ip route add 10.62.0.0/24 via 172.21.4.10 dev eth1
iptables -t nat -A POSTROUTING -s 10.62.0.0/24 -d 172.21.4.40 -o lan0 -p tcp --dport 80 -j SNAT --to-source 172.21.4.10

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

ნუ შეამოწმებთ თავად კარიბჭიდან

კარიბჭეზე 10.62.0.1-ისკენ შექმნილი მოთხოვნა გადის OUTPUT ჯაჭვით და არა შემავალი PREROUTING-ით. მისი წარუმატებლობა ან წარმატება არაფერს ამბობს კლიენტისკენ მიმართულ წესზე, და ასე აკეთებენ ადამიანები დასკვნას, რომ მომუშავე წესი გატეხილია.

conntrack -L | grep 172.21.4.40
tcpdump -ni any 'port 8080 or port 80'

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