AWS VPN: lokaal en fiert CIDR - hokker kant is hokker?

Jo iepenje de opsjes fan Site-to-Site VPN, sjogge twa CIDR-fakken mei de labels lokaal en fiert, en gripe nei it adres dat jo as lokaal beskôgje: de VPC. Dat is it tsjinoerstelde fan wat de API bedoelt. Yn 'e ferbyningsopsjes neamt LocalIpv4NetworkCidr de klantpoarte-kant en RemoteIpv4NetworkCidr de AWS-kant, om't de ferbining fan 'e klantpoarte ôf boud wurdt. De konsole seit dit nea lûd, en neat wiist in leaudweardich lykjende omwikseling ôf.

Begjin by de API-oproep, net by it konsol-label

Lês de referinsje fan 'e ferbyningsopsjes ien kear hielendal troch en merk op dat elke opsje skreaun is fanút it eachpunt fan 'e klantpoarte. Dat is gjin tafal fan 'e nammejouwing. De tunnel wurdt beskreaun sa't dy foar it apparaat liket dat him oan jo kant beëiniget, dus lokaal betsjut it netwurk efter jo poarte en fiert it netwurk efter de AWS-poarte. Sawol de IPv4- as de IPv6-fakken folgje deselde regel.

Skriuw de twa labels op in plaknotysje foardat jo eat yntype: klantkant, AWS-kant. Byldzjepje dêrnei jo adressen dêr op ôf.

In útwurke foarbyld mei de rollen derby

Stel dat it lokale prefiks 10.20.0.0/16 is en it VPC-prefiks 10.60.0.0/16. De opsjes lêze krekt sa't de rollen suggerearje, mei it lokale berik yn it lokale fak:

{
  "LocalIpv4NetworkCidr": "10.20.0.0/16",
  "RemoteIpv4NetworkCidr": "10.60.0.0/16"
}

Jou no deselde peare oan wa't it peerapparaat konfigurearret en sjoch hoe't de falstrik ôfgiet. By in protte firewalls betsjut lokaal de ynterface dêr't de tunnel op einige, en fiert it fiere ein, wat foar de AWS-kant de omkearde mapping is. Beide minsken kinne gelyk hawwe en dochs in tunnel meitsje dy't nea foltôget, om't de twa wurdboeken ferskillende einpunten beskriuwe.

Werhelje de oefening op papier yn 'e terminology fan 'e peer, mei beide CIDR's en beide labels, foardat ien apparaat oanreitsen wurdt.

Standertwearden binne gjin ûntwerp

Deselde referinsje listet 0.0.0.0/0 as standert foar beide IPv4-fakken, mei ferlykbere wearden foar IPv6. It sjen fan dy wearden yn in besteande ferbining fertelt jo dat it fak nea ferringe is, net dat der in ynternetútgong konfigurearre is. Rûteferdieling, de rûtetabel fan it subnet en de feiligensmaatregels beslute noch hieltiten hokker ferkear der wier oer kin; de CIDR-wearden beskriuwe allinnich hokker berikken de tunnel ree is te kiezen.

In smeller wearde ferfange troch de standert is dêrom gjin kompatibiliteitstruk dat jo tapasse kinne as in tunnel ferkeard docht. It ferwiidt de selektor en lit elke oare laach krekt sa't dy wie.

It peerapparaat brûkt it oare eachpunt

As de AWS-kant ienris dúdlik is, is de peer-konfiguraasje it plak dêr't it measte fan 'e oerbliuwende betizing sit. In apparaat dat in lokaal netwurk en in fier netwurk freget, beskriuwt syn eigen ynterface as lokaal, dus jo VPC-berik giet yn syn fiere fak en jo lokale berik yn syn lokale fak. Freget it ynstee ferkearsselektors yn pearen, dan skriuwe jo beide rjochtingen eksplisyt en de labels telle minder as it pearen.

Lês de fakhelp fan it apparaat, net de faknammen. Fabrikanten brûke deselde twa wurden foar trije ferskillende begripen.

Kontrolearje dan de tunnelstatus foar beide fazen, om't in net passende selektor him meastentiids sjen lit as in mislearring yn 'e twadde faze, wylst de earste faze rêstich fêststeld bliuwt.

Feroarje de opsjes as in feroaring, net as dokumintaasje

It bewurkjen fan ferbyningsopsjes op in aktive VPN kin de tsjinst ûnderbrekke, behannelje it dêrom as in ûnderhâldsaksje mei in finster, in weromsetwearde en in notysje wa't it rekket. Lêst earst de hjoeddeiske opsjes fêst, ynklusyf beide CIDR-fakken en de tunnelopsjes, sadat weromsette in plakke is en gjin weropbou.

Kontrolearje nei de feroaring fan 'e AWS-kant en fan 'e peer: in boarne yn elk berik dy't in bestimming yn it oare berikt, yn beide rjochtingen. Ien ping fan ien kant bewiist ien selektor.

Wurkje dan de ferbyningsdokumintaasje by mei de rollen útskreaun, sadat de folgjende persoan net op 'e nij ûntdekke moat dat lokaal jo kant betsjut.