OpenVPN на GCE-у: додајте alias IP пре него што push-ујете руте

Push-ована рута не чини VM next hop-ом. Додајте опсег alias IP-а, ускладите га са pool-ом сервера и направите повратну руту у VPC-у пре него што тестирате клијенте.

Клијент се повезује на сервер OpenVPN на VM-у Compute Engine, статусни прозор каже повезано, а ping на host унутар VPC-а ипак не стиже никуда. Инстинкт је додати још један push ред, и то то никада не поправља. Compute Engine одлучује куда пакети иду на основу сопствене табеле рута и адреса које VM интерфејс стварно има, па је pool тунела који VM не поседује pool у који нико не доставља.

Пратите пакет који умире уместо конфигурационе датотеке и делови који недостају појавиће се редом.

Почните од пакета који умире

SYN напушта клијента, улази у тунел и долази до VM-а као упакован пакет за одредиште унутар VPC-а. OpenVPN га распакује и покушава да га проследи кроз eth0, где fabric поставља једно питање пре свега осталог: да ли ова инстанца поседује одредишну адресу. Pool тунела исечен из туђе подмреже на то питање одговара не, и пакет се одбацује пре него што се провери било која рута или firewall правило.

Смер од клијента ка VPC-у има дакле два одвојена захтева и ниједан од њих није push директива. VM-у је потребан alias опсег који покрива pool тунела, и управо то чини VM законитим власником тих адреса. VPC-у је потребна рута која VM наводи као next hop за сваки заштићени префикс. Ако недостаје једно, пакет умире на другом месту, док клијент види исту тишину.

Читајте квар тим редом, јер са стране клијента оба услова изгледају једнако. Тунел који пријављује повезано док ништа не одговара знак је проблема са топологијом, а не лоше шифре.

Да ли инстанца поседује pool тунела

Дајте VM-у секундарни опсег унутар његове сопствене подмреже, а затим нека OpenVPN додељује адресе тачно из тог опсега. На инстанци чија је примарна адреса 10.156.0.10/20, alias /28 држи pool одвојеним од адреса које друге инстанце већ имају:

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

Директива server тада мора да опише исти блок. Њена прва адреса постаје gateway тунела, а преостале адресе деле се клијентима. Овде два броја описују један блок, мрежу и маску, и то је синтакса pool-а коју OpenVPN још увек очекује.

server 10.156.1.0 255.255.255.240

Потврдите да је адреса заиста стигла на интерфејс, а не само у конфигурацију OpenVPN-а. Fabric прослеђује оно што NIC пријављује, не оно што daemon верује. Једна наредба то решава:

ip -4 addr show dev eth0

Секундарна адреса која никада не стигне на eth0, или pool који се преклапа са другом подмрежом, касније се показује као повремени губици, а не као грешка при покретању. Daemon се покреће, клијенти се повезују и само се нека одредишта понашају погрешно. Држите alias опсег малим како би pool у табели рута био лако препознатљив. Никада га не режите из подмреже коју друга инстанца већ користи.

Дајте повратном саобраћају next hop

Одговор са host-а у VPC-у адресиран је на адресу клијента у pool-у тунела, која не припада ниједној подмрежи коју VPC познаје. Без руте за тај 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-а. Ти префикси требају и iroute запис у ccd датотеци тог клијента. Тај запис је књиговодство на страни сервера: говори серверу који клијент поседује префикс и не инсталира ништа на самом клијенту.

Задржите push листу за клијентску страну разговора јер додаје руте само на машину која се повезује. Push ред за подмрежу VPC-а и рута VPC-а назад у pool две су половине истог пута, а свака половина сама ствара тунел који носи захтеве, али не одговоре.

Firewall-ови, прослеђивање и hop-ови између

VPC firewall процењује распакован пакет, па ingress правило мора да пропусти pool тунела и сваки префикс сајта који на тај начин стигне до VM-а. Став default-deny овде тихо затаји: пакет се одбацује након распакивања, а OpenVPN лог показује здраву сесију.

На сваком Linux host-у који прослеђује, а не завршава, проверите да ли је укључен net.ipv4.ip_forward. Правило власништва важи и тамо: машина која прослеђује за подмрежу коју не поседује одбацује пакет једнако као VM. Прочитајте вредност пре него што окривите тунел.

Када закаже тачно један префикс

Делимични квар је најлакше читати јер је све остало на путу већ доказано. Почните са списком рута и прочитајте одредишни опсег и 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)

Рута која недостаје показује се као никакав next hop за префикс, док се alias који недостаје показује као пакет одбачен на интерфејсу; са стране клијента то двоје изгледа слично, а у та два излаза потпуно је различито. Ако су оба присутна, преостали сумњивац је ccd iroute клијента који полаже право на префикс.

Запишите четири вредности поред тунела: alias опсег, pool сервера, push-овани префикси, VPC руте. Застарео alias квари сваку адресу pool-а, застарела рута квари један смер, push који недостаје скрива префикс од клијента, а погрешан iroute шаље префикс погрешном peer-у. Следећа особа која дода подмрежу треба све четири на једном месту, а та белешка је јефтинија од вечери.

Повезани чланци