რატომ ყრის AWS Client VPN ტრაფიკს შესაბამისი მარშრუტის გარეშე

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

Client VPN კლიენტს აძლევს მისამართს, ხელის ჩამორთმევა სრულდება და კავშირი მაინც არსად მიდის. სანამ სერტიფიკატებს ან კლიენტის ვერსიებს შეეხებით, შეხედეთ ბოლო წერტილის საკუთარ მარშრუტების ცხრილს. AWS Client VPN ბოლო წერტილი პაკეტს გადასცემს მხოლოდ მაშინ, როცა მისი ერთ-ერთი მარშრუტი ფარავს დანიშნულების პრეფიქსს; თუ არაფერი ემთხვევა, პაკეტი ბოლო წერტილში იყრება და სამიზნე ჰოსტი SYN-ს ვერასოდეს ხედავს.

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

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

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

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

კლასიკური შეუთანხმებლობა არის დაწყვილებული VPC. ვიღაც ამატებს მარშრუტს 10.20.0.0/24-ისთვის, მაშინ როცა ჰოსტი 10.20.4.0/24-ში ცხოვრობს, ამიტომ მისამართი ყველა ჩანაწერის გარეთ რჩება. კლიენტის მხრიდან ჩაწერა გვიჩვენებს განმეორებით SYN-ებს პასუხის გარეშე, სამიზნის ჟურნალები კი საერთოდ არაფერს აჩვენებს.

წაიკითხეთ მარშრუტების სია სერტიფიკატამდე

ბოლო წერტილის მარშრუტები ცალკე ობიექტია, ამიტომ ჰკითხეთ მათ პირდაპირ VPC-ის ცხრილის წაკითხვის ნაცვლად:

aws ec2 describe-client-vpn-routes --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 --query 'Routes[].{Dest:DestinationCidr,Target:TargetSubnet,Origin:Origin}'

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

ერთი რესურსი თითო დანიშნულებაზე for_each-ით

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

variable "client_vpn_routes" {
  type = map(string)
  default = {
    "10.20.0.0/16"  = "subnet-0aa11bb22cc33dd44"
    "172.31.0.0/20" = "subnet-0aa11bb22cc33dd44"
  }
}

resource "aws_ec2_client_vpn_route" "this" {
  for_each               = var.client_vpn_routes
  client_vpn_endpoint_id = var.client_vpn_endpoint_id
  destination_cidr_block = each.key
  target_vpc_subnet_id   = each.value
  depends_on             = [aws_ec2_client_vpn_network_association.this]
}

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

ისეთი ბოლო წერტილის მიღება, რომელიც თქვენ არ შეგიქმნიათ

გუნდების უმეტესობა კონსოლში აწყობილ ბოლო წერტილს მემკვიდრეობით იღებს, ამიტომ მარშრუტების კოდი არ არსებობს. ნუ აღმართავთ მეორე ბოლო წერტილს მხოლოდ იმისთვის, რომ მარშრუტები Terraform-ში შევიდეს.

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

თვალი ადევნეთ პაკეტს იმ თანმიმდევრობით, რომლითაც ის მოძრაობს

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

  1. მარშრუტი: პრეფიქსი ფარავს დანიშნულებას და მიუთითებს ბოლო წერტილთან დაკავშირებულ ქვექსელზე.
  2. ავტორიზაცია: ავტორიზაციის წესი ნებას რთავს ამ დანიშნულებას მომხმარებლის ჯგუფისთვის. მხოლოდ მარშრუტი არასოდეს იძლევა წვდომას.
  3. დაბრუნების გზა: სამიზნე ქვექსელის მარშრუტების ცხრილი პასუხებს უკან ბოლო წერტილისკენ აგზავნის, ხოლო უსაფრთხოების ჯგუფი პორტს კლიენტის მისამართების პულიდან რთავს.
  4. აპლიკაცია: გახსენით ნამდვილი TCP კავშირი კლიენტიდან, შემდეგ დაადასტურეთ, რომ სამიზნის ჟურნალები აჩვენებს პულიდან მოსალოდნელ წყაროს მისამართს.

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

დაკავშირებული სტატიები