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-ова накупљају правила која касније нико не може да објасни.

Ако ВМ мора да прослеђује саобраћај других машина, планирајте ту улогу рутера експлицитно, укључујући подешавање у облаку које дозвољава прослеђивање и филтере госта који иду са тим.