Бірнеше NIC-і бар GCP VM: жауаптар неге дұрыс емес интерфейстен шығады

Compute Engine VM-іне екінші интерфейсті тіркеу оған тағы бір желілік қосылым береді, симметриялы қайтару жолын емес. Қонақ әлі де интерфейс пен бастауыш мекенжайды өз маршруттары мен ережелерінен таңдайды. Содан кейін Google Cloud пакет шыққан интерфейстің айналасында VPC маршруттауын және firewall саясатын қолданады. Бұл екі шешім сәйкес келмесе, сұраныстар бір NIC-ке келеді, ал жауаптар екіншісінен шығады, және филиал жартылай ашық әңгімені көреді.

Жолды бес қадаммен өтіңіз, саясат ережесін жазбас бұрын сәйкессіздік байқалады.

1-қадам: бұлттық NIC-терді қонақ құрылғыларына сәйкестендіріңіз

Бұлт интерфейстерді nic0, nic1 және сол сияқты деп атайды, ал қонақ сәйкес келуі міндетті емес құрылғы атауларын көреді. Басқа нәрседен бұрын сәйкестікті дана метадеректерінен немесе интерфейстің өз мекенжайынан анықтаңыз. DHCP ұсынатын әдеттегі әдепкі маршрут nic0-ге байланысты, сондықтан интернетке қарайтын жол жиі кездейсоқ жеңеді. Болжалды құрылғы атауына саясат жазу — дұрыс ереженің дұрыс емес интерфейске түсу жолы.

Мекенжайларды, құрылғы атауларын және әрқайсысы тиесілі VPC-ні жазып алыңыз. Сол үш бағаналы карта келесі әрбір қадамның кірісі.

2-қадам: екі маршруттау шешімін атаңыз

Бірінші шешім қонаққа тиесілі: осы пакет үшін қай интерфейс және қай бастауыш мекенжай. Екіншісі бұлтқа тиесілі: VPC маршруттары мен firewall саясаты сол интерфейстің айналасында неге рұқсат береді.

VPN-ге қарайтын VPC-де көрінетін маршрут сол NIC-ты таңдайтын қонақ маршрутына айналмайды. Бұлттық маршрут желінің нені жеткізе алатынын сипаттайды, ал қонақ маршруты пакеттің не істейтінін шешеді.

3-қадам: қайтару жолының саясатын таңдаңыз

Филиал префикстерінің шағын, тұрақты жиыны үшін қонақтағы айқын межелі маршруттар ең қарапайым өрнек: сол префикстерге жауаптар VPN-ге қарайтын интерфейстен шығады. Бірнеше қызмет әдейі әртүрлі жергілікті бастауыш мекенжайларды пайдаланса, әр интерфейске кесте таңдайтын бастауышқа негізделген ережелер әр жауапты дұрыс контексте ұстайды. Бірнеше интерфейс туралы құжаттама осы жобалар сүйенетін NIC атауын және әдепкі маршрут мінезін сипаттайды.

Әр кестеге жарамды қосылған маршруттар мен келесі секірістер, сондай-ақ одан сұралатын межелер қажет. Толық емес кестеге нұсқайтын ереже қайтару жолының жобасы емес. Сол NIC үшін құжатталған шлюзді пайдаланыңыз, қосымша желінің көрінісінен Ethernet шлюзін ойлап таппаңыз.

4-қадам: қонақтың өз сүзгілерін тексеріңіз

Сервердің қайда тыңдайтынын және жауаптың қай жергілікті бастауышты алып жүретінін тексеріңіз. Барлық мекенжайларды тыңдайтын тыңдаушы маршруттау саясатын жоймайды, сондықтан барлық мекенжайларға байланысу жауап шығатын интерфейске ештеңе өзгертпейді.

Linux-та кері жолды тексеруді жоспарланған жобаға қарсы қарап шығыңыз. Оны бірінші қадам ретінде ғаламдық өшіру маршруттау қатесін жасанды сәйкестендіруге ашықтықпен алмастырады және сіз іздеген асимметрияны жасырады.

5-қадам: әр жол үшін бір ағынды сынаңыз

Рұқсат етілген филиал сұранысын және байланысы жоқ интернет сұранысын бөлек тексеріңіз, әрқайсысы өзінің нақты бастауы мен межесімен. Мүмкін болса, екі интерфейстен де ұстаңыз, өйткені пайдалы дәлел — қай интерфейстің жауапты тасығаны. Содан кейін бұлт жағындағы саясаттың сіз жобалаған жолды құрметтегенін растаңыз. Бір сәтті сұраныс бір ағынды дәлелдейді, симметриялы жобаны емес.

Екі сынақты жазбаларыңызда бөлек ұстаңыз, өйткені олар әртүрлі маршруттар мен әртүрлі firewall ережелерін қолданады.

Екінші NIC сізге не бермейді

Екінші интерфейс желілік қосылым мен тағы бір мекенжай қосады. Ол автоматты симметриялы маршруттауды қоспайды және firewall саясатын айналып өтпейді. Оны маршруттау түзетуі ретінде қарау — көп NIC-ті жобалардың кейін ешкім түсіндіре алмайтын ережелерді жинақтау себебі.

Егер VM басқа машиналардың трафигін қайта жіберуі керек болса, сол маршрутизатор рөлін айқын жоспарлаңыз, оның ішінде қайта жіберуге рұқсат беретін бұлт параметрі және онымен бірге жүретін қонақ сүзгілері.