ASA hairpin: ინტერნეტიდან გასვლა თუ საიტ-საიტ შორის VPN-ის ფეხი?

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

ორი ფეხი, ერთი ინტერფეისი

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

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

same-security-traffic permit intra-interface

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

ფეხი A: კლიენტს ინტერნეტი სურს

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

object network VPN_POOL
 subnet 10.80.0.0 255.255.255.0
nat (outside,outside) after-auto source dynamic VPN_POOL interface route-lookup

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

ფეხის დანარჩენი ნაწილი ჩვეულებრივია: გამოსადეგი ნაგულისხმევი ან კონკრეტული მარშრუტი გარე ინტერფეისიდან, წვდომის პოლიტიკა, რომელიც ნაკადს უშვებს, და DNS, დამუშავებული თქვენი არჩეული გამხსნელის პოლიტიკის მიხედვით. დაამატეთ route-lookup აქ იმავე მიზეზით, როგორც ქვემოთ, რადგან შესვლისა და გასვლის ინტერფეისები იდენტურია.

ფეხი B: კლიენტს კერძო საიტი სურს

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

nat (outside,outside) source static VPN_POOL VPN_POOL
    destination static SITE_PREFIX SITE_PREFIX route-lookup

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

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

ტესტი, რომელიც გეუბნებათ, რომელი ფეხი ააშენეთ

გამოიყენეთ თავად ASA-ის გზის შეფასება კონფიგურაციის წაკითხვისა და იმედის ნაცვლად. packet-tracer input outside tcp 10.80.0.25 40000 203.0.113.10 443 detailed გვიჩვენებს NAT-ის გადაწყვეტილებას, მარშრუტს და ACL-ის შედეგს ერთი ნაკადისთვის; გაიმეორეთ კერძო დანიშნულებით. თუ NAT-ის ფაზა გადაწერს კერძო-კერძო ნაკადს, თქვენ ააშენეთ ფეხი A იმ პაკეტისთვის, რომელსაც ფეხი B სჭირდებოდა.

კიდევ ორი ბრძანება ხურავს უფსკრულს. show nat detail ბეჭდავს წესების რიგს, რომელსაც packet-tracer მიჰყვა, და show crypto ipsec sa გვიჩვენებს, არსებობს თუ არა სელექტორი მოსალოდნელი წყვილისთვის. დაკარგული SA სელექტორის ან პარტნიორის კონფიგურაციის საკითხია, და არა ის, რისი გამოსწორებაც NAT წესს შეუძლია.

გადაამოწმეთ თითოეული ფეხი იმ ტრაფიკით, რომელსაც ემსახურება

მიიღეთ ფეხი A კლიენტის ჩვეულებრივი საჯარო მოთხოვნით, და მიიღეთ ფეხი B მოთხოვნით რეალურად არსებულ კერძო რესურსზე. შემდეგ გაიმეორეთ თითოეული უარყოფილი რესურსით, რადგან „ნებადართული“ და „წვდომის პოლიტიკით დამტკიცებული“ ერთი და იგივე მტკიცებულება არ არის, და ჰაბიდან წამოსული ping არც ერთ კლიენტის გზას არ ვარჯიშობს.

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