Antros sąsajos prijungimas prie Compute Engine VM suteikia dar vieną tinklo prisijungimą, o ne simetrinį grįžimo kelią. Svečias vis dar pasirenka sąsają ir šaltinio adresą iš savo maršrutų ir taisyklių. Tada Google Cloud taiko VPC maršrutizavimą ir ugniasienės politiką aplink tą sąsają, kuria paketas išėjo. Kai šie du sprendimai nesutampa, užklausos ateina į vieną NIC, o atsakymai išeina per kitą, ir filialas mato pusiau atvirą pokalbį.

Pereikite kelią penkiais žingsniais, ir neatitikimas pasirodys prieš rašant politikos taisyklę.

1 žingsnis: susiekite debesies NIC su svečio įrenginiais

Debesis sąsajas vadina nic0, nic1 ir taip toliau, o svečias mato įrenginių pavadinimus, kurie neturi sutapti. Išsiaiškinkite atitikimą iš egzemplioriaus metaduomenų arba iš pačios sąsajos adreso prieš ką nors kita. Įprastas DHCP suteikiamas numatytasis maršrutas susietas su nic0, todėl į internetą nukreiptas kelias taip dažnai netyčia laimi. Politikos rašymas pagal spėjamą įrenginio pavadinimą yra būdas, kuriuo teisinga taisyklė atsiduria netinkamoje sąsajoje.

Užrašykite adresus, įrenginių pavadinimus ir VPC, kuriam priklauso kiekvienas. Ta trijų stulpelių lentelė yra kiekvieno vėlesnio žingsnio įvestis.

2 žingsnis: įvardykite du maršrutizavimo sprendimus

Pirmasis sprendimas priklauso svečiui: kuri sąsaja ir koks šaltinio adresas šiam paketui. Antrasis priklauso debesiui: ką leidžia VPC maršrutai ir ugniasienės politika aplink tą sąsają.

Maršrutas, matomas į VPN atgręžtame VPC, netampa svečio maršrutu, pasirenkančiu tą NIC. Debesies maršrutas aprašo, ką tinklas gali pristatyti, o svečio maršrutas nusprendžia, ką daro paketas.

3 žingsnis: pasirinkite grįžimo kelio politiką

Mažam, stabiliam filialo prefiksų rinkiniui aiškūs svečio paskirties maršrutai yra paprasčiausia išraiška: atsakymai į tuos prefiksus išeina per į VPN atgręžtą sąsają. Kai kelios paslaugos tyčia naudoja skirtingus vietinius šaltinio adresus, šaltiniu pagrįstos taisyklės, pasirenkančios lentelę kiekvienai sąsajai, išlaiko kiekvieną atsakymą tinkamame kontekste. Daugelio sąsajų dokumentacija aprašo NIC pavadinimus ir numatytojo maršruto elgseną, kuria remiasi šie sprendimai.

Kiekvienai lentelei reikia galiojančių prijungtų maršrutų ir kitų šuolių, be to, paskirčių, kurių bus klausiama. Taisyklė, rodanti į nepilną lentelę, nėra grįžimo kelio sprendimas. Naudokite dokumentuotus to NIC vartus, o ne išgalvokite Ethernet vartus pagal potinklio išvaizdą.

4 žingsnis: patikrinkite pačio svečio filtrus

Patikrinkite, kur serveris klausosi ir kokį vietinį šaltinį neša atsakymas. Klausytojas visuose adresuose nepanaikina maršrutizavimo politikos, todėl susiejimas su visais adresais nieko nekeičia sąsajos, per kurią išeina atsakymas, atžvilgiu.

Linux sistemoje peržiūrėkite atvirkštinio kelio tikrinimą pagal numatytą sprendimą. Visuotinis jo išjungimas kaip pirmas žingsnis maino maršrutizavimo klaidą į apsimetimo riziką ir paslepia asimetriją, kurios ieškojote.

5 žingsnis: išbandykite vieną srautą kiekvienam keliui

Atskirai patikrinkite leidžiamą filialo užklausą ir nesusijusią interneto užklausą, kiekvieną su tikruoju šaltiniu ir paskirties vieta. Kai galite, fiksuokite abiejose sąsajose, nes naudingas įrodymas yra tai, kuri sąsaja pernešė atsakymą. Tada patvirtinkite, kad debesies pusės politika gerbė jūsų suprojektuotą kelią. Viena sėkminga užklausa įrodo vieną srautą, o ne simetrinį sprendimą.

Laikykite du testus atskirai savo užrašuose, nes jie naudoja skirtingus maršrutus ir skirtingas ugniasienės taisykles.

Ko antra NIC jums neduoda

Antra sąsaja prideda tinklo prisijungimą ir dar vieną adresą. Ji neprideda automatinio simetrinio maršrutizavimo ir neapeina ugniasienės politikos. Traktavimas kaip maršrutizavimo pataisos yra priežastis, kodėl daugelio NIC sprendimai kaupia taisykles, kurių vėliau niekas negali paaiškinti.

Jei VM turi persiųsti kitų mašinų srautą, suplanuokite tą maršrutizatoriaus vaidmenį aiškiai, įskaitant debesies nustatymą, leidžiantį persiųsti, ir su juo susijusius svečio filtrus.

Susiję straipsniai