Maraming LAN sa Isang AWS VPN Tunnel: Ano ang Ibig Sabihin ng Limitasyon sa SA

Ang pagdaragdag ng pangalawang LAN ng sangay sa isang AWS Site-to-Site VPN ay hindi nangangailangan ng pangalawang malayang IPsec association sa loob ng tunnel na iyon. Ang limitasyong kinatitisuran ng mga tao ay totoo ngunit mas makitid kaysa sa tunog nito: idinodokumento ng AWS isang natatanging pares ng IPsec SA bawat tunnel, isang papasok at isang palabas, at ang dalawang tunnel sa isang koneksyon ay nakakakuha ng kani-kanilang pares. Ito ay katangian ng serbisyo, hindi isang tuntuning IPsec ang nagpoprotekta sa isang subnet sa isang pagkakataon. Pinakamahalaga ang pagkakaiba kapag ginagawang sariling association ng isang policy-based na customer gateway ang bawat policy entry.

Magsimula sa koneksyon, hindi sa listahan ng LAN

Buksan ang koneksyon sa console at pansinin kung paano ito niruruta. Ang static na koneksyon ay nagdadala ng mga remote prefix na idineklara mo. Ang BGP na koneksyon ay natututo ng mga ito mula sa customer gateway.

Sa alinmang paraan, ang tunnel ay nakabatay sa ruta. Ang pumapasok dito ay pinagpapasyahan ng mga selector na kinakausap ng iyong device, hindi ng bilang ng subnet na maaari mong i-type sa isang form.

Obserbahan ang kinakausap ng customer gateway

Ang policy-based na device ay maaaring gawing sariling SA ang bawat policy entry. Ang dalawang LAN ay nangangahulugan ng dalawang entry, na nangangahulugan ng dalawang SA, at dito nagsisimulang mahalaga ang limitasyon bawat tunnel. Mga kinakailangan ng customer gateway nagbabala nang eksakto tungkol sa pag-uugaling ito at nagmumungkahi ng pinagsama-samang mga tuntunin sa mga device na iyon. Suriin ang mga napagkasunduang selector sa halip na ang bilang ng ACL sa device.

Dapat i-configure ang device upang ipakita ang parehong prefix sa ilalim ng isang patakaran, kung hindi ay hindi kayang hawakan ng malayong dulo ang resulta.

Tatlong imbentaryo, pinaghiwalay

Paghaluin ang tatlong listahang ito at ang bawat pagbabago ay magiging haka-haka. Itago ang mga ito bilang magkakahiwalay na column at punan ang bawat isa para sa iyong sariling network.

Tanging ang gitnang column ang nililimitahan ng limitasyon sa SA. Ang unang column ay katotohanan sa negosyo, at ang ikatlo ay ang nagpapagana sa isang aplikasyon. Basahin ang mga tinanggap na selector sa device sa halip na hulaan ang saklaw mula sa bilang ng mga ACL line na isinulat mo.

Pagsama-samahin nang hindi pinalalawak ang pahintulot

Ang summarized route ay ang halatang paraan upang makakuha ng isang policy entry, at ito rin ang paraan ng tahimik na paglaki ng protektadong set. Ang /20 na sumasaklaw sa parehong /24 ay sumasaklaw din sa mga address na hindi ginagamit ng alinmang sangay, at kusang dadalhin ng tunnel ang mga ito. Kung kailangan mong i-summarize, ipares ito sa pag-filter sa receiving side upang tanggihan ang sobrang espasyo sa halip na hindi lamang ipahayag. Ang tinanggihang packet ay ebidensya. Ang hindi inihayag na address ay kawalan lamang ng ebidensya.

Ang pagsama-sama ng patakaran sa proteksyon ay pagbabago sa kung ano ang maaaring i-encrypt. Hindi ito pagbibigay ng access at hindi dapat ituring na ganoon.

Subukan ang dalawang LAN, pagkatapos ay panatilihin ang dalawang tunnel

Pagkatapos ng coordinated na pagbabago, suriin ang aktibong saklaw ng proteksyon at pagkatapos ay magpatakbo ng tunay na aplikasyon mula sa bawat LAN. Ang paggana ng isang subnet ay walang pinapatunayan tungkol sa saklaw ng selector ng pangalawa, at lalo na tungkol sa reply path nito.

Panatilihin ang dalawang tunnel sa disenyo. Ang pagsama-sama ng patakaran ay hindi pahintulot na itapon ang redundancy, at ang isang tunnel na nagdadala ng bawat LAN ng sangay ay ginagawang outage ang susunod na maintenance window.

Isulat ang mga napagkasunduang selector, ang dalawang prefix, at ang mga may-ari ng ruta sa parehong change record. Kapag dumating ang ikatlong LAN, sasabihin sa iyo ng record na iyon kung nagdaragdag ka ng selector o nagsisimula muli.