OpenVPN GCE-ზე: დაამატეთ alias IP, სანამ route-ებს push-ს გააკეთებთ

Client ურეკავს OpenVPN სერვერს Compute Engine VM-ზე, სტატუსის ფანჯარა ამბობს დაკავშირებულია, და VPC-ის შიგნით მდებარე host-ზე გაშვებული ping მაინც არსად არ აღწევს. ინსტინქტია კიდევ ერთი push ხაზის დამატება და ეს ამას არასდროს არ ასწორებს. Compute Engine წყვეტს, სად მიდიან packet-ები, საკუთარი route-ების ცხრილით და იმ მისამართებით, რომლებიც VM-ის interface-ს რეალურად აქვს, ამიტომ tunnel pool, რომელიც VM-ს არ ეკუთვნის, არის pool, სადაც არავინ არ აწვდის.

მიჰყევით მომაკვდავ packet-ს და არა კონფიგურაციის ფაილს, და დაკარგული ნაწილები რიგზე გამოჩნდება.

დაიწყეთ მომაკვდავი packet-იდან

SYN ტოვებს client-ს, შედის tunnel-ში და VM-ს აღწევს როგორც ინკაფსულირებული packet VPC-ის შიგნით მდებარე დანიშნულებისთვის. OpenVPN დეკაფსულაციას უკეთებს და ცდილობს eth0-ით გადაცემას, სადაც fabric ყველაფერზე ადრე ერთ კითხვას სვამს: ფლობს თუ არა ეს instance დანიშნულების მისამართს. სხვისი subnet-იდან ამოჭრილი tunnel pool ამ კითხვაზე ვერ გადის, და packet უგულებელყოფილია მანამ, სანამ რომელიმე route ან firewall წესი განიხილება.

ასე რომ, client-იდან VPC-ის მიმართულებას ორი ცალკე მოთხოვნა აქვს და არც ერთი მათგანი push ინსტრუქცია არ არის. VM-ს სჭირდება alias დიაპაზონი, რომელიც ფარავს tunnel pool-ს და სწორედ ეს ხდის მას ამ მისამართების ლეგიტიმურ მფლობელს. VPC-ს სჭირდება route, რომელიც VM-ს ასახელებს next hop-ად ყოველი დაცული prefix-ისთვის. ერთი რომ გამოგრჩეთ, packet სხვა ადგილას კვდება, სანამ client იმავე სიჩუმეს ხედავს.

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

ფლობს თუ არა instance tunnel pool-ს

მიეცით VM-ს მეორადი დიაპაზონი საკუთარი subnet-ის შიგნით და შემდეგ აიძულეთ OpenVPN-ს მისამართები ზუსტად ამ დიაპაზონიდან გასცეს. Instance-ზე, რომლის ძირითადი მისამართია 10.156.0.10/20, /28 alias pool-ს გამოყოფს სხვა instance-ების უკვე არსებული მისამართებისგან:

gcloud compute instances network-interfaces update openvpn-vm \
  --zone=europe-west1-b \
  --aliases=eth0:10.156.1.0/28

შემდეგ server ინსტრუქციამ უნდა აღწეროს იგივე ბლოკი. მისი პირველი მისამართი ხდება tunnel-ის gateway, ხოლო დარჩენილი მისამართები client-ებს ურიგდებათ. აქ ორი რიცხვი ერთ ბლოკს აღწერს, ქსელს და ქსელის ნიღაბს, და ეს არის ის pool სინტაქსი, რომელსაც OpenVPN ჯერ კიდევ ელოდება.

server 10.156.1.0 255.255.255.240

დაადასტურეთ, რომ მისამართი ნამდვილად მოხვდა interface-ზე და არა მხოლოდ OpenVPN-ის კონფიგურაციაში. Fabric გადასცემს იმას, რასაც NIC იტყობინება და არა იმას, რაც daemon-ს სჯერა. ერთი ბრძანება წყვეტს ამას:

ip -4 addr show dev eth0

მეორადი მისამართი, რომელიც არასდროს აღწევს eth0-ს, ან pool, რომელიც სხვა subnet-ს ემთხვევა, მოგვიანებით ვლინდება როგორც წყვეტილი დანაკარგები და არა როგორც გაშვების შეცდომა. Daemon ირთვება, client-ები უერთდებიან და მხოლოდ ზოგიერთი დანიშნულება იქცევა არასწორად. შეინახეთ alias დიაპაზონი პატარა, რომ pool ადვილად ცნობადი იყოს route-ების ცხრილში. არასდროს ამოჭერით ის subnet-იდან, რომელსაც სხვა instance უკვე იყენებს.

