GCP VM со повеќе NIC: зошто одговорите излегуваат низ погрешен интерфејс

Прикачувањето втор интерфејс на VM во Compute Engine ѝ дава уште една мрежна врска, а не симетрична повратна патека. Гостинот сѐ уште избира интерфејс и изворна адреса од сопствените рути и правила. Потоа Google Cloud применува VPC рутирање и firewall политика околу интерфејсот низ кој излегол пакетот. Кога овие две одлуки не се совпаѓаат, барањата пристигнуваат на едниот NIC, а одговорите излегуваат низ другиот, и филијалата гледа полуотворен разговор.

Поминете ја патеката во пет чекори и несовпаѓањето ќе се покаже пред да напишете правило за политика.

Чекор 1: поврзете ги NIC на облакот со уредите на гостинот

Облакот ги именува интерфејсите nic0, nic1 и така натаму, а гостинот гледа имиња на уреди што не мора да се совпаѓаат. Разрешете го мапирањето од метаподатоците на примерокот или од сопствената адреса на интерфејсот пред сѐ друго. Обичната стандардна рута што ја дава DHCP е поврзана со nic0, затоа патеката кон интернет толку често победува случајно. Пишувањето политика врз претпоставено име на уред е начинот на кој точното правило завршува на погрешниот интерфејс.

Запишете ги адресите, имињата на уредите и VPC во кој припаѓа секој. Таа табела со три колони е влезот за секој следен чекор.

Чекор 2: именувајте ги двете рутирачки одлуки

Првата одлука му припаѓа на гостинот: кој интерфејс и која изворна адреса за овој пакет. Втората му припаѓа на облакот: што дозволуваат рутите на VPC и firewall политиката околу тој интерфејс.

Рута видлива во VPC свртен кон VPN не станува рута на гостинот што го избира тој NIC. Рутата на облакот опишува што мрежата може да достави, додека рутата на гостинот одлучува што прави пакетот.

Чекор 3: изберете политика за повратна патека

За мал, стабилен збир префикси на филијала, експлицитните дестинациски рути кај гостинот се наједноставниот израз: одговорите на тие префикси излегуваат низ интерфејсот свртен кон VPN. Кога неколку служби намерно користат различни локални изворни адреси, правилата базирани на извор што избираат табела по интерфејс го држат секој одговор во правилниот контекст. Документацијата за повеќе интерфејси го опишува именувањето на NIC и однесувањето на стандардната рута на кои се потпираат овие решенија.

Секоја табела бара важечки поврзани рути и следни скокови, плус дестинациите за кои ќе биде прашана. Правило што покажува во нецелосна табела не е решение за повратна патека. Користете го документираниот gateway за тој NIC наместо да измислите Ethernet gateway од изгледот на подмрежата.

Чекор 4: проверете ги сопствените филтри на гостинот

Проверете каде слуша серверот и кој локален извор го носи одговорот. Слушателот на сите адреси не ја поништува рутирачката политика, така што врзувањето за сите адреси не менува ништо во врска со интерфејсот низ кој излегува одговорот.

На Linux, прегледајте ја валидацијата на обратната патека наспроти предвиденото решение. Нејзиното глобално исклучување како прв чекор заменува грешка во рутирањето со изложеност на лажно претставување и ја крие асиметријата што ја баравте.

Чекор 5: тестирајте еден тек по патека

Проверете одделно дозволено барање од филијала и неповрзано интернет барање, секое со неговиот вистински извор и дестинација. Снимете на двата интерфејса кога можете, бидејќи корисниот доказ е кој интерфејс го пренел одговорот. Потоа потврдете дека политиката на страната на облакот ја почитувала патеката што ја дизајниравте. Едно успешно барање докажува еден тек, а не симетрично решение.

Држете ги двата теста одделно во вашите белешки, бидејќи користат различни рути и различни firewall правила.

Што не ви дава вториот NIC

Вториот интерфејс додава мрежна врска и уште една адреса. Тој не додава автоматско симетрично рутирање и не ја заобиколува firewall политиката. Третирањето како поправка на рутирањето е причината зошто решенијата со повеќе NIC собираат правила што подоцна никој не може да ги објасни.

Ако VM треба да го препраќа сообраќајот на други машини, планирајте ја таа улога на рутер експлицитно, вклучувајќи го поставувањето во облакот што го дозволува препраќањето и филтрите кај гостинот што одат со него.