BGP-adresoj de Cloud VPN apartenas ene de la tunelo, ne sur la retkarto
La paro BGP de Cloud Router por HA VPN situas ene de la IPsec-vojo. Sekvu ĝin malsupren laŭ la stako anstataŭ aldoni link-local-adreson al la VM-interfaco.
Malfermu la paĝon Cloud Router por la VPN kaj BGP-sesio kun adreso en 169.254.0.0/16 fiksrigardas vin. La natura reago estas meti tiun adreson ie sur la VM kaj atendi, ke la sesio supreniĝu. Tiu reago malĝustas en specifa maniero: la paro apartenas al la logika ligo, kiun kreas la IPsec-tunelo, ne al la ordinara retinterfaco de la maŝino. Nenio, kion vi aldonas al la retkarto, igas la tunelon porti BGP.
Sekvu la paron malsupren laŭ la stako anstataŭ aldoni ĝin al la gastiganto.
Komencu tie, kie la konzolo montras la paron
La sesia paĝo listigas BGP-adreson de Cloud Router kaj samrangulan adreson, ambaŭ link-local por IPv4 HA VPN. Apud ili estas la eksteraj pordejaj adresoj, kiuj finigas la tunelojn. Tiuj estas malsamaj objektoj: la link-local-paro vivas interne, kaj la pordejaj adresoj vivas ekstere kaj devas esti enkursigeblaj antaŭ ol io ajn alia funkcios.
Notu ĉiujn tri antaŭ ol malfermi agordan dosieron, ĉar konfuzi ilin estas la tuta malsukcesa maniero.
Malsupreniru al la tunelo, kiu portas ĝin
La link-local-paro signifas ion nur post kiam IPsec-sekurec-asocio ekzistas inter la du pordegoj. Ĉe la flanko de Google la HA VPN-tuneloj kreas ĝin sur la du interfacoj; ĉe via flanko ĝi estas tio, kion intertraktis la samtavolano. Unue kontrolu la datuman asocion per swanctl --list-sas kaj notu, kiu tunelo estas supra sur kiu interfaco, ĉar sana BGP-sesio super morta tunelo estas neebla kaj morta tunelo kun esperplena agordo estas rutina.
La BGP-paketo estas interna IP-trafiko. La ekstera reto neniam vidas ĝin, do neniu ŝaltilo bezonas ambaŭ adresojn sur unu VLAN.
Nun agordu la Linux-samtavolanon por kongrui
Elektu la subtenatan tunelan dezajnon kaj lasu ĝin decidi la internajn adresojn. Kun enkursig-bazita interfaco, la enkursiga ero kaj la intertraktitaj trafik-selektiloj devas kongrui, ĉar interfaca nomo sola permesas nenion. Direktu BIRD al la interna loka adreso kaj al la interna adreso de Cloud Router, agordu la AS-numerojn el la sesia paĝo, kaj permesu TCP 179 ene de la protektita vojo. Konservu la enkursigon al la malproksima ekstera adreso sur la fizika suprenligo, por ke la tunelo ne kaptu sian propran transporton.
Tunelo, kiu enkursigas sin mem, estas buklo kun manpremo, kaj ĝi aspektos kiel fajroŝirma problemo dum unu horo.
Kontrolu ĉiun etapon laŭorde, ne la tuton samtempe
Trairu la etapojn: sekurec-asocio supra, interna samtavolano atingebla el la tunela adreso, BGP-sesio starigita, antaŭfiksoj akceptitaj, poste laborŝarĝa antaŭfikso efektive uzata. birdc show protocols respondas la trian demandon kaj nenion alian, kaj tial homoj deklaras venkon frue.
Starigita najbaro ne promesas, ke ambaŭ flankoj anoncis la antaŭfiksojn, kiujn vi bezonas, nek ke tiuj enkursigoj estis instalitaj kiel preferataj.
Se la sesio estas starigita kaj la trafiko ankoraŭ prenas la malĝustan vojon, komparu la anoncitajn antaŭfiksojn kun tio, kion la enkursiga tabelo faras kun ili. Pli specifa enkursigo aliloke, aŭ prefero por alia vojo, donas al vi funkciantan BGP-sesion kaj neniun utilan plusendadon.
Haltu antaŭ ol apliki tion al Router Appliance
Network Connectivity Center Router Appliance estas malsama alkroĉa modelo. Ĝiaj Cloud Router-samtavolanoj uzas internajn adresojn el la VPC- kaj subreta aranĝo anstataŭ la HA VPN link-local-paro. Se la vera celo estas BGP kun enkursiganta VM, sekvu la interfacajn postulojn de tiu produkto anstataŭ kopii link-local-sesion.
La link-local-amplekso ankoraŭ signifas tion, kion ĝi diras. La logika tunelo provizas ĉi tiun najbarecon, kaj ĝi ne rajtigas enkursigi arbitrajn link-local-celojn tra la VPC.