მიეცით დაბრუნების traffic-ს next hop

VPC-ის host-იდან პასუხი მისამართიანია tunnel pool-ის client მისამართზე, რომელიც არ ეკუთვნის VPC-ისთვის ცნობილ არც ერთ subnet-ს. ამ pool-ის route-ის გარეშე პასუხი ჩერდება პირველ hop-ზე, სადაც დამთხვევა არ არის, და მოთხოვნა შეიძლება სავსებით წარმატებული ყოფილიყო მეორე ბოლოში.

gcloud compute routes create openvpn-return \
  --network=prod-vpc \
  --destination-range=192.168.127.0/24 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b \
  --priority=800

იგივე route საჭიროა ყოველი prefix-ისთვის, რომელიც client-ის უკანაა და არა VPC-ის შიგნით. ამ prefix-ებს ასევე სჭირდებათ iroute ჩანაწერი იმ client-ის ccd ფაილში. ეს ჩანაწერი server-ის მხრიდან აღრიცხვაა: ის server-ს ეუბნება, რომელი client ფლობს prefix-ს და არაფერს აყენებს თავად client-ზე.

შეინახეთ push სია საუბრის client მხარისთვის, რადგან ის მხოლოდ route-ებს ამატებს დამაკავშირებელ მანქანას. VPC subnet-ის push ხაზი და pool-ში დაბრუნებული VPC route ერთი და იმავე გზის ორი ნახევარია და თითოეული ნახევარი ცალკე ქმნის tunnel-ს, რომელიც მოთხოვნებს ატარებს, მაგრამ არა პასუხებს.

Firewall-ები, გადაცემა და შუალედური hop-ები

VPC-ის firewall აფასებს დეკაფსულირებულ packet-ს, ამიტომ ingress წესმა უნდა გაუშვას tunnel pool და ნებისმიერი site prefix, რომელიც ამ გზით აღწევს VM-ს. Default-deny დამოკიდებულება აქ ჩუმად ვარდება: packet დეკაფსულაციის შემდეგ უგულებელყოფილია და OpenVPN-ის log ჯანსაღ session-ს აჩვენებს.

ნებისმიერ Linux host-ზე, რომელიც გადასცემს და არ ამთავრებს, შეამოწმეთ, ჩართულია თუ არა net.ipv4.ip_forward. საკუთრების წესი იქაც მოქმედებს: მანქანა, რომელიც გადასცემს იმ subnet-ისთვის, რომელიც მას არ აქვს, packet-ს ყრის ზუსტად ისე, როგორც VM გააკეთებდა. წაიკითხეთ მნიშვნელობა, სანამ tunnel-ს დაადანაშაულებთ.

როცა ზუსტად ერთი prefix ვარდება

ნაწილობრივი ხარვეზი ყველაზე ადვილად წასაკითხი შემთხვევაა, რადგან გზაზე ყველაფერი დანარჩენი უკვე დამტკიცებულია. დაიწყეთ route-ების სიით და წაიკითხეთ იმ ჩანაწერის დანიშნულების დიაპაზონი და next hop, რომელმაც უნდა დაფაროს prefix, შემდეგ წაიკითხეთ instance-ის აღწერა და შეადარეთ მისი alias დიაპაზონი server-ის მიერ დარიგებულ pool-ს.

gcloud compute routes list --filter=destination-range~10.164.0.0
 gcloud compute instances describe openvpn-vm --format=get(networkInterfaces[0].aliasIpRanges)

დაკარგული route ვლინდება როგორც next hop-ის არარსებობა prefix-ისთვის, ხოლო დაკარგული alias ვლინდება როგორც interface-ზე გადაგდებული packet; client-იდან ეს ორი მსგავსად გამოიყურება, მაგრამ ამ ორ გამონატანში სრულიად განსხვავებულია. თუ ორივე არსებობს, დარჩენილი ეჭვმიტანილია იმ client-ის ccd iroute, რომელიც prefix-ს ითხოვს.

ჩაწერეთ ოთხი მნიშვნელობა tunnel-ის გვერდით: alias დიაპაზონი, server pool, push-ული prefix-ები, VPC route-ები. მოძველებული alias ამტვრევს pool-ის ყოველ მისამართს, მოძველებული route ამტვრევს ერთ მიმართულებას, დაკარგული push მალავს prefix-ს client-ისგან, ხოლო არასწორი iroute prefix-ს არასწორ peer-თან აგზავნის. შემდეგ ადამიანს, ვინც subnet-ს დაამატებს, ოთხივე ერთ ადგილას სჭირდება და ეს ჩანაწერი საღამოზე იაფია.