Avota/galamērķa pārbaude ir vieni vārti, ne viss VPN ceļš

VPN beidzas EC2 instancē, jūs varat sasniegt šīs instances tuneļa adresi, un trafiks, kam bija jāiet caur to uz citu privātu resursdatoru, pazūd. Tie ir divi dažādi testi, un to sajaukšana izšķērdē stundas. Pirmais jautā, vai varat sasniegt instanci; otrais pieprasa, lai tā pārsūta trafiku uz galamērķi, kas nav tās pašas, un tam vajadzīga Linux pārsūtīšana, ugunsmūra politika, maršruts otrā pusē un AWS līmeņa atļauja, kam nav nekāda sakara ar viesu operētājsistēmu. Nekas konsolē nepievērš uzmanību šai atšķirībai. Simptoms izskatās kā maršrutēšanas kļūda, un parasti tā nav.

Atdaliet abus testus, pirms kaut ko maināt

Vārtejas sasniegšana pierāda tuneli, maršrutu uz tās adresi un drošības grupu, kas atļauj apmaiņu. Pārsūtīšana citam resursdatoram nepierāda neko no tā: tā izmanto citu avota adresi, citu galamērķi un instanci lomā, kurai tā ne vienmēr ir būvēta. Pierakstiet abus testus atsevišķi un atzīmējiet, kurš neizdodas, jo katra labojums ir citā konsolē. Vārtejas instance, kas būvēta tikai tuneļu pabeigšanai, nav iemesla pārsūtīt neko citu, un tās noklusējuma vērtības to atspoguļo. Tāpēc otrajam testam vajag savu iestatījumu, nevis nelielu pirmā pielāgojumu.

Ping, kas darbojas uz vārteju, un ping, kas neizdodas uz resursdatoru aiz tās, nav periodiska problēma. Tā ir gaidāmā instances uzvedība, kurai nav pateikts, ka tā drīkst pārsūtīt.

Pierakstiet ceļu, pirms pieskaraties iestatījumam

Pierakstiet klienta prefiksu, pārsūtošo instanci vai tīkla saskarni, mērķa apakštīklu un atbildes maršrutu. VPC maršrutu tabulas ieraksts, kas norāda uz instanci, nekonfigurē instances operētājsistēmu pārsūtīšanai, un viesu kodols ar iespējotu pārsūtīšanu neveido VPC maršrutu. Abiem šo attiecību galiem jāpastāv, un tie tiek rediģēti dažādās vietās, to darot cilvēkiem ar atšķirīgu piekļuvi.

Pēc tam pārbaudiet avota/galamērķa pārbaudes iestatījumu faktiskajā pārsūtīšanas komponentā, nevis katrā VPC instancē. AWS dokumentē, kāpēc instancei, kas pārsūta trafiku citu vietā, šī pārbaude jābūt izslēgtai, un arī kāpēc iestatījums ir lēmums katrai instancei, nevis visa VPC noklusējums.

Četras robežas, un pārbaude ir tikai viena no tām

Uztveriet ceļu kā četrus jautājumus un atbildiet uz tiem secībā. Pirmā neizdevusies atbilde ir vieta, kur ir darbs, un neviena no pārējām to nekompensēs.

Secība ir svarīga, jo pārbaudīt ir lēti: maršruti redzami vienā lapā, pārbaude ir viens atribūts, un galamērķa viedoklis parasti ir pēdējais, ko kāds jautā.

Tulkošana maina to, kādu avotu galamērķis redz

Maršrutēts dizains saglabā klienta avota adresi, tāpēc galamērķim vajadzīgs atgriešanās maršruts uz klienta prefiksu. Tulkots dizains tā vietā uzrāda vārtejas adresi, kas šo prasību novērš un aizstāj to ar stāvokļa tabulu uz vārtejas. Izlemiet atbilstoši paredzētajai arhitektūrai, nevis pievienojiet tulkošanu tāpēc, ka nesaistīts piemērs to izmantoja un izskatījās, ka tas darbojas.

Ja tulkojat, ierobežojiet noteikumu ar klienta prefiksu un paredzēto galamērķi. Ja saglabājat, apstipriniet, ka otrā puse patiešām zina maršrutu, nevis pieņemiet, ka tā to iemācīsies.

Testējiet no oriģinālā klienta, pēc tam saglabājiet izmaiņas

Uz vārtejas ģenerēts pieprasījums var izdoties, kamēr pārsūtīts pieprasījums neizdodas, jo tas ir cits avots un cits pārsūtīšanas gadījums. Pēc mērķēta labojuma atkārtojiet tieši to klienta-uz-resursu testu, kas neizdevās, no tā paša klienta, un apstipriniet, ka atbilde atgriežas, nevis tikai to, ka pieprasījums ieradās.

Visbeidzot, ievietojiet iestatījumu vārtejas pārvaldītajā konfigurācijā, lai to saņemtu aizvietojošā instance. Veiksmīgs tests, kas atkarīgs no manuālas izņēmuma, ir tests, kas beidzas nākamajā pārbūvē, un cilvēks, kurš to atklāja, nebūs tur, lai atcerētos kāpēc.