VPN vietnes paplašināšana: sekojiet atgriešanās maršrutam aiz vārtejas

Satiksme no filiāles beidzas vārtejā, kuras LAN nav tās lietotnes, kuru jums bija jāsasniedz. Serveris atrodas otrajā datu centrā, aiz iekšējā savienojuma, kuru VPN nekad nav konfigurējis. Vēl viena prefiksa pievienošana tuvākajai vārtejai šajā gadījumā neko nedod, jo tālā vārteja ir šifrēšanas galapunkts, nevis pēdējais maršrutētājs. Ceļam nepieciešams maršruts uz priekšu, pielaide tālajā drošības robežā un atgriešanās lēmums pašā galamērķa tīklā.

Tālā vārteja ir šifrēšanas galapunkts

IPsec starp vārtām aizsargā satiksmi starp divām drošības ierīcēm, un iekšējās adreses šķērso šo segmentu šifrētā veidā. Aiz tālās vārtejas pārņem parastā maršrutēšana, tostarp jebkura politika, kas pastāv starp datu centriem. Tāpēc aizsargātais segments aptver daļu ceļojuma, nevis atlikušo daļu. Domāt pretējo ir veids, kā projekts beidzas ar veselu tuneli un nesasniedzamu lietotni.

Uzzīmējiet ceļu trīs daļās: filiāle uz tuvāko vārteju, tuvākā uz tālo, tālā vārteja uz lietotni. Katrai daļai ir savs īpašnieks un savs atteices veids.

Izlasiet abus tuneļa politikas virzienus

Tuneļa politika parasti tiek rakstīta no vietējās puses skatpunkta, un tieši no šī ieraduma rodas daļējas konfigurācijas. Abām pusēm ir jāuzskaita filiāles avots un galamērķis tā, kā tie parādīsies tunelī, ieskaitot jebkuru tulkojumu, ko paredz projekts. Atjauninot tikai tuvāko galu, rodas otrās fāzes neatbilstība, kas izskatās kā maršrutēšanas kļūda. Salīdziniet abus politikas kopumus pirms jebkura maršruta aizskaršanas.

Rakstiet avotu un galamērķi kā adreses, nevis vietnes nosaukumus. Neskaidrība šeit vēlāk atkal parādīsies kā mulsinoša asimetrija.

Pievienojiet maršrutu uz priekšu un apstipriniet pielaidi

Tālajai vārtejai nepieciešams maršruts uz lietotnes apakštīklu, un katram maršrutētājam starp tiem ir jāpielaiž filiāles avots. Pārbaudiet, kas tālajai vārtejai patiešām ir, nevis ko apgalvo shēma.

ip route get 10.30.5.10 from 10.10.1.50
traceroute -n -s 10.10.1.50 10.30.5.10

Pirmā komanda ziņo par izejas interfeisu un nākamo lēcienu, ko tālā vārteja izvēlētos šim avotam, un tas ir jautājums, uz kuru parasta maršrutēšanas tabula nevar atbildēt. Izsekošana parāda, kur paketes apstājas, un pārtraukums pēc tālās vārtejas norāda uz iekšējo tranzītu, nevis tuneli. Ja maršruts pastāv un satiksme tomēr pazūd, veiciet uztveršanu tālajā vārtejā un nolasiet ienākošo avota adresi, jo negaidīta adrese nozīmē, ka tulkošana notiek kaut kur neplānoti. Visas adreses šeit ir vietturi, tāpēc aizstājiet tās ar īstajiem filiāles, tranzīta un lietotnes apakštīkliem.

Pārbaudiet no filiāles, pēc tam vēlreiz pārbaudiet veco ceļu

Pieņemšanai nepieciešams īsts avots, nevis zondēšana no tālās vārtejas. Veiciet pārbaudi no filiāles resursdatora un saglabājiet iepriekš strādājošos galamērķus tajā pašā testā.

curl -sS -m 5 http://10.30.5.10:8080/health
ping -c 3 10.20.1.1

Atbilde no lietotnes pierāda ceļu uz priekšu un atgriešanās ceļu kopā, savukārt ping uz veco galamērķi pierāda, ka izmaiņas nesabojāja to, kas jau darbojās. Ierakstiet avota adresi, ko lietotne reģistrē, jo tās piekļuves noteikumiem un jebkuram atgriešanās maršrutam ir jāatbilst šai vērtībai. Kur filiāle tulko pirms tuneļa, politikas adrese un adrese, ko redz lietotne, pēc projekta atšķiras, tāpēc pierakstiet abas. Atkārtojiet testu pēc atslēgas atjaunināšanas vai maršrutēšanas izmaiņām, jo šie ceļi parasti tiek validēti vienreiz un pēc tam aizmirsti.

Piešķiriet īpašnieku katram no trim segmentiem un atgriešanās maršrutam galamērķa tīkla iekšienē. Ceļš ar četriem īpašniekiem sabrūk spraugās starp tiem.