Олон NIC-тэй GCP VM: хариултууд яагаад буруу интерфейсээр гардаг вэ

Compute Engine VM-д хоёр дахь интерфейс хавсаргах нь түүнд өөр нэг сүлжээний холболт өгдөг, тэгш хэмтэй буцах зам биш. Зочин өөрийн замууд болон дүрмүүдээс интерфейс болон эх сурвалжийн хаягийг сонсодог хэвээр. Дараа нь Google Cloud пакет гарсан интерфейсийн эргэн тойронд VPC маршрутлалт болон firewall бодлогыг хэрэглэнэ. Эдгээр хоёр шийдвэр нийцэхгүй бол хүсэлтүүд нэг NIC дээр ирж, хариултууд нөгөөгөөр гарч, салбар хагас нээлттэй яриа хардаг.

Замыг таван алхамаар туулна уу, бодлогын дүрэм бичихээс өмнө зөрүү илэрнэ.

1-р алхам: үүлэн NIC-г зочны төхөөрөмжүүдтэй тааруулна уу

Үүл интерфейсүүдийг nic0, nic1 гэх мэтээр нэрлэдэг бол зочин таарах шаардлагагүй төхөөрөмжийн нэрсийг хардаг. Бусад бүхнээс өмнө тохирлыг instance-ийн мета өгөгдөл эсвэл интерфейсийн өөрийн хаягаас тодруулна уу. DHCP-ийн өгдөг энгийн анхдагч зам нь nic0-тэй холбоотой байдаг тул интернэт рүү чиглэсэн зам санамсаргүйгээр олон удаа ялдаг. Таамагласан төхөөрөмжийн нэр дээр бодлого бичих нь зөв дүрэм буруу интерфейс дээр буух арга юм.

Хаяг, төхөөрөмжийн нэр, тус бүрийн харьяалагдах VPC-г бичиж тэмдэглээрэй. Тэр гурван баганын зурагт дараагийн алхам бүрийн оролт болно.

2-р алхам: маршрутлалтын хоёр шийдвэрийг нэрлэнэ үү

Эхний шийдвэр зочных: энэ пакетэд аль интерфейс, аль эх сурвалжийн хаяг. Хоёр дахь нь үүлнийх: VPC-ийн замууд болон firewall бодлого тэр интерфейсийн эргэн тойронд юу зөвшөөрдөг.

VPN рүү чиглэсэн VPC-д харагдах зам нь тэр NIC-г сонгох зочны зам болохгүй. Үүлэн зам нь сүлжээ юу хүргэж чадахыг тодорхойлдог, харин зочны зам пакет юу хийдгийг шийддэг.

3-р алхам: буцах замын бодлогыг сонгоно уу

Салбарын угтварын жижиг, тогтвортой багцад зочны тодорхой очих газрын замууд хамгийн энгийн илэрхийлэл юм: тэдгээр угтварт өгөх хариултууд VPN рүү чиглэсэн интерфейсээр гардаг. Хэд хэдэн үйлчилгээ санаатайгаар өөр өөр локал эх сурвалжийн хаяг ашигладаг бол интерфейс тус бүрд хүснэгт сонгодог эх сурвалжид суурилсан дүрмүүд хариулт бүрийг зөв контекстэд байлгадаг. Олон интерфейсийн баримт бичиг эдгээр загварууд найдаж буй NIC-ийн нэршил болон анхдагч замын зан төлөвийг тайлбарладаг.

Хүснэгт бүрт хүчинтэй холбогдсон замууд болон дараагийн үсрэлтүүд, мөн түүнээс асуух очих газрууд хэрэгтэй. Дутуу хүснэгт рүү заасан дүрэм буцах замын загвар биш. Тэр NIC-д баримтжуулсан гарцыг ашиглана уу, дэд сүлжээний харагдах байдлаас Ethernet гарц зохиохын оронд.

4-р алхам: зочны өөрийн шүүлтүүрийг шалгана уу

Сервер хаана сонсож байгаа, хариулт ямар локал эх сурвалж агуулж байгааг шалгана уу. Бүх хаяг дээр сонсдог сонсогч маршрутлалтын бодлогыг цуцлахгүй тул бүх хаягт холбогдох нь хариулт гардаг интерфейсийн хувьд юу ч өөрчлөхгүй.

Linux дээр урвуу замын баталгаажуулалтыг төлөвлөсөн загвартай харьцуулан хянана уу. Үүнийг эхний алхам болгон глобал унтраах нь маршрутлалтын алдааг хуурамчлалд өртөх эрсдэлээр сольж, таны хайж байсан тэгш бус байдлыг нуудаг.

5-р алхам: зам тус бүрд нэг урсгалыг туршина уу

Зөвшөөрөгдсөн салбарын хүсэлт болон холбоогүй интернэт хүсэлтийг тус тусад нь шалгана уу, тус бүрийг бодит эх сурвалж, очих газартай нь. Боломжтой бол хоёр интерфейс дээр бичлэг хийнэ үү, учир нь хариултыг аль интерфейс зөөсөн нь ашигтай нотолгоо. Дараа нь үүлний талын бодлого таны зохиосон замыг хүндэтгэсэн эсэхийг баталгаажуулна уу. Нэг амжилттай хүсэлт нэг урсгалыг нотолдог, тэгш хэмтэй загварыг биш.

Хоёр туршилтыг тэмдэглэлдээ тус тусад нь хадгална уу, учир нь тэд өөр замууд болон өөр firewall дүрмүүд ашигладаг.

Хоёр дахь NIC танд юу өгөхгүй вэ

Хоёр дахь интерфейс сүлжээний холболт болон өөр нэг хаяг нэмдэг. Энэ нь автомат тэгш хэмтэй маршрутлалт нэмэхгүй бөгөөд firewall бодлогыг тойрохгүй. Үүнийг маршрутлалтын засвар гэж үзэх нь олон NIC-тэй загваруудад дараа нь хэн ч тайлбарлаж чадахгүй дүрмүүд хуримтлагдах шалтгаан юм.

Хэрэв VM бусад машины трафикийг дамжуулах шаардлагатай бол тэр маршрутизаторын үүргийг тодорхой төлөвлөнө үү, дамжуулалтыг зөвшөөрдөг үүлний тохиргоо болон түүнтэй хамт явах зочны шүүлтүүрүүдийг оролцуулан.