Віртуальная машына GCP з некалькімі NIC: чаму адказы ідуць праз не той інтэрфейс

Далучэнне другога інтэрфейса да ВМ Compute Engine дае ёй яшчэ адно сеткавае далучэнне, а не сіметрычны зваротны шлях. Гасцявая сістэма па-ранейшаму выбірае інтэрфейс і адрас крыніцы з уласных маршрутаў і правілаў. Затым Google Cloud ужывае маршрутызацыю VPC і палітыку міжсеткавага экрана вакол таго інтэрфейса, праз які пайшоў пакет. Калі гэтыя два рашэнні разыходзяцца, запыты прыходзяць на адзін NIC, а адказы сыходзяць праз другі, і філіял бачыць паўадкрытую размову.

Прайдзіце шлях за пяць крокаў, і разыходжанне стане бачным яшчэ да таго, як вы напішаце правіла палітыкі.

Крок 1: супастаўце воблачныя NIC з прыладамі гасцявой сістэмы

Воблака называе інтэрфейсы nic0, nic1 і гэтак далей, а гасцявая сістэма бачыць назвы прылад, якія не абавязаны супадаць. Вызначце супастаўленне з метаданых экзэмпляра або з уласнага адраса інтэрфейса раней за ўсё астатняе. Звычайны маршрут па змаўчанні, які выдае DHCP, звязаны з nic0, і менавіта таму шлях да інтэрнэту так часта перамагае выпадкова. Напісанне палітыкі пад меркаваную назву прылады — гэта спосаб, якім правільнае правіла трапляе на не той інтэрфейс.

Запішыце адрасы, назвы прылад і VPC, да якой належыць кожная. Гэтая табліца з трох слупкоў — уваход для кожнага наступнага кроку.

Крок 2: назавіце два маршрутныя рашэнні

Першае рашэнне належыць гасцявой сістэме: які інтэрфейс і які адрас крыніцы для гэтага пакета. Другое належыць воблаку: што дазваляюць маршруты VPC і палітыка міжсеткавага экрана вакол гэтага інтэрфейса.

Маршрут, бачны ў VPC, скіраванай да VPN, не становіцца маршрутам гасцявой сістэмы, які выбірае гэты NIC. Воблачны маршрут апісвае, што сетка можа даставіць, а маршрут гасцявой сістэмы вырашае, што робіць пакет.

Крок 3: выберыце палітыку зваротнага шляху

Для невялікага стабільнага набору прэфіксаў філіялаў яўныя маршруты прызначэння ў гасцявой сістэме — найпрасцейшае выражэнне: адказы на гэтыя прэфіксы сыходзяць праз інтэрфейс, скіраваны да VPN. Калі некалькі сэрвісаў наўмысна выкарыстоўваюць розныя лакальныя адрасы крыніцы, правілы на аснове крыніцы, якія выбіраюць табліцу для кожнага інтэрфейса, трымаюць кожны адказ у належным кантэксце. Дакументацыя па некалькіх інтэрфейсах апісвае назвы NIC і паводзіны маршруту па змаўчанні, на якія абапіраюцца гэтыя схемы.

Кожнай табліцы патрэбны сапраўдныя далучаныя маршруты і наступныя пераходы, а таксама пункты прызначэння, якія ў яе запытаюць. Правіла, якое паказвае ў няпоўную табліцу, не з’яўляецца схемай зваротнага шляху. Выкарыстоўвайце дакументаваны шлюз для гэтага NIC замест таго, каб выдумляць Ethernet-шлюз з выгляду падсеткі.

Крок 4: праверце ўласныя фільтры гасцявой сістэмы

Праверце, дзе слухае сервер і які лакальны адрас крыніцы нясе адказ. Слухач, які адказвае на ўсе адрасы, не адмяняе маршрутную палітыку, таму прывязка да ўсіх адрасоў ніяк не змяняе інтэрфейс, праз які сыходзіць адказ.

У Linux праверце адваротную праверку шляху супраць задуманай схемы. Адключэнне яе глабальна як першы крок мяняе памылку маршрутызацыі на ўразлівасць да падробкі адрасоў і хавае асіметрыю, якую вы спрабавалі знайсці.

Крок 5: праверце адзін паток на кожны шлях

Праверце дазволены запыт філіяла і незвязаны інтэрнэт-запыт асобна, кожны з яго рэальнымі крыніцай і прызначэннем. Перахоплівайце на абодвух інтэрфейсах, калі можаце, бо карыснае сведчанне — гэта тое, які інтэрфейс панёс адказ. Затым пераканайцеся, што палітыка на баку воблака ўшанавала шлях, які вы спраектавалі. Адзін паспяховы запыт даказвае адзін паток, а не сіметрычную схему.

Трымайце два тэсты асобна ў сваіх нататках, бо яны праходзяць па розных маршрутах і розных правілах міжсеткавага экрана.

Што другі NIC вам не дае

Другі інтэрфейс дадае сеткавае далучэнне і яшчэ адзін адрас. Ён не дадае аўтаматычнай сіметрычнай маршрутызацыі і не абыходзіць палітыку міжсеткавага экрана. Стаўленне да яго як да выпраўлення маршрутызацыі — вось чаму схемы з некалькімі NIC назапашваюць правілы, якія потым ніхто не можа растлумачыць.

Калі ВМ павінна перасылаць трафік іншых машын, сплануйце гэтую ролю маршрутызатара яўна, уключаючы наладу воблака, якая дазваляе перасылку, і адпаведныя фільтры гасцявой сістэмы.