GCP VM с няколко NIC: защо отговорите излизат през грешния интерфейс

Прикачването на втори интерфейс към VM в 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 да натрупват правила, които по-късно никой не може да обясни.

Ако VM трябва да препраща трафика на други машини, планирайте тази роля на рутер изрично, включително настройката в облака, която разрешава препращане, и съответните филтри на госта.