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 кардардан чыгып, туннелге кирет жана VPC ичиндеги максатка арналган инкапсуляцияланган пакет катары VM-ге жетет. OpenVPN аны декапсуляциялап, eth0 аркылуу өткөрүүгө аракет кылат, ал жерде fabric баарынан мурун бир суроо берет: бул инстанс максаттуу дарекке ээби. Башка бирөөнүн subnetинен кесилип алынган tunnel pool бул суроодон өтпөйт, ал эми пакет кандайдыр бир маршрут же firewall эрежеси каралганга чейин ташталат.

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

Бузулууну ушул тартипте окуңуз, анткени кардар тараптан эки шарт бирдей көрүнөт. Эч нерсе жооп бербесе да туташты деп билдирген туннел — топология маселесинин белгиси, начар шифрдин эмес.

Инстанс tunnel poolго ээби

VM-ге өз subnetинин ичинде кошумча диапазон бериңиз, анан OpenVPN даректерди так ошол диапазондон таратсын. Негизги дареги 10.156.0.10/20 болгон инстанста /28 alias poolду башка инстанстар ээлик кылган даректерден бөлүп турат:

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

Анан server нускамасы ошол эле блокту сүрөттөшү керек. Анын биринчи дареги туннелдин 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 маршрут таблицасында оңой таанылат. Аны эч качан башка инстанс колдонуп жаткан 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 маршруту — бир жолдун эки жарымы, ал эми ар кандай жарым жалгыз өзү сурамдарды ташыган, бирок жоопторду ташыбаган туннел жаратат.

Firewallдар, forwarding жана аралык hopтор

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

Өткөргөн, бирок бүтүрбөгөн ар кандай Linux хостто net.ipv4.ip_forward күйүк экенин текшериңиз. Ээлик эрежеси ал жерде да колдонулат: өзүнө тиешелүү эмес subnet үчүн өткөргөн машина пакетти VMдей таштайт. Туннелди күнөөлөөдөн мурун маанини окуңуз.

Так бир prefix ийгиликсиз болгондо

Жарым-жартылай бузулуу — окууга эң жеңил учур, анткени жолдогу калгандын баары мурун эле далилденген. Маршруттар тизмесинен баштап, prefixти камтышы керек болгон жазуунун максат диапазонун жана next hopун окуңуз, анан инстанстын сүрөттөмөсүн окуп, анын 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у.

Төрт маанини туннелдин жанына жазып коюңуз: alias диапазону, сервер poolу, push кылынган prefixтер, VPC маршруттары. Эскирген alias poolдогу ар бир даректи бузат, эскирген маршрут бир багытты бузат, жетишпеген push prefixти кардардан жашырат, ал эми туура эмес iroute prefixти туура эмес peerге жиберет. Subnet кошкон кийинки адамга төртөө тең бир жерде керек, ал эми бул жазуу кечке караганда арзан.

Тектеш макалалар