FortiGate NAT-ის უკან: local-gw, localid და საჯარო IP

NAT-ის უკან მყოფ FortiGate-ს შეიძლება ჰქონდეს 10.0.0.2 თავის WAN ინტერფეისზე, მაშინ როცა ინტერნეტი მას წარმოადგენს როგორც 198.51.100.40, და ორივე რიცხვი რეალურია. მისამართი, რომელზეც მოწყობილობა იკავშირებს, და იდენტობა, რომელსაც ის აგზავნის IKE ავთენტიფიკაციის დროს, ცალკეული გადაწყვეტილებებია, მიღებული ცალკეულ ველებში, ცალკეული აუდიტორიისთვის. NAT გზაზე გადაწერს გარე მისამართებს, მაგრამ არ გადაწერს ავთენტიფიცირებულ იდენტობას იმად, რასაც შორეული თანატოლი ელოდება. ამ ფორმაში ფაზა 1-ის წარუმატებლობების უმეტესობა სწორი მნიშვნელობის არასწორ ველში ჩასმით ხდება.

სამი მნიშვნელობა, სამი მფლობელი

დაიწყეთ სამი მნიშვნელობის და თითოეულის მფლობელის დასახელებით. local-gw არის მისამართი, რომელსაც FortiGate იყენებს IKE-ის წყაროდ გარე ინტერფეისზე, და ის უნდა იყოს მისამართი, რომელიც მოწყობილობას ნამდვილად აქვს. საჯარო ბოლო წერტილი NAT მოწყობილობის მისამართია და ეკუთვნის მას, ვინც თარგმნას ასრულებს. IKE იდენტობა არის სტრიქონი, რომელსაც თანატოლი თავის კონფიგურაციას ადარებს, და სულაც არ არის აუცილებელი IP მისამართი იყოს.

ველების სახელები საკმარისად ახლოსაა, რომ ჩანაცვლება შესთავაზოს, და ეს არის ხაფანგი. localid და localid-type აღწერენ იდენტიფიკაციას; local-gw აღწერს ლოკალურ მიბმას.

მაგალითი განსხვავებას კონკრეტულს ხდის. FortiGate-ზე გახსენით config vpn ipsec phase1-interface, შემდეგ set interface "wan1" და set local-gw 10.0.0.2 — მისამართი, რომელიც ყუთს აქვს, და სწორედ ეს იწვევს IKE სოკეტის წარმატებულ მიბმას. დატოვეთ local-gw 0.0.0.0 -ზე და გამოყენებული იქნება ინტერფეისის მისამართი, რაც ჩვეულებრივ იგივეა, მაგრამ ნაკლებად ცხადი. არ დააყენოთ local-gw 198.51.100.40 -ზე, რადგან მოწყობილობას ეს მისამართი არ აქვს და სოკეტი მასზე არ მიბმდება. ორი მნიშვნელობის ქაღალდზე თანაბრად ჩვენება კონფიგურაცია არ არის.

ნაბიჯი 1: აირჩიეთ იდენტობა, რომელსაც თანატოლი მიიღებს

ახლა იდენტობა, რაც სხვა გადაწყვეტილებაა. set localid იღებს მნიშვნელობას, რომელსაც თანატოლი შეადარებს, და set localid-type ეუბნება FortiGate-ს, როგორ ინტერპრეტირდეს ის: მისამართი, FQDN, მომხმარებლის FQDN ან გასაღების ID. auto -ით მოწყობილობა მას გამოიყვანს, ჩვეულებრივ გამავალი ინტერფეისის მისამართიდან, რაც ზუსტად ის მნიშვნელობაა, რომლის შეცვლასაც NAT მოწყობილობა აპირებს.

სწორედ ეს გამოყვანაა მიზეზი, რის გამოც ამ ტოპოლოგიაში ცხადი იდენტობა მნიშვნელოვანია. თუ თანატოლი მისამართის იდენტობას ელოდება, დააყენეთ localid-type address და localid იმ საჯარო მისამართზე, რომელსაც თანატოლი დაინახავს, შემდეგ დაადასტურეთ, რომ თანატოლი ამ მნიშვნელობას იდენტობად იღებს და არა მარშრუტიზაციის სამიზნედ. თუ თანატოლი FQDN-ს ელოდება, გამოიყენეთ localid-type fqdn და სახელი, რომლითაც ის კონფიგურირებული იყო. შეამოწმეთ, რა გაიგზავნა სინამდვილეში diagnose vpn ike gateway list -ით, რომელიც აჩვენებს კარიბჭის მდგომარეობას და გამოყენებულ იდენტიფიკატორებს და არა იმას, რისი აკრეფაც გსურდათ. ნუ ჩათვლით, რომ იდენტობის ტიპის ოფცია იღებს თვითნებურ არალოკალურ მისამართს; ჯერ შეამოწმეთ გამოშვების დოკუმენტირებული სემანტიკა.

