GCE дээрх OpenVPN: маршрутуудыг push хийхээс өмнө alias IP нэмнэ үү

Push хийсэн маршрут VM-ийг next hop болгодоггүй. Alias IP-ийн хүрээг нэмж, серверийн pool-той тааруулж, клиентүүдийг туршихаас өмнө VPC-ийн буцах маршрутыг үүсгэнэ үү.

Клиент Compute Engine VM дээрх OpenVPN серверт холбогдож, төлөвийн цонх холбогдсон гэж хэлнэ, гэвч VPC доторх хост руу ping одоо ч хаашаа ч хүрэхгүй. Зөн совин дахин нэг push мөр нэмэхийг хэлдэг бөгөөд энэ нь хэзээ ч засдаггүй. Compute Engine пакетууд хаашаа явахыг өөрийн маршрутын хүснэгт болон VM интерфейс үнэхээр эзэмшиж буй хаягуудаар шийддэг тул VM-ийн эзэмшдэггүй tunnel pool нь хэн ч хүргэдэггүй pool юм.

Тохиргооны файлын оронд унаж буй пакетыг дагаарай, тэгвэл дутуу хэсгүүд дарааллаар гарч ирнэ.

Үхэж буй пакетаас эхэл

SYN клиентээс гарч, tunnelд орж, VPC доторх очих газар руу чиглэсэн инкапсуллагдсан пакет хэлбэрээр VM-д хүрнэ. OpenVPN үүнийг задалж, eth0-оор дамжуулахыг оролддог бөгөөд тэнд fabric бүхний өмнө нэг асуулт тавьдаг: энэ instance очих хаягийг эзэмшиж байна уу. Өөр хэн нэгний subnet-ээс тасарсан tunnel pool тэр асуултад унаж, пакет аливаа маршрут эсвэл firewall дүрмийг харахаас өмнө хаягдана.

Тиймээс клиентээс VPC руу чиглэл хоёр тусдаа шаардлагатай бөгөөд аль нь ч push заавар биш. VM-д tunnel pool-ыг хамарсан alias хүрээ хэрэгтэй бөгөөд энэ нь түүнийг эдгээр хаягийн хууль ёсны эзэмшигч болгодог. VPC-д хамгаалагдсан prefix бүрд VM-ийг next hop гэж нэрлэсэн маршрут хэрэгтэй. Нэг нь дутуу бол пакет өөр газар үхэж, клиент ижил чимээгүй байдлыг харна.

Алдааг энэ дарааллаар уншаарай, учир нь клиентийн талаас хоёр нөхцөл ижил харагдана. Юу ч хариулахгүй байхад холбогдсон гэж мэдээлдэг tunnel нь топологийн асуудлын шинж, муу шифрийн шинж биш.

Instance tunnel pool-ыг эзэмшиж байна уу

VM-д өөрийн subnet дотор нэмэлт хүрээ өгч, дараа нь OpenVPN хаягуудыг яг тэр хүрээнээс хуваарил. Үндсэн хаяг нь 10.156.0.10/20 байгаа instance дээр /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 болж, үлдсэн хаягууд клиентүүдэд тараагдана. Энд хоёр тоо нэг блокийг дүрсэлдэг, сүлжээ ба netmask, бөгөөд энэ нь OpenVPN-ийн одоо ч хүлээж буй pool синтакс юм.

server 10.156.1.0 255.255.255.240

Хаяг үнэхээр интерфейс дээр буусан, зөвхөн OpenVPN тохиргоонд үлдээгүй гэдгийг батал. Fabric нь NIC-ийн мэдээлснийг дамжуулдаг, daemon-ийн итгэснийг биш. Нэг команд үүнийг шийднэ:

ip -4 addr show dev eth0

eth0-д хэзээ ч хүрэхгүй нэмэлт хаяг эсвэл өөр subnet-тэй давхцаж буй pool нь дараа нь эхлүүлэх алдаа биш, тасалдалтай алдагдал хэлбэрээр илэрнэ. Daemon ажиллаж, клиентүүд холбогдож, зөвхөн зарим очих газар буруу ажиллана. Alias хүрээг жижиг байлгаснаар pool нь маршрутын хүснэгтэд амархан танигдана. Үүнийг хэзээ ч өөр instance ашиглаж буй subnet-ээс таслах хэрэггүй.

Буцах трафикт next hop өг

VPC дахь хостоос ирэх хариу нь tunnel pool дахь клиентийн хаяг руу илгээгддэг бөгөөд энэ хаяг нь VPC-ийн мэддэг ямар ч subnet-д хамаарахгүй. Тэр pool-д маршрут байхгүй бол хариу нь таарч тохирохгүй эхний 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

Мөн тэр маршрут нь VPC дотор биш, клиентийн ард байгаа аливаа prefix-д хэрэгтэй. Тэдгээр prefix-үүдэд тухайн клиентийн ccd файлд iroute бичлэг мөн хэрэгтэй. Энэ бичлэг нь серверийн талын бүртгэл: серверт аль клиент prefix-ийг эзэмшиж байгааг хэлдэг бөгөөд клиент өөр дээр нь юу ч суулгадаггүй.

Push жагсаалтыг ярианы клиентийн талд үлдээ, учир нь энэ нь зөвхөн холбогдож буй машин руу маршрут нэмдэг. VPC subnet-ийн push мөр болон pool руу буцах VPC маршрут нь нэг замын хоёр хагас бөгөөд аль ч хагас ганцаараа хүсэлт зөөдөг ч хариу зөөдөггүй tunnel үүсгэдэг.

Firewall, forwarding болон хоорондын hop

VPC-ийн firewall нь задалсан пакетыг үнэлдэг тул ingress дүрэм tunnel pool болон энэ замаар VM-д хүрэх аливаа site prefix-ийг зөвшөөрөх ёстой. Default-deny байр суурь энд чимээгүйгээр бүтэлгүйтдэг: пакет задалсны дараа хаягдаж, OpenVPN лог эрүүл session харуулна.

Дамжуулдаг боловч дуусгадаггүй аливаа Linux хост дээр net.ipv4.ip_forward идэвхтэй эсэхийг шалга. Эзэмшлийн дүрэм тэнд ч үйлчилнэ: өөрийн эзэмшдэггүй subnet-ийн төлөө дамжуулдаг машин пакетыг VM шиг хаядаг. Tunnel-ийг буруутгахаас өмнө утгыг унш.

Яг нэг prefix бүтэлгүйтэх үед

Хэсэгчилсэн алдаа нь уншихад хамгийн хялбар тохиолдол, учир нь зам дээрх бусад бүхэн аль хэдийн батлагдсан. Маршрутын жагсаалтаас эхэлж, prefix-ийг хамах ёстой бичлэгийн очих хүрээ болон next hop-ыг уншаад, дараа нь instance-ийн тайлбарыг уншиж, түүний alias хүрээг серверийн тараадаг pool-той харьцуул.

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

Дутуу маршрут нь prefix-д next hop байхгүй хэлбэрээр илэрдэг бол дутуу alias нь интерфейс дээр хаягдсан пакет хэлбэрээр илэрнэ; клиентийн талаас хоёулаа ижил төстэй харагдаж, тэр хоёр гаралтад огт өөр. Хоёулаа байвал үлдсэн сэжигтэн нь prefix-ийг шаардаж буй клиентийн ccd iroute юм.

Дөрвөн утгыг tunnel-ийн хажууд бич: alias хүрээ, серверийн pool, push хийсэн prefix-үүд, VPC маршрутууд. Хуучирсан alias нь pool дахь хаяг бүрийг эвддэг, хуучирсан маршрут нэг чиглэлийг эвддэг, дутуу push prefix-ийг клиентээс нуудаг, буруу iroute prefix-ийг буруу peer руу илгээдэг. Subnet нэмэх дараагийн хүнд дөрвийг нь нэг дор хэрэгтэй бөгөөд энэ тэмдэглэл оройноос хямд.

Холбоотой нийтлэлүүд