Semakan sumber/destinasi ialah satu pintu, bukan seluruh laluan VPN
Instans pemajuan memerlukan kebenaran AWS serta laluan Linux dan peraturan firewall. Semak pengesahan sumber/destinasi pada instans yang memajukan.
VPN berakhir pada instans EC2, anda boleh mencapai alamat terowong instans itu, dan trafik yang sepatutnya melaluinya ke hos peribadi lain hilang. Itu dua ujian berbeza, dan mencampurkannya membuang masa berjam-jam. Yang pertama bertanya sama ada anda boleh mencapai instans itu; yang kedua memintanya memajukan trafik untuk destinasi yang bukan miliknya, yang memerlukan pemajuan Linux, dasar firewall, laluan di sisi jauh dan kebenaran peringkat AWS yang tiada kaitan dengan sistem pengendalian tetamu. Tiada apa dalam konsol menarik perhatian kepada perbezaan itu. Gejalanya kelihatan seperti kerosakan penghalaan, dan biasanya bukan.
Asingkan kedua-dua ujian sebelum mengubah apa-apa
Mencapai get laluan membuktikan terowong, laluan ke alamatnya dan kumpulan keselamatan yang membenarkan pertukaran. Pemajuan untuk hos lain tidak membuktikan apa-apa daripada itu: ia menggunakan alamat sumber berbeza, destinasi berbeza dan instans dalam peranan yang tidak semestinya dibina untuknya. Tulis kedua-dua ujian secara berasingan dan catat yang mana gagal, kerana pembetulan bagi setiap satu berada dalam konsol berbeza. Instans get laluan yang dibina hanya untuk menamatkan terowong tiada sebab untuk memajukan apa-apa lagi, dan tetapan lalainya mencerminkan itu. Itulah sebabnya ujian kedua memerlukan persediaannya sendiri dan bukan pelarasan kecil pada yang pertama.
Ping yang berfungsi ke get laluan dan ping yang gagal ke hos di sebaliknya bukan masalah sekali-sekala. Ia tingkah laku yang dijangka bagi instans yang tidak diberitahu bahawa ia boleh memajukan.
Tulis laluan itu sebelum menyentuh mana-mana tetapan
Catat awalan klien, instans atau antara muka rangkaian pemajuan, subnset sasaran dan laluan balasan. Entri jadual laluan VPC yang menunjuk ke instans tidak mengkonfigurasi sistem pengendalian instans untuk memajukan, dan kernel tetamu dengan pemajuan dihidupkan tidak mencipta laluan VPC. Kedua-dua hujung hubungan itu mesti wujud, dan kedua-duanya diedit di tempat berbeza oleh orang dengan akses berbeza.
Kemudian periksa tetapan semakan sumber/destinasi pada komponen pemajuan sebenar, bukan pada setiap instans dalam VPC. AWS mendokumenkan mengapa instans yang memajukan trafik untuk orang lain perlu mematikan semakan itu, dan juga mengapa tetapan itu keputusan setiap instans dan bukan nilai lalai seluruh VPC.
Empat sempadan, dan semakan hanya salah satunya
Anggap laluan itu sebagai empat soalan dan jawab mengikut urutan. Jawapan pertama yang gagal ialah tempat kerja itu, dan tiada satu pun yang lain akan menampalnya.
| 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? |
Urutan penting kerana menyemaknya murah: laluan kelihatan pada satu halaman, semakan ialah satu atribut, dan pendapat destinasi biasanya perkara terakhir yang ditanya orang.
Terjemahan mengubah sumber mana yang dilihat oleh destinasi
Reka bentuk berpenghalaan mengekalkan alamat sumber klien, jadi destinasi memerlukan laluan balik ke awalan klien. Reka bentuk terjemahan sebaliknya menunjukkan alamat get laluan, yang menghapuskan keperluan itu dan menggantikannya dengan jadual keadaan pada get laluan. Putuskan mengikut seni bina yang anda maksudkan, bukan menambah terjemahan kerana contoh tidak berkaitan menggunakannya dan kelihatan berjaya.
Jika anda menterjemah, hadkan peraturan itu kepada awalan klien dan destinasi yang dimaksudkan. Jika anda mengekalkan, sahkan bahawa sisi jauh benar-benar mengetahui laluan itu dan bukan menganggap ia akan mempelajarinya.
Uji dari klien asal, kemudian kekalkan perubahan itu
Permintaan yang dijana pada get laluan boleh berjaya manakala permintaan yang dimajukan gagal, kerana ia sumber berbeza dan kes pemajuan berbeza. Selepas pembetulan bersasar, ulangi ujian klien-ke-sumber yang tepat yang gagal itu, dari klien yang sama, dan sahkan bahawa balasan kembali dan bukan hanya permintaan itu tiba.
Akhir sekali, letakkan tetapan itu dalam konfigurasi terurus get laluan supaya instans pengganti menerimanya. Ujian berjaya yang bergantung pada pengecualian manual ialah ujian yang luput pada pembinaan semula seterusnya, dan orang yang menemuinya tidak akan berada di sana untuk mengingati sebabnya.