დაუკავშირეთ კერძო LAN-ები მარშრუტიზაციით, სანამ კიდევ ერთ NAT-ს დაამატებთ
გადამფარავი მისამართების სივრცე, დაკარგული უკუგზა ან არასანდო ტრანზიტი წყვეტს არჩევანს მარშრუტიზაციას, NAT-სა და გვირაბს შორის. შეამოწმეთ ეს სამი ფაიერვოლის რედაქტირებამდე.
ორი შიდა ფაიერვოლი, ერთი კერძო ტრანზიტული სეგმენტი და მოთხოვნა, რომ რამდენიმე ჰოსტს თითოეულ LAN-ში შეეძლოს მეორესთან საუბარი. რეფლექსია VPN-ის აწევა ან მეორე NAT შრის დამატება, და ორივე რეფლექსი უფრო ძვირია, ვიდრე პრობლემა იმსახურებს. ჩვეულებრივი მარშრუტიზაცია საკმარისია, როცა სამი პირობა სრულდება: მისამართების დიაპაზონები არ გადაიფარება, ორივე მხარეს შეუძლია ტრაფიკის დაბრუნება მეორე LAN-ში და ტრანზიტული სეგმენტი უკვე საკმარისად სანდოა მონაცემებისთვის. შეამოწმეთ ეს სამი, სანამ რაიმეს დააპროექტებთ, რადგან თითოეული პასუხს ცვლის.
სამი პირობა, რომელიც განსაზღვრავს დიზაინს
პირველი პირობა მისამართების სივრცეა. თუ ორივე LAN იყენებს ერთსა და იმავე RFC 1918 ბლოკს, მარშრუტიზაცია ვერ განასხვავებს მათ და თარგმნა გარდაუვალი ხდება, არა არჩევითი. მეორე უკუგზაა: მარშრუტი A-დან B-მდე უსარგებლოა, თუ B-მაც არ იცის, როგორ მიაღწიოს A-ს LAN-ს, და ასიმეტრიული ცოდნა ყველაზე გავრცელებული მიზეზია, რის გამოც მარშრუტიზებული დიზაინი ჩუმად კარგავს პასუხებს.
მესამე ნდობაა. მარშრუტიზაცია პაკეტებს გადაადგილებს; ის მათ არ იცავს. კერძო ტრანზიტული სეგმენტი ერთი შენობის შიგნით სხვა რამაა, ვიდრე პროვაიდერისთვის გადაცემა ან ბმული, რომელიც საერთო კამპუსის ხერხემალს კვეთს. თუ სეგმენტი სანდო არ არის, პასუხი გვირაბია ორ ფაიერვოლს შორის, და ქვემოთ მოცემული მარშრუტიზაციის გეგმა მის შიგნითაც მოქმედებს.
მარტივი დიზაინი იმარჯვებს მხოლოდ მაშინ, როცა სამივე ერთი მიმართულებით მიუთითებს. როცა ერთი მათგანი ვარდება, გაასწორეთ სწორედ ის პირობა ცალსახად, ნაცვლად იმისა, რომ თარგმნით დაფაროთ, რადგან NAT წარუმატებლობას მალავს და არ ხსნის.
ააგეთ მარშრუტის გეგმა ტრანზიტულ ქსელზე
მიეცით თითოეულ ფაიერვოლს მისამართი საერთო სეგმენტზე და დაამატეთ თითო კონკრეტული მარშრუტი ყოველი შორეული LAN-ისთვის. არსებულ კონფიგურაციაში სხვა არაფერი უნდა გადაადგილდეს და განსაკუთრებით ინტერნეტის ნაგულისხმევი მარშრუტი ზუსტად იქ უნდა დარჩეს, სადაც არის. ნაგულისხმევი მარშრუტის პარტნიორი ფაიერვოლით შეცვლა ყოველ უკავშირო დანიშნულებას ტრანზიტზე გაგზავნიდა, რაც გაცილებით დიდი ცვლილებაა, ვიდრე მოთხოვნილი. pfSense-ის სტატიკური მარშრუტიზაციის დოკუმენტაცია აღწერს იმავე მარშრუტ-პლუს-კარიბჭის მოდელს ამ პლატფორმისთვის და ეკვივალენტური კონტროლი არსებობს ნებისმიერ ფაიერვოლზე, რომელსაც რეალურად იყენებთ.
| Firewall | Remote LAN | Next hop on the transit |
|---|---|---|
| A | 10.40.0.0/24 | 192.0.2.20 |
| B | 10.30.0.0/24 | 192.0.2.10 |
ფაიერვოლი A ემსახურება 10.30.0.0/24-ს, ხოლო ფაიერვოლი B — 10.40.0.0/24-ს, ორი ტრანზიტული მისამართი კი 192.0.2.0/24-ზეა. თითოეული LAN ჰოსტი ინარჩუნებს თავის ლოკალურ ფაიერვოლს კარიბჭედ, ამიტომ ერთადერთი ახალი მდგომარეობა თითო მარშრუტია თითოეულ მხარეს. Linux-ზე დაფუძნებულ ფაიერვოლზე იგივე გეგმა ასე გამოიყურება და გადაცემა უნდა იყოს ჩართული, თორემ მარშრუტი გადაწყდება, პაკეტი კი გადაიგდება.
sysctl -w net.ipv4.ip_forward=1 ip route add 10.40.0.0/24 via 192.0.2.20 dev eth1 ip route get 10.40.0.15 traceroute -n 10.40.0.15
ფილტრაცია თარგმნისგან ცალკე გქონდეთ
მარშრუტიზაცია და პოლიტიკა სხვადასხვა კონტროლია და სწორედ მეორეში ვარდება რეალურად მარშრუტიზებული დიზაინების უმეტესობა. დაუშვით კონკრეტული წყაროები, დანიშნულებები და სერვისები შესვლის იმ საზღვარზე, რომელსაც პაკეტები რეალურად კვეთს, და გახსოვდეთ, რომ ინტერფეისის იარლიყი, მაგალითად WAN, სახელია და არა განაცხადი ნდობაზე. კერძო ტრაფიკის მატარებელ ტრანზიტულ პორტს შეიძლება ჯერ კიდევ ჩართული ჰქონდეს კერძო მისამართების ბლოკირება ნაგულისხმევად.
შემდეგ შეხედეთ გამავალ თარგმნას, სანამ დაასკვნით, რომ NAT არ ხდება. ავტომატურმა გამავალმა წესებმა შეიძლება გადაწეროს ტრაფიკი, რომელიც არასდროს ყოფილა თარგმნისთვის განკუთვნილი, და ეს ანადგურებს წყაროს მისამართებს, რომლებიც მეორე მხარეს სჭირდება საკუთარი პოლიტიკისა და ჟურნალებისთვის. დაადასტურეთ, რომ შერჩეული ნაკადები ინარჩუნებენ თავდაპირველ მისამართებს, და ხელი არ ახლოთ ინტერნეტის თარგმნის წესებს იმ ტრაფიკისთვის, რომელსაც ისინი ჯერ კიდევ სჭირდება.
iptables -t nat -S POSTROUTING iptables -t nat -L POSTROUTING -n -v tcpdump -ni eth1 -c 5 host 10.40.0.15
როცა NAT პატიოსანი პასუხია
თარგმნა იმსახურებს თავის ადგილს, როცა მისამართების დიაპაზონები ნამდვილად გადაიფარება და გადანომრვა მიუწვდომელია, ან როცა პოლიტიკა მოითხოვს, რომ ერთმა მხარემ დაინახოს ერთი მისამართი და არა ქვექსელი. ასეთ შემთხვევებში განზრახ ერთ-ერთზე ან პორტებით შეზღუდული დაკავშირება ცნობილი შედეგების მქონე დიზაინის გადაწყვეტილებაა და არა გვერდის ავლა.
შედეგი, რომელიც ხმამაღლა უნდა ითქვას, არის ის, რომ მეორე მხარე ვეღარ ხედავს და ვერ ფილტრავს ცალკეულ წყაროებს. ჟურნალები იშლება მთარგმნელ მისამართზე, ჰოსტისეული პოლიტიკა წყვეტს მუშაობას და პრობლემების მოგვარება იქცევა ნადირობად იმაზე, თუ რომელი შიდა ჰოსტი ფლობდა ნაკადს მოცემულ მომენტში. თუ ამ ყველაფერს მნიშვნელობა არ აქვს განსახილველი ტრაფიკისთვის, NAT კარგია.
როცა თავად ტრანზიტია არასწორი ვარაუდი
თუ საერთო სეგმენტი კვეთს პროვაიდერს, საერთო კომუტაციის ქსოვილს ან ნებისმიერ გზას, სადაც სხვა მხარეს შეეძლო ტრაფიკის წაკითხვა, მხოლოდ მარშრუტიზაცია სრული პასუხი არ არის. გვირაბი ორ ფაიერვოლს შორის გაძლევთ კონფიდენციალურობას და პარტნიორის ავთენტიფიკაციას, და მის შიგნით არსებული მარშრუტების ცხრილი იგივე ცხრილია, რომელსაც ტრანზიტზე დაწერდით.
გადაწყვიტეთ ეს პირველი ნაწილის ნდობის კითხვიდან და არა ჩვევიდან, რომ VPN-ები უფრო უსაფრთხოა. გვირაბი უკვე კერძო სეგმენტზე ამატებს ოპერაციულ ხარჯს და კიდევ ერთი ჩავარდნის რეჟიმს ყოველგვარი მოგების გარეშე, მაშინ როცა არასანდო სეგმენტზე მარშრუტიზაცია კონფიდენციალურობას ცვლის იმ სიმარტივეში, რომელსაც ვერ გაწვდებით. ჩაწერეთ, სამი პირობიდან რომელმა განაპირობა არჩევანი, და შემდეგ ინჟინერს ხელახლა განხილვა აღარ დასჭირდება.