Hifadhi au SNAT anwani za IP za wateja wa VPN kwenye ukingo wa wingu

Kuhifadhi anwani ya mteja wa VPN hadi kwenye programu hufanya kila mstari wa kumbukumbu na kila ingizo la orodha ya ruhusa kuwa na maana moja. Kuiandika upya kwenye ukingo wa wingu hufanya jedwali la njia kuwa rahisi na kumbukumbu zisiwe na manufaa. Hakuna chaguo lolote lililo kosa lenyewe, na hoja inayoamua mara chache huhusu utendaji. Masharti matatu yanaamua: kama programu inapaswa kujua ni mtu gani aliunganisha, kama kitambaa cha wingu kitakubali chanzo unachokusudia kutuma, na nani atakubali kuchukua jukumu la njia ya kurudi baadaye.

Masharti matatu yanaamua

Anza na hitaji la programu, si kwa mchoro wa mtandao. Ikiwa idhini au ukaguzi unategemea anwani ya mteja mmoja, basi kuihifadhi ni hitaji la utendaji na kutafsiri ni kurudi nyuma. Ikiwa programu inahitaji tu kujua kwamba trafiki ilifika kwa njia ya ufikiaji wa mbali, anwani iliyotafsiriwa inatosha na ni nafuu zaidi kuendesha.

Sharti la pili ni la kiufundi. Mtandao pepe haujiamini kiotomatiki pakiti inayodai anwani ambayo haikutolewa kwa kiolesura kinachotuma. Vitambaa vingi vya wingu hulazimisha hilo, kwa njia na majina tofauti, na muundo unaoipuuza utaonekana sahihi kwenye mchoro na utaanguka kimya kwenye uzalishaji.

La tatu ni la shirika. Kuhifadhi vyanzo kunamaanisha kwamba jedwali la njia la subneti ya programu linapaswa kuelekeza nyuma kwenye lango kwa kiambishi cha mteja, na kila timu inayoongeza subneti baadaye lazima iweke njia hiyo sawa. Hiyo ni gharama ndogo mara moja, na gharama inayojirudia katika makumi ya akaunti. Amua nani anailipa kabla ya kuahidi tabia hiyo.

Njia si ruhusa ya kughushi

Kuongeza njia ya kurudi kunaiambia subneti yako wapi majibu yanapaswa kwenda. Haikuambii kitambaa kwamba kifaa kinachosambaza pakiti hizo kinaruhusiwa kuzitoa kwa chanzo cha kigeni. Katika AWS udhibiti unaohusika ni ukaguzi wa chanzo na lengwa, na unaonekana kwa kila kifaa:

aws ec2 describe-instances --instance-ids i-0a1b2c3d4e5f60718 \
  --query "Reservations[].Instances[].SourceDestCheck"
aws ec2 modify-instance-attribute --instance-id i-0a1b2c3d4e5f60718 \
  --no-source-dest-check

Zima hiyo kwa kifaa tu ambacho kazi yake iliyoandikwa ni usambazaji, na si kwa kitu kingine chochote. Kila VM ya programu inayoacha ukaguzi ukiwa washa ni mashine moja pungufu inayoweza kutumika kutoa trafiki kwa chanzo kilichokopwa. Ikiwa jukwaa lako si AWS, tafuta mpangilio sawa wa kuzuia ughushi au anwani zilizoruhusiwa badala ya kudhani tabia itahamia.

Unasaji wa pakiti wa haraka hutatua swali haraka kuliko kusoma konsoli. Ikiwa majibu yanatoka na mteja hayawaoni kamwe, ni kitambaa kinachotupa chanzo cha ughushi, na si programu inashindwa.

Tafsiri inanunua nini, na inagharimu nini

Kuandika upya chanzo kwenye lango kunaondoa tatizo la njia ya kurudi. Programu inaona anwani moja ambayo tayari inajua jinsi ya kuifikia, na kiambishi cha mteja hakihitaji kamwe kuonekana kwenye jedwali la njia la wingu. Katika Linux kanuni ni mstari mmoja, na inafaa kuandika toleo jembamba zaidi unaloweza:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 172.20.8.0/24 -o ens5 -j SNAT --to-source 10.40.3.10

Angalia kile programu sasa inarekodi: 10.40.3.10 kwa kila mtumiaji, kwenye kila muunganisho, milele. Orodha yoyote ya anwani zilizoruhusiwa iliyojengwa juu ya thamani hiyo sasa inatoa ufikiaji kwa watu wote wa ufikiaji wa mbali, na ukaguzi wowote wa tukio lazima urudi kwenye lango kujibu huyu alikuwa nani.

Suluhisho si kuacha tafsiri, ni kuacha kujifanya kwamba anwani ni utambulisho. Beba utambulisho wa mteja katika sehemu iliyothibitishwa, iandike kwenye lango pamoja na tuple iliyotafsiriwa, na uache programu ijiunge nayo. Bila ufunguo wa kujiunga, tafsiri hubadilisha tatizo la mtandao kuwa tatizo la uchunguzi wa kudumu.

Relay ni kiolesura tofauti

Proksi ya kinyume mbele ya programu inaepuka kabisa swali la njia iliyoelekezwa. Proksi hufungua muunganisho wake wa backend, kwa hiyo kiambishi cha mteja hakihitaji kamwe kuwa kinachoweza kuelekezwa ndani ya mtandao pepe, na programu inaweza kupokea utambulisho katika kichwa ambacho proksi huweka.

Kichwa hicho kinaaminika tu wakati backend inakikubali kutoka kwa proksi na kutoka kwa kitu kingine chochote. Kwa maneno ya nginx hiyo inamaanisha kutaja mwenza anayeaminika kwa uwazi badala ya kuamini chochote kinachofika:

set_real_ip_from 10.40.3.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

Mteja yeyote anayeweza kufikia backend moja kwa moja anaweza kughushi kichwa hicho hicho, kwa hiyo backend lazima isifikike isipokuwa kupitia proksi. Hiyo ni ukweli wa firewall, si maoni ya usanidi, na ndiyo dhana ambayo watu huiruka wanapokili kipande hicho.

Relay pia hubadilisha kile unachonunua. Unapata utambulisho wa kiwango cha programu na mahali pa asili pa kuurekodi; unatoa ujumla, kwa sababu itifaki kila mpya inahitaji msaada wake wa proksi. Kwa huduma za HTTP biashara hiyo kwa kawaida ni nzuri, na kwa kitu chochote ambacho si HTTP kwa kawaida haipatikani kabisa.

Andika kile kila ukingo unaona

Chochote unachochagua, mapitio ya muundo yanapaswa kuishia na jedwali moja linalotaja anwani ya chanzo na utambulisho unaoweza kuthibitishwa katika kila hop. Bila hilo, tukio la kwanza huzalisha timu tatu ambazo kila moja inaelezea mteja tofauti.

Kisha chagua. Hifadhi chanzo wakati idhini ya programu inategemea kweli anwani ya mteja na unaweza kuchukua njia. Tafsiri wakati sivyo na unaweza kubeba utambulisho nje ya bendi, na tumia mwongozo wa AWS kwa vifaa vya usambazaji kwa mipangilio ya usambazaji mahususi ya jukwaa. Geukia relay wakati huduma inazungumza HTTP na unataka utambulisho uache kuwa anwani.