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-ը երևում է որպես prefix-ի համար next hop-ի բացակայություն, մինչդեռ բացակայող 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 կավելացնի, բոլոր չորսը մեկ տեղում է պետք, և այդ գրառումն ավելի էժան է, քան երեկոն։