ნაბიჯი 2: გადაამისამართეთ UDP 500 და 4500 მოწყობილობაზე

მესამე მნიშვნელობა NAT მოწყობილობას ეკუთვნის და სწორედ ის არის, რომლის შემოწმებასაც ადამიანები ივიწყებენ. საჯარო ბოლო წერტილმა უნდა გადაამისამართოს UDP 500 და UDP 4500 FortiGate-ზე, რადგან NAT-T-ის აღმოჩენა და მის შემდეგ მოცემული ინკაფსულირებული ESP ორივე ამ პორტების ჩამოსვლაზეა დამოკიდებული. ეს დიზაინი ერთ-ერთზე შესაბამისობას გულისხმობს; ერთი საჯარო მისამართის პორტებით გაზიარება რამდენიმე თანატოლს შორის სხვა ტოპოლოგიაა, სხვა შეზღუდვებით.

დაადასტურეთ გადამისამართება ჩაწერით და არა იმედით: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 აჩვენებს, მოდის თუ არა პაკეტები და გადის თუ არა პასუხები.

Google Cloud VPN ადოკუმენტებს ერთ-ერთ NAT-ს NAT-T-ით, როგორც NAT-ის უკან მყოფი თანატოლისთვის მხარდაჭერილ განლაგებას, და სწორედ ეს შეზღუდვაა, რომლის მიმართაც უნდა დააპროექტოთ, თუ შორეული მხარე Cloud VPN კარიბჭეა. ერთ-მრავალზე ან პორტებით გაზიარება არ არის იგივე მხარდაჭერილი ტოპოლოგია და ლოკალური იდენტობის არც ერთი კორექტირება ამას არ ცვლის. თუ შორეული მხარე სხვა მოწყობილობაა, მისი საკუთარი დოკუმენტაცია განსაზღვრავს, რას მიიღებს იდენტობად და შეეგუება თუ არა თარგმნილ თანატოლის მისამართს. წაიკითხეთ ეს ლოკალური ველის შეცვლამდე, რადგან ლოკალური მხარე ვერ მოაწყობს მოლაპარაკებას წესზე, რომელსაც შორეული მხარე არ ახორციელებს.

ნაბიჯი 3: შეამოწმეთ, რას არ ხსნის ფაზა 1

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

ამიტომ შეამოწმეთ ფენებად. get vpn ipsec tunnel details აჩვენებს, აწეულია თუ არა გვირაბი და რომელი სელექტორები იქნა მოლაპარაკებული, და შეუთანხმებლობა კონფიგურირებულ შორეულ ქვექსელსა და მოლაპარაკებულ სელექტორს შორის მარშრუტიზაციის პრობლემაა ფაზა 2-ის კოსტიუმში. execute vpn ike gateway clear აიძულებს ხელახალ მოლაპარაკებას, ასე რომ თქვენ ამოწმებთ მიმდინარე კონფიგურაციას და არა სესიას, რომელიც თქვენს ბოლო ცვლილებამდე დამყარდა. შემდეგ გაგზავნეთ ტრაფიკი შორეული პრეფიქსის ჰოსტზე და დაადასტურეთ, რომ მრიცხველები მოძრაობენ, რადგან აწეული და არაფრის გამტარი გვირაბი ზუსტად ისე გამოიყურება, როგორც მუშა, სანამ არ შეამოწმებთ.

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

NAT მოწყობილობის ხელახალი ნუმერაცია არ არის მიზეზი FortiGate-ის local-gw -ის შესახებ, და იდენტობის ცვლილება არ არის მიზეზი რაიმეს ხელახლა დანომრვისა. ორივეს შერევა არის ის, როგორც მუშა გვირაბი აღდგება დაუკავშირებელი ტექნიკური მომსახურების ფანჯრის დროს. Cloud VPN-ის NAT სახელმძღვანელო არის მხარდაჭერილი ტოპოლოგიის ცნობარი იმ მხარეს.

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