Paano gawing simulan ng AWS ang isang Site-to-Site VPN tunnel
Magkaibang tanong ang sinasagot ng startup action at ng DPD timeout action. Itakda ang tumutulong sa AWS na magsimula, pagkatapos ay suriin ang address ng peer at ang ruta ng app.
Bilang default, naghihintay ang isang AWS Site-to-Site VPN na simulan ng customer gateway ang negosasyon. Ang default na iyon ay isang setting, hindi batas, at ang setting ay tinatawag na Startup action. Bago mo ito abutin, paghiwalayin ang dalawang tanong na laging pinagsasama: sino ang gumagawa ng tunnel, at kung may ruta ba sa pamamagitan nito ang mga packet na mahalaga sa iyo. Ang una lang ang nasa mga opsyon ng tunnel.
Paghiwalayin ang startup action sa DPD timeout action
Dalawang opsyon bawat tunnel ang kumokontrol sa dalawang magkaibang pangyayari, at hindi nagsasabi ang pagtatakda ng isa tungkol sa isa pa.
| Event | Option | Useful values |
|---|---|---|
| A new or modified VPN connection needs a tunnel | Startup action | add waits for the peer; start asks AWS to initiate |
| Dead peer detection times out | DPD timeout action | clear ends the session, restart reinitiates, none does nothing |
Kung dapat magtayo ang AWS ng bago o binagong tunnel, piliin start. Kung dapat ding simulan muli ng AWS ang negosasyon pagkatapos ng DPD timeout, i-configure ang restart para sa pangyayaring iyon nang hiwalay. Wala sa dalawang opsyon ang patakaran sa muling pagsubok ng app, at wala sa dalawa ang agwat ng pagpapalit ng key: sinusuri ng DPD kung buhay ang peer, habang pinapalitan ng pagpapalit ng key ang security associations sa aktibong tunnel.
Ang app na nag-timeout habang nag-uulat pa ng up ang tunnel ay may problema sa daanan ng data. Hindi ito maaayos ng pagpapaikli ng DPD timer, at maaaring magdagdag ito ng gulo na kailangan mong ipaliwanag mamaya.
Suriin na may mapagpapadalhan ang AWS ng negosasyon
Ang pagsisimula mula sa panig ng AWS ay gumagana lamang sa IKEv2, at kailangan ng AWS ang pampublikong address ng customer gateway para malaman kung saan ipapadala ang proposal. Ang kaso na pinakamasakit ay ang customer gateway resource na na-authenticate ng certificate na ginawa nang walang address: inilalarawan ng dokumentasyon ng AWS ang paggawa ng bagong customer gateway resource na may address at pagkatapos ay pagbabago ng VPN connection para tumuro rito.
Pinapatunayan ng certificate kung sino ang peer. Hindi nito sinasabi sa AWS kung nasaan ang peer, at dalawang magkaibang pangangailangan iyon. Kaya ang lunas ay bagong customer gateway resource at hindi bagong certificate. Kapag pinalitan ang certificate, nananatili ang AWS sa parehong kulang na destinasyon.
Kung nasa likod ng NAT ang customer gateway, kailangan din ng AWS ng naka-configure na responder identity, IDr, para tumugma ang pagkakakilanlan ng peer sa inaasahan ng device. Kumpirmahin ang halagang iyon at ang daanan ng firewall na tumatanggap ng IKE traffic bago sisihin ang opsyon na binago mo lang. Ang pagpili ng start ay hindi makapipilit sa isang peer na hindi maabot o mali ang pagkakakilanlan na tanggapin ang isang proposal.
Ilapat ang pagbabago sa isang tunnel at asahan ang pagkaantala
May dalawang tunnel ang isang VPN connection na may independiyenteng mga opsyon, kaya kumpirmahin sa panlabas na address kung alin ang ine-edit mo. Pinapayagan ng AWS na baguhin ang isang tunnel sa isang pagkakataon, at ang koneksyon sa napiling tunnel ay maaaring maputol nang ilang minuto.
- Piliin ang Site-to-Site VPN connection at buksan ang Modify VPN tunnel options.
- Piliin ang tunnel ayon sa panlabas na IP address at kumpirmahin ang bersyon ng IKE at ang customer gateway resource.
- Itakda ang startup at DPD actions na talagang gusto mo, pagkatapos ay i-save sa loob ng window na kontrolado mo.
- Kumpirmahin na nagtatatag ang binagong tunnel, at suriin ang isa pang tunnel at ang routing bago ang susunod na pagbabago.
Isang pag-uugali ang dapat bigyan ng pansin bago ang maintenance. Kapag naka-on ang pagsisimula mula sa AWS, walang timeout: patuloy na sumusubok ang AWS hanggang umangat ang tunnel, at nagsisimula itong muli kapag nagpadala ang customer gateway ng delete-SA message. Kung sadyang ibababa mo ang peer, patuloy na kakatok ang AWS, at makikita ito sa mga log ng peer.
Suriin ang daanan ng app, hindi lamang ang kalagayan ng tunnel
Ang tunnel na nag-uulat ng up ay hindi katulad ng isang kahilingang gumagana. Ang isang Lambda function na nakakabit sa VPC ay kailangan pa rin ng subnet route patungo sa prefix ng customer, ng mga panuntunan ng security group at network ACL na pumapayag sa traffic, ng resolusyon ng pangalan na nagbabalik ng tamang address, at ng daanan pabalik sa panig ng customer.
Subukan isang beses gamit ang tunay na kahilingan mula sa konteksto ng app, pagkatapos ay basahin ang flow logs kung nabigo. Ang keepalive traffic ay lehitimong opsyon kapag patay ang pagsisimula mula sa AWS at kailangan ng idle tunnel ng mga packet para manatiling nakataas, pero dapat itong desisyon sa monitoring na makakapangalan ka, hindi isang hindi maipaliwanag na ping loop na nakabolt sa isang function.
Piliin muna kung sino ang gumagawa ng tunnel, pagkatapos ay i-diagnose ang natitirang kabiguan sa sarili nitong layer. Ang dokumentasyon ng AWS tungkol sa pagsisimula ay sumasaklaw sa mga pangangailangan sa address, pagkakakilanlan at muling pagsubok nang mas detalyado kaysa sa mga pahiwatig sa console.