ESP არის IP პროტოკოლი 50 და არა TCP პორტი 50: რა უნდა დავუშვათ
პროტოკოლის ნომრები და პორტის ნომრები სხვადასხვა სახელთა სივრცეებია. TCP პორტი 50-ის წესი არაფერს უშვებს, ხოლო NAT traversal ESP-ს გადაიტანს UDP 4500-ში.
Firewall-ის ფორმები TCP პორტს ითხოვენ და აშკარა პასუხი 50-ია. ეს პასუხი არაფერს უშვებს, რადგან ESP არის IP პროტოკოლი ნომერი 50 და პროტოკოლის ნომრები პორტები არ არის. ორი სახელთა სივრცე მხოლოდ პატარა მთელ რიცხვებს იზიარებს და მეტს არაფერს, და შეცდომა უხილავი რჩება მანამ, სანამ IKE დასრულდება და დაცული ტრაფიკი არასოდეს მოვა.
ორი სახელთა სივრცე, რომლებიც პატარა რიცხვებს იზიარებენ
IP სათაური ატარებს პროტოკოლის ველს, რომელიც ასახელებს შემდეგს: 6 TCP-ისთვის, 17 UDP-ისთვის, 1 ICMP-ისთვის, 50 ESP-ისთვის, 51 AH-ისთვის. TCP ან UDP სათაური ატარებს პორტის ნომრებს, რომლებიც ირჩევენ პროცესს დანიშნულების ჰოსტზე. პროტოკოლი 50 და TCP პორტი 50 უკავშირო მნიშვნელობებია, მაგრამ დიალოგის ფანჯარას შეუძლია ისინი ურთიერთშემცვლელად აჩვენოს.
სწორედ ამიტომ პორტის გადამისამართების წესს არ შეუძლია მშობლიური ESP-ის გამოხატვა. არ არსებობს ESP დანიშნულების პორტი გადასამისამართებლად, და მოწყობილობას, რომელსაც მხოლოდ პორტის წესები ესმის, საერთოდ არ აქვს ლექსიკა ამ პაკეტისთვის. სწორი წესი ნაცვლად ამისა IP პროტოკოლს ასახელებს. პორტის ნებისმიერი დიალოგი ამ პაკეტისთვის არასწორი იარაღია.
დაბნეულობას მეორე ნახევარიც აქვს. როცა პაკეტი დაშიფრულია, მის შიგნით ყველაფერი გაუმჭვირვალეა, მათ შორის თავდაპირველი კავშირის TCP სათაური. Firewall, რომელიც ამ პაკეტზე პორტებს ამოწმებს, გარე სათაურს უყურებს, რომელსაც მშობლიურ შემთხვევაში შესამოწმებელი პორტები არ აქვს.
მშობლიური ESP, შემდეგ შეფუთული ალტერნატივა
მშობლიური ESP პირდაპირ გადაეცემა IP პროტოკოლად, რაც თანაბრად ეფექტური და მოუხერხებელია. ეფექტურია, რადგან დამატებითი სათაური არ არის, და მოუხერხებელია, რადგან მისამართების და პორტების თარგმანს რომელიმე მოწყობილობა ვერ გამოჰყვება. NAT traversal სწორედ ამის გადაჭრისთვის არსებობს: ESP პაკეტს UDP-ში ახვევს, რომ მთარგმნელს გადასაწერი პორტები ჰქონდეს.
| Form on the wire | How it is identified | What the firewall must permit |
|---|---|---|
| IKE negotiation | UDP with a destination port | UDP 500, and 4500 once traversal is detected |
| Native ESP | IP protocol 50 in the outer header | The protocol itself, with no port to name |
| ESP inside UDP | UDP 4500 carrying an ESP payload | The UDP port pair, which translation devices can track |
ორივე ფორმა ერთი და იმავე მონაცემთა არხის ალტერნატიული განლაგებაა და არა ერთის შრეები. მშობლიური ESP-ის დაშვება არ უშვებს შეფუთულ ფორმას, ხოლო UDP 4500-ის დაშვება არ უშვებს მშობლიურ ტრაფიკს, ამიტომ წესების ნაკრები განლაგებას უნდა შეესაბამებოდეს და არა შემთხვევით ორივე დაფაროს.
აღმოჩენას აქაც აქვს მნიშვნელობა. ბოლო წერტილები მოლაპარაკების დროს წყვეტენ ფორმებს შორის, და გადართვა ჩვეულებრივ მაშინ ხდება, როცა მათ შორის NAT აღმოჩნდება. ამიტომ გვირაბის დადგენის შემდეგ შეცვლილმა მარშრუტმა შეიძლება ტრაფიკი გადაიტანოს ისეთ სახელთა სივრცეში, რომელიც თქვენს წესებს არასოდეს დაუფარავს.
წაიკითხეთ, რომელ ფორმას იყენებს კავშირი სინამდვილეში
ჰკითხეთ ბოლო წერტილს და ნუ გამოიცნობთ firewall-იდან. Linux-ში მდგომარეობის ჩანაწერი აცხადებს, იყენებს თუ არა ასოციაცია UDP შეფუთვას და რომელი პორტებია ჩართული. პაკეტის აღება იმავე კითხვას პასუხობს მავთულიდან, და ორივე უფრო სწრაფია, ვიდრე წესების ნაკრების კითხვა და იმედი.
ip xfrm state | grep -A3 encap
tcpdump -ni any 'ip proto 50 or udp port 4500'პირველი ბრძანება აჩვენებს შეფუთვის ტიპს, როცა NAT traversal გამოიყენება, და არაფერს, როცა არ გამოიყენება. მეორე აჩვენებს, ორი ფორმიდან რომელი გადის სინამდვილეში ინტერფეისს, და ეს ამთავრებს კამათს კონფიგურაციაზე, რომელიც ქაღალდზე სწორად გამოიყურება.
საწინააღმდეგო მტკიცებულება იმავე ნაბიჯს ეკუთვნის. წესი, რომელიც ნულოვან დამთხვევას იუწყება, გეუბნებათ, რომ პაკეტი მას არასოდეს მიუღწევია, და ეს მარშრუტიზაციის ან სელექტორის საკითხია და არა firewall-ის.
შემდეგ ცალკე დაადასტურეთ მართვის არხი. IKE-ს აქვს საკუთარი პორტები და საკუთარი ჟურნალები, და მონაცემების გარეშე დასრულებული მოლაპარაკება ზუსტად ის გაყოფაა, რომელზეც ეს სტატიაა.
დაწერეთ წესი სწორ სახელთა სივრცეში
პროტოკოლის წესი და პორტის წესი სხვადასხვა ინსტრუქციაა, ამიტომ იარაღმა ის უნდა გამოხატოს, რაც გულისხმობთ. nftables-ში პროტოკოლის დამთხვევა ცხადია, და შეფუთული ალტერნატივა საკუთარ UDP წესს იღებს. ორი წესი ერთმანეთის გვერდით დაიტოვეთ, რომ წყვილი განხილვისას ჩანდეს.
nft add rule inet filter input ip protocol esp accept
nft add rule inet filter input udp dport { 500, 4500 } acceptწინააღმდეგობა გაუწიეთ ცდუნებას, გააფართოვოთ რომელიმე წესი არასწორი დიაგნოზის კომპენსაციისთვის. ESP პროტოკოლისთვის ყველაფრის დაშვება ყველა ინტერფეისზე, ან UDP-ის დაშვება ნებისმიერიდან ნებისმიერამდე, სიმპტომს ასწორებს და აშორებს იმ კონტროლს, რომლის დაყენებასაც ცდილობდით. ვიწრო მხარდაჭერილი დინება თითქმის ყოველთვის საკმარისია, როცა ფორმა ცნობილია.
და ბოლოს, შრეები სწორად დაიტოვეთ, როცა გვირაბი მუშაობს და აპლიკაცია არა. კარიბჭესთან მისული პაკეტებს კვლავ სჭირდებათ გადაცემა, დაბრუნების მარშრუტი და პოლიტიკა, რომელიც მათ უშვებს, და არც ერთი მათგანი არ გამოიხატება ESP წესით. დაკარგული პორტი კონკრეტულ მარცხს ხსნის და არა ყოველ IPsec მარცხს. წესის შესწორება და მარშრუტიზაციის შემოწმება ორ ცალკე დასკვნად დაიტოვეთ.
ჩაწერეთ დაკვირვებული ფორმა, დამატებული პროტოკოლის წესი და შემდეგ ნანახი მრიცხველი. სამი სტრიქონი, და შემდეგ ადამიანს შეეძლება სახელთა სივრცის შეცდომა მარშრუტიზაციის შეცდომისგან გაარჩიოს წუთში და არა ნახევარ დღეში.