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 қосатын келесі адамға төртеуі де бір жерде керек, ал бұл жазба кешке қарағанда арзан.

Қатысты мақалалар