A Cloud VPN BGP-címei a tunelen belülre tartoznak, nem a hálózati kártyára

Nyissa meg a VPN Cloud Router oldalát, és egy 169.254.0.0/16 belüli című BGP-munkamenet néz vissza önre. A természetes reakció az, hogy ezt a címet valahol a VM-en elhelyezi, és várja, hogy a munkamenet feljöjjön. Ez a reakció meghatározott módon hibás: a pár ahhoz a logikai kapcsolathoz tartozik, amelyet az IPsec-alagút létrehoz, nem a gép szokásos hálózati interfészéhez. Semmi, amit a NIC-hez ad, nem készteti az alagutat BGP hordozására.

Kövesse a párt lefelé a veremben ahelyett, hogy a hoszthoz adná.

Ott kezdje, ahol a konzol a párt mutatja

A munkamenet oldala felsorol egy Cloud Router BGP-címet és egy partner-címet, mindkettő link-local IPv4 HA VPN esetén. Mellettük vannak a külső átjárócímek, amelyek az alagutakat lezárják. Ezek különböző objektumok: a link-local pár belül él, az átjárócímek pedig kívül élnek, és útvonalazhatónak kell lenniük, mielőtt bármi más működne.

Írja fel mindhármat, mielőtt megnyit egy konfigurációs fájlt, mert ezek összekeverése maga a teljes hibaüzemmód.

Menjen le az alagútig, amely hordozza

A link-local párnak csak akkor van jelentése, ha a két átjáró között létezik IPsec biztonsági társítás. A Google oldalán a HA VPN alagutak a két interfészen hozzák létre; az ön oldalán az van érvényben, amit a partner kialkudott. Először ellenőrizze az adattársítást a swanctl --list-sas segítségével, és jegyezze fel, melyik alagút melyik interfészen van fent, mert egy halott alagút feletti egészséges BGP-munkamenet lehetetlen, a reményteli konfigurációjú halott alagút pedig mindennapos.

A BGP-csomag belső IP-forgalom. A külső hálózat soha nem látja, ezért egyetlen kapcsolónak sincs szüksége mindkét címre egy VLAN-on.

Most állítsa be a Linux partnert, hogy illeszkedjen

Válassza a támogatott alagút-kialakítást, és hagyja, hogy az döntse el a belső címeket. Útvonalalapú interfész esetén az útvonalbejegyzésnek és a kialkudott forgalomválasztóknak egyezniük kell, mert az interfész neve önmagában semmit nem engedélyez. Irányítsa a BIRD-et a belső helyi címre és a Cloud Router belső címére, állítsa be az AS-számokat a munkamenet oldaláról, és engedélyezze a TCP 179-et a védett útvonalon belül. Tartsa a távoli külső cím felé vezető útvonalat a fizikai uplinkon, hogy az alagút ne fogja el a saját átvitelét.

Az alagút, amely magát útvonalazza, egy hurok kézfogással, és egy órán át tűzfalproblémának fog látszani.

Minden szakaszt sorrendben ellenőrizzen, ne az egészet egyszerre

Járja végig a szakaszokat: biztonsági társítás fent, belső partner elérhető az alagút címéről, BGP-munkamenet létrejött, előtagok elfogadva, majd egy számítási terhelés előtagja ténylegesen használatban. A birdc show protocols a harmadik kérdésre válaszol és semmi másra, ezért az emberek korán győzelmet hirdetnek.

Egy létrejött szomszéd nem ígéri meg, hogy mindkét fél hirdette a szükséges előtagokat, vagy hogy ezeket az útvonalakat előnyben részesítettként telepítették.

Ha a munkamenet létrejött, és a forgalom mégis rossz útra tér, hasonlítsa össze a hirdetett előtagokat azzal, amit az útvonaltábla tesz velük. Egy konkrétabb útvonal máshol, vagy egy másik út előnyben részesítése működő BGP-munkamenetet ad, és semmilyen hasznos továbbítást.

Álljon meg, mielőtt ezt a Router Appliance-re alkalmazza

A Network Connectivity Center Router Appliance más csatlakozási modell. Cloud Router partnerei a VPC- és alhálózat-elrendezés belső címeit használják a HA VPN link-local párja helyett. Ha a valódi cél a BGP útvonalazó VM-mel, kövesse annak a terméknek az interfészkövetelményeit, ahelyett hogy link-local munkamenetet másolna.

A link-local hatókör továbbra is azt jelenti, amit mond. A logikai alagút biztosítja ezt a szomszédságot, és nem engedélyezi tetszőleges link-local célok útvonalazását a VPC-n át.