ორმაგი დასტის VPN პულები: ორივე ოჯახის მისამართირება strongSwan-ში

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

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

ორი ოჯახი შიგნით, ერთი გზა გარეთ

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

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

მიეცით კლიენტს მისამართი თითოეულ ოჯახში

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

pools {
  pool4 { addrs = 10.90.0.0/24 }
  pool6 { addrs = fd42:90::/64 }
}
connections {
  private-access {
    version = 2
    pools = pool4, pool6
    local  { auth = pubkey  certs = gateway.pem  id = vpn.example.com }
    remote { auth = pubkey  cacerts = ca.pem  vips = 0.0.0.0, :: }
    children {
      private { local_ts = 10.60.0.0/16, fd42:60::/48  remote_ts = dynamic }
    }
  }
}

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

შექმენით თქვენი საკუთარი უნიკალური ლოკალური პრეფიქსი ნიმუშის კოპირების ნაცვლად. ორი ორგანიზაცია, რომლებიც ორივე fd42::/16 დანერგავს მას, აღმოაჩენენ კოლიზიას პირველივე ურთიერთდაკავშირებისას, და ამის დიაგნოსტიკა სასიამოვნო არ არის.

სელექტორები აღწერენ დანიშნულებებს და არა წყაროებს

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

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

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

DNS და პასუხის გზა წყვეტს, დასრულებულად გამოიყურება თუ არა

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

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

შეამოწმეთ ორივე ოჯახი, სანამ დასრულებულს უწოდებთ

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

swanctl --list-sas
swanctl --list-pools
ip -6 addr show scope global
ip -6 route get fd42:60::10

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

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