CIDR ya mteja wa AWS Client VPN haiwezi kupishana na masafa ya VPC
AWS hufunga bwawa la Client VPN wakati wa kuunda, na mwingiliano huamuliwa na masafa, si anwani zisizotumika. Ukaguzi matano kabla ya kuijenga.
Kituo cha mwisho cha AWS Client VPN hutoa anwani za wateja kutoka bwawa unalochagua, na AWS hukagua bwawa hilo dhidi ya mtandao lengwa kabla ya kuunda kituo cha mwisho. Ukaguzi si kama subnet inaonekana tupu. Ni kama bwawa linaingiliana na masafa ya VPC, na jibu ni lile lile ikiwa instance ya EC2 inatumia anwani hizo leo au la. Mwingiliano ni swali la masafa, si la mgawanyo.
Pitia ukaguzi matano kwa mpangilio. Simama kwenye ule wa kwanza unaoshindikana, kwa sababu hakuna hatua ya baadaye inayoweza kurekebisha uamuzi wa awali.
Mwingiliano ni jaribio la masafa, si jaribio la anwani huru
Anza na CIDR ya VPC, si na subnet unayokusudia kuiunganisha. Bwawa la 172.20.0.0/22 liko ndani ya VPC ya 172.20.0.0/16 na hukataliwa hata wakati hakuna subnet inayolichukua, kwa sababu mwingiliano ni sifa ya masafa, si ya mgawanyo wa sasa. Kisha ongeza maeneo ambayo kituo cha mwisho kinaelekeza: VPC za rika, lango la usafiri na masafa ya ndani kupitia muunganisho wa site-to-site. Masafa yoyote ambayo mteja anaweza kuhitaji kufikia ni sehemu ya orodha.
Kusanya kutoka kwa akaunti, si kutoka kwa kumbukumbu: aws ec2 describe-vpcs --query "Vpcs[].CidrBlock", pamoja na maingizo ya jedwali la njia kwa subnet unayokusudia kuiunganisha.
Ukubwa wa bwawa huamuliwa kabla ya kujenga
AWS inakubali bwawa la wateja la IPv4 kati ya /22 na /12 kwenye Client VPN. /24 ni ndogo mno, /8 iko nje ya masafa yaliyoandikwa, na makosa yote mawili yanatoka katika kupima bwawa kama subnet ya mzigo wa kazi. Lipime kwa wateja wa wakati mmoja wanaotarajiwa pamoja na akiba, kisha likamilishe kwa kiambishi kinachoruhusiwa.
Angalia hesabu kabla ya kuiandika kwenye konsoli, kwa sababu kiambishi kilichoandikwa vibaya hubadilisha ukubwa wa bwawa bila onyo lolote:
python3 -c "import ipaddress; p=ipaddress.ip_network('172.16.0.0/22'); print(p.num_addresses, p.prefixlen, p.overlaps(ipaddress.ip_network('172.20.0.0/16')))"Hiyo huchapisha idadi ya anwani, urefu wa kiambishi na ikiwa mteule anagongana na masafa ya VPC, jambo ambalo ni haraka zaidi kuliko kufikiria kuhusu netmask mwishoni mwa dirisha la mabadiliko.
Kitatuzi kina jukumu lake la anwani
Kitatuzi cha VPC hujibu kwa anwani ya msingi ya masafa ya VPC pamoja na mbili, ambayo si lazima iwe ndani ya subnet uliyoiunganisha. Kudhani kwamba kitatuzi kinapaswa kuishi katika bwawa la wateja, au kujenga subnet kuzunguka anwani hiyo, huongeza vitu bila kubadilisha chochote. Kilicho muhimu ni kwamba kituo cha mwisho kinabeba mpangilio wa DNS ambao mteja anaweza kutumia na kwamba kitatuzi kinafikiwa kutoka kwenye handaki.
Rekodi kitatuzi, bwawa la wateja na subnet iliyounganishwa kama vitu vitatu tofauti katika mpango wa anwani. Vinashindikana kwa kujitegemea, na moja kuwa sahihi haisemi chochote kuhusu viwili vingine.
Sehemu nne unazojitolea wakati wa kuunda
CIDR ya IPv4 ya mteja imefungwa wakati wa kuunda. Kubadilisha seva ya DNS, kuongeza muunganisho, kubadilisha kikundi cha usalama, kuhariri kanuni za uidhinishaji au kubadilisha njia za split-tunnel zote ni hariri za kawaida, na hakuna hata moja inayobadilisha jina la bwawa. Utofauti huo ndio sababu hii inastahili mapitio: mipangilio ya bei nafuu ndiyo utakayotaka kuibadilisha baadaye, na ile ya bei ghali ndiyo unayojitolea kwa mara ya kwanza. Soma maelezo ya kituo cha mwisho kabla ya kupanga dirisha la mabadiliko.
Kagua kituo cha mwisho kilichowekwa kabla ya kudhani ujenzi upya. aws ec2 describe-client-vpn-endpoints hurudisha bwawa, DNS, bendera ya split-tunnel na muunganisho katika jibu moja, ambayo kwa kawaida inatosha kuondoa ujenzi upya.
Badilisha kituo cha mwisho badala ya kukirekebisha
Kituo kipya cha mwisho ni kituo kipya, si uhamishaji. Vikao vilivyopo havihamii, wasifu wa wateja huelekeza kwa jina lingine, na kila mpangilio uliouona kama wa kawaida lazima uundwe upya: cheti cha seva, uthibitishaji, muunganisho, njia, vikundi vya uidhinishaji, uwekaji kumbukumbu. Thibitisha kwa mteja mmoja dhidi ya huduma ya kibinafsi inayohitajika na dhidi ya lengo ambalo lazima likataliwe, kisha panua ufikiaji. Chochote unachoruka huwa tikiti ya msaada baadaye.
Endelea kuweka kituo cha zamani kikifanya kazi hadi uthibitisho huo upite, na uhifadhi njia ya kiutawala isiyotegemea kipya.
Kikomo kimoja kinachostahili kutajwa: hii inashughulikia bwawa la wateja la IPv4. Mipangilio ya trafiki ya dual-stack na IPv6 kwenye Client VPN hufuata muundo wake wa anwani, kwa hivyo usinakili orodha hii bila kusoma nyaraka za hali hiyo.