Ang pagsusuri ng pinagmulan/destinasyon ay isang tarangkahan, hindi ang buong landas ng VPN
Ang instans na nagpapasa ay nangangailangan ng pahintulot ng AWS pati na rin ng mga ruta ng Linux at mga tuntunin ng firewall. Suriin ang beripikasyon ng pinagmulan/destinasyon sa instans na nagpapasa.
Nagtatapos ang VPN sa isang instans ng EC2, maaabot mo ang address ng tunnel ng instans na iyon, at ang trapikong dapat dumaan dito patungo sa ibang pribadong host ay nawawala. Dalawang magkaibang pagsubok ito, at ang paghahalo sa kanila ay nag-aaksaya ng oras. Itinatanong ng una kung maaabot mo ang instans; hinihiling ng pangalawa na magpasa ito ng trapiko para sa destinasyong hindi sarili nito, na nangangailangan ng pagpapasa sa Linux, patakaran ng firewall, ruta sa kabilang panig at pahintulot sa antas ng AWS na walang kinalaman sa operating system ng bisita. Wala sa console ang nagpapansin sa pagkakaibang iyon. Mukhang fault ng routing ang sintomas, at kadalasan ay hindi.
Paghiwalayin ang dalawang pagsubok bago magbago ng anuman
Ang pag-abot sa gateway ay nagpapatunay ng tunnel, ang ruta patungo sa address nito at ang security group na nagpapahintulot ng palitan. Ang pagpapasa para sa ibang host ay walang napatutunayang alinman sa mga iyon: gumagamit ito ng ibang source address, ibang destinasyon at instans sa papel na hindi kinakailangang ginawa para dito. Isulat nang hiwalay ang dalawang pagsubok at itala kung alin ang nabigo, dahil ang pagwawasto ng bawat isa ay nasa ibang console. Ang instans ng gateway na ginawa lamang upang tapusin ang mga tunnel ay walang dahilan upang magpasa para sa iba pa, at ang mga default nito ay nagpapakita niyon. Kaya ang pangalawang pagsubok ay nangangailangan ng sariling setup nito, hindi maliit na pagbabago sa una.
Ang ping na gumagana patungo sa gateway at ang ping na nabigo patungo sa host sa kabila nito ay hindi paminsan-minsang problema. Ito ang inaasahang pag-uugali ng instans na hindi sinabihan na maaari itong magpasa.
Isulat ang landas bago hawakan ang anumang setting
Itala ang prefix ng kliyente, ang instans o interface ng network na nagpapasa, ang target na subnet at ang ruta ng sagot. Ang entry sa talahanayan ng ruta ng VPC na tumuturo sa isang instans ay hindi nagko-configure ng operating system ng instans upang magpasa, at ang kernel ng bisita na may bukas na pagpapasa ay hindi gumagawa ng rutang VPC. Dapat umiiral ang dalawang dulo ng ugnayang iyon, at binago ang mga ito sa magkaibang lugar ng mga taong may magkaibang access.
Pagkatapos suriin ang setting ng pagsusuri ng pinagmulan/destinasyon sa aktwal na bahagi ng pagpapasa, hindi sa bawat instans sa VPC. Idinodokumento ng AWS kung bakit kailangang patayin ng instans na nagpapasa ng trapiko para sa iba ang pagsusuring iyon, at kung bakit desisyon ito para sa bawat instans at hindi default ng buong VPC.
Apat na hangganan, at ang pagsusuri ay isa lamang sa kanila
Ituring ang landas na apat na tanong at sagutin ang mga ito nang sunud-sunod. Ang unang sagot na nabigo ang siyang lugar kung saan naroon ang trabaho, at wala sa iba ang makakabayad niyon.
| Boundary | Question it answers |
|---|---|
| VPC route tables | Do the destinations and replies select the intended gateway? |
| Forwarding instance | Do the AWS check and the guest OS both permit forwarding? |
| Access policy | Do security groups, ACLs and host rules allow the exchange? |
| Destination | Can the service accept that source and return a reply? |
Mahalaga ang pagkakasunod-sunod dahil mura ang pagsusuri: nakikita ang mga ruta sa isang pahina, isang attribute lamang ang pagsusuri, at ang opinyon ng destinasyon ang karaniwang huling itinatanong ng sinuman.
Binabago ng pagsasalin kung aling pinagmulan ang nakikita ng destinasyon
Pinapanatili ng rutadong disenyo ang source address ng kliyente, kaya kailangan ng destinasyon ng rutang pabalik sa prefix ng kliyente. Ang isinaling disenyo ay nagpapakita ng address ng gateway sa halip, na nag-aalis ng pangangailangang iyon at pumapalit ng talahanayan ng estado sa gateway. Magpasya ayon sa arkitekturang nilalayon mo, sa halip na magdagdag ng pagsasalin dahil ginamit ito ng walang kaugnayang halimbawa at mukhang gumagana.
Kung nagsasalin ka, limitahan ang tuntunin sa prefix ng kliyente at sa nilalayong destinasyon. Kung pinapanatili mo, kumpirmahin na alam talaga ng kabilang panig ang ruta sa halip na ipagpalagay na matututunan nito ang isa.
Subukan mula sa orihinal na kliyente, pagkatapos panatilihin ang pagbabago
Ang kahilingang nabuo sa gateway ay maaaring magtagumpay habang ang ipinasang kahilingan ay nabigo, dahil ibang pinagmulan ito at ibang kaso ng pagpapasa. Pagkatapos ng naka-target na pagwawasto, ulitin ang eksaktong pagsubok na kliyente-patungo-sa-mapagkukunan na nabigo, mula sa parehong kliyente, at kumpirmahin na bumabalik ang sagot at hindi lamang na nakarating ang kahilingan.
Sa huli, ilagay ang setting sa pinamamahalaang konfigurasyon ng gateway upang matanggap ito ng kapalit na instans. Ang matagumpay na pagsubok na umaasa sa manu-manong pagbubukod ay pagsubok na magwawakas sa susunod na muling pagtatayo, at ang taong nakatuklas nito ay wala roon upang alalahanin kung bakit.