OpenVPN kwenye GCE: ongeza alias IP kabla ya push routes
Route iliyopush haifanyi VM kuwa next hop. Ongeza safu ya alias IP, ilinganishe na pool ya seva na uunde route ya kurudi kwenye VPC kabla ya kujaribu wateja.
Mteja hupiga seva ya OpenVPN kwenye VM ya Compute Engine, dirisha la hali linasema imeunganishwa, na ping kwa mwenyeji ndani ya VPC bado haifiki popote. Silika ni kuongeza mstari mwingine wa push, na hilo haliwezi kuirekebisha kamwe. Compute Engine huamua pakiti zinaenda wapi kwa kutumia jedwali lake la route na anwani ambazo kiolesura cha VM kinashikilia kweli, kwa hiyo pool ya tunnel ambayo VM haina umiliki wake ni pool ambayo hakuna anayefikisha.
Fuatilia pakiti inayoshindikana badala ya faili ya usanidi, na sehemu zinazokosekana zitaonekana kwa mpangilio.
Anza na pakiti inayokufa
SYN huondoka kwa mteja, huingia kwenye tunnel na kufika kwenye VM kama pakiti iliyofungwa kwa lengo ndani ya VPC. OpenVPN huifungua na kujaribu kuipitisha kwa eth0, ambapo fabric huuliza swali moja kabla ya kila kitu kingine: je, instance hii inamiliki anwani ya lengo. Pool ya tunnel iliyokatwa kutoka subnet ya mtu mwingine haishindi swali hilo, na pakiti hutupwa kabla ya route au kanuni yoyote ya firewall kuzingatiwa.
Hivyo mwelekeo kutoka mteja kwenda VPC una mahitaji mawili tofauti, na hakuna hata moja ni maagizo ya push. VM inahitaji safu ya alias inayofunika pool ya tunnel, na hilo ndilo linaifanya kuwa mmiliki halali wa anwani hizo. VPC inahitaji route inayotaja VM kama next hop kwa kila prefix iliyolindwa. Ikikosekana moja, pakiti hufa mahali pengine, huku mteja akiona ukimya uleule.
Soma hitilafu kwa mpangilio huo, kwa sababu kutoka upande wa mteja masharti yote mawili yanaonekana sawa. Tunnel inayoripoti imeunganishwa wakati hakuna kinachojibu ni alama ya tatizo la topolojia, si ya cipher mbaya.
Je, instance inamiliki pool ya tunnel
Ipe VM safu ya pili ndani ya subnet yake mwenyewe, kisha ifanye OpenVPN igawanye anwani kutoka safu hiyo hasa. Kwenye instance ambayo anwani yake ya msingi ni 10.156.0.10/20, alias ya /28 hutenganisha pool na anwani ambazo instance nyingine tayari zinashikilia:
gcloud compute instances network-interfaces update openvpn-vm \
--zone=europe-west1-b \
--aliases=eth0:10.156.1.0/28Maelekezo ya server basi lazima yaeleze block hiyo hiyo. Anwani yake ya kwanza inakuwa gateway ya tunnel, na anwani zilizobaki hugawanywa kwa wateja. Hapa namba mbili zinaelezea block moja, mtandao na netmask, na hiyo ndiyo sintaksia ya pool ambayo OpenVPN bado inaitarajia.
server 10.156.1.0 255.255.255.240Thibitisha kwamba anwani ilifika kwenye kiolesura kweli na si tu ndani ya usanidi wa OpenVPN. Fabric hupitisha kile NIC inaripoti, si kile daemon inaamini. Amri moja huamua hilo:
ip -4 addr show dev eth0Anwani ya pili ambayo haifiki eth0 kamwe, au pool inayopishana na subnet nyingine, huonekana baadaye kama upotevu wa vipindi na si kama hitilafu ya kuanza. Daemon huanza, wateja huunganisha, na ni baadhi ya maeneo tu yanayotenda vibaya. Weka safu ya alias ndogo ili pool itambulike kwa urahisi kwenye jedwali la route. Kamwe usiikate kutoka subnet ambayo instance nyingine tayari inaitumia.
Ipe trafiki ya kurudi next hop
Jibu kutoka mwenyeji ndani ya VPC linaelekezwa kwa anwani ya mteja katika pool ya tunnel, ambayo haimilikiwi na subnet yoyote inayojulikana na VPC. Bila route kwa pool hiyo, jibu huacha kwenye hop ya kwanza isiyo na mechi, na ombi linaweza kuwa limefanikiwa kabisa upande wa pili.
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=800Route hiyo hiyo inahitajika kwa prefix yoyote iliyo nyuma ya mteja badala ya ndani ya VPC. Prefix hizo pia zinahitaji ingizo la iroute kwenye faili ya ccd ya mteja huyo. Ingizo hilo ni uhasibu wa upande wa seva: humwambia seva ni mteja gani anamiliki prefix, na haliweki chochote kwenye mteja mwenyewe.
Weka orodha ya push kwa upande wa mteja wa mazungumzo, kwa sababu inaongeza route kwenye mashine inayounganisha tu. Mstari wa push kwa subnet ya VPC na route ya VPC kurudi kwenye pool ni nusu mbili za njia moja, na nusu yoyote peke yake huzalisha tunnel inayobeba maombi lakini si majibu.
Firewall, uenezaji na hop zilizo katikati
Firewall ya VPC hutathmini pakiti iliyofunguliwa, kwa hiyo kanuni ya ingress lazima iruhusu pool ya tunnel na prefix yoyote ya tovuti inayofika kwenye VM kwa njia hiyo. Msimamo wa kukataa kwa chaguo-msingi hushindikana kimya hapa: pakiti hutupwa baada ya kufunguliwa, na kumbukumbu ya OpenVPN inaonyesha kipindi chenye afya.
Kwenye mwenyeji wowote wa Linux unaopitisha badala ya kumaliza, angalia kwamba net.ipv4.ip_forward imewezeshwa. Kanuni ya umiliki inatumika huko pia: mashine inayopitisha kwa subnet ambayo haina humtupa pakiti kama VM ingefanya. Soma thamani kabla ya kulaumu tunnel.
Wakati prefix moja hasa inashindikana
Kushindikana kwa sehemu ni kisa rahisi kusoma, kwa sababu kila kitu kingine kwenye njia tayari kimethibitishwa. Anza na orodha ya route na usome safu ya lengo na next hop ya ingizo linalopaswa kufunika prefix, kisha soma maelezo ya instance na ulinganishe safu yake ya alias na pool ambayo seva inagawanya.
gcloud compute routes list --filter=destination-range~10.164.0.0
gcloud compute instances describe openvpn-vm --format=get(networkInterfaces[0].aliasIpRanges)Route inayokosekana hujionyesha kama hakuna next hop kwa prefix, wakati alias inayokosekana hujionyesha kama pakiti iliyotupwa kwenye kiolesura; kutoka kwa mteja hizo mbili zinafanana na katika matokeo hayo mawili ni tofauti kabisa. Ikiwa zote zipo, mtuhumiwa aliyebaki ni iroute ya ccd ya mteja anayedai prefix.
Andika thamani nne kando ya tunnel: safu ya alias, pool ya seva, prefix zilizopush, route za VPC. Alias ya zamani huvunja kila anwani ya pool, route ya zamani huvunja mwelekeo mmoja, push inayokosekana huficha prefix kwa mteja, na iroute isiyo sahihi hutuma prefix kwa peer isiyo sahihi. Mtu anayefuata kuongeza subnet anahitaji zote nne mahali pamoja, na noti hiyo ni rahisi kuliko jioni.