અનેક NIC સાથેની GCP VM: જવાબો ખોટા ઇન્ટરફેસમાંથી કેમ નીકળે છે

Compute Engine VMમાં બીજું ઇન્ટરફેસ જોડવાથી તેને બીજું નેટવર્ક જોડાણ મળે છે, સપ્રમાણ પરત માર્ગ નહીં। ગેસ્ટ હજી પણ પોતાના રૂટ અને નિયમોમાંથી ઇન્ટરફેસ અને સ્રોત સરનામું પસંદ કરે છે। પછી Google Cloud પેકેટ જે ઇન્ટરફેસમાંથી નીકળ્યું તેની આસપાસ VPC રૂટિંગ અને ફાયરવોલ નીતિ લાગુ કરે છે। જ્યારે એ બે નિર્ણયો મળતા નથી, વિનંતીઓ એક NIC પર આવે છે અને જવાબો બીજીમાંથી નીકળે છે, અને શાખા અર્ધ-ખુલ્લી વાતચીત જુએ છે।

પાંચ પગલામાં માર્ગ ચાલો અને નીતિ નિયમ લખતા પહેલા અસંગતિ દેખાશે।

પગલું 1: ક્લાઉડ NICને ગેસ્ટ ઉપકરણો સાથે મેળવો

ક્લાઉડ ઇન્ટરફેસને nic0, nic1 વગેરે નામ આપે છે, અને ગેસ્ટ એવા ઉપકરણ નામ જુએ છે જે મેળ ખાવાની જરૂર નથી। બીજું કંઈ પણ કરતા પહેલા ઇન્સ્ટન્સ મેટાડેટા અથવા ઇન્ટરફેસના પોતાના સરનામેથી મેપિંગ ઉકેલો। DHCP આપેલો સામાન્ય ડિફોલ્ટ રૂટ nic0 સાથે સંકળાયેલો છે, તેથી ઇન્ટરનેટ તરફનો માર્ગ ઘણી વાર આકસ્મિક રીતે જીતી જાય છે। અનુમાનિત ઉપકરણ નામ સામે નીતિ લખવી એ છે કે કેવી રીતે સાચો નિયમ ખોટા ઇન્ટરફેસ પર પહોંચે છે।

સરનામાં, ઉપકરણ નામ અને દરેક જે VPCનું છે તે નોંધો। એ ત્રણ-કોલમ નકશો દરેક પછીના પગલાનું ઇનપુટ છે।

પગલું 2: બે રૂટિંગ નિર્ણયોને નામ આપો

પહેલો નિર્ણય ગેસ્ટનો છે: આ પેકેટ માટે કયું ઇન્ટરફેસ અને કયું સ્રોત સરનામું। બીજો ક્લાઉડનો છે: VPCના રૂટ અને ફાયરવોલ નીતિ તે ઇન્ટરફેસની આસપાસ શું મંજૂરી આપે છે।

VPN તરફના VPCમાં દેખાતો રૂટ તે NIC પસંદ કરતો ગેસ્ટ રૂટ બનતો નથી। ક્લાઉડ રૂટ વર્ણવે છે કે નેટવર્ક શું પહોંચાડી શકે, જ્યારે ગેસ્ટ રૂટ નક્કી કરે છે કે પેકેટ શું કરે।

પગલું 3: પરત માર્ગની નીતિ પસંદ કરો

શાખા પ્રીફિક્સના નાના, સ્થિર સમૂહ માટે ગેસ્ટમાં સ્પષ્ટ ગંતવ્ય રૂટ સૌથી સરળ અભિવ્યક્તિ છે: તે પ્રીફિક્સના જવાબો VPN તરફના ઇન્ટરફેસમાંથી નીકળે છે। જ્યારે ઘણી સેવાઓ જાણી જોઈને જુદાં સ્થાનિક સ્રોત સરનામાં વાપરે છે, ત્યારે દરેક ઇન્ટરફેસ માટે ટેબલ પસંદ કરતા સ્રોત-આધારિત નિયમો દરેક જવાબને યોગ્ય સંદર્ભમાં રાખે છે। અનેક ઇન્ટરફેસનું દસ્તાવેજીકરણ NIC નામકરણ અને ડિફોલ્ટ-રૂટ વર્તન વર્ણવે છે જેના પર આ ડિઝાઇન આધાર રાખે છે।

દરેક ટેબલને માન્ય જોડાયેલા રૂટ અને આગલા હોપની જરૂર છે, ઉપરાંત જે ગંતવ્યો માટે તેને પૂછવામાં આવશે। અપૂર્ણ ટેબલ તરફ નિર્દેશ કરતો નિયમ પરત-માર્ગ ડિઝાઇન નથી। તે NIC માટે દસ્તાવેજી ગેટવે વાપરો, સબનેટના દેખાવ પરથી Ethernet ગેટવે શોધવાને બદલે।

પગલું 4: ગેસ્ટના પોતાના ફિલ્ટર તપાસો

સર્વર ક્યાં સાંભળે છે અને જવાબ કયું સ્થાનિક સ્રોત લઈ જાય છે તે તપાસો। બધા સરનામાં પર સાંભળતો શ્રોતા રૂટિંગ નીતિને રદ કરતો નથી, તેથી બધા સરનામાં સાથે જોડાવાથી જવાબ જે ઇન્ટરફેસમાંથી નીકળે છે તેમાં કંઈ બદલાતું નથી।

Linux પર, ઇચ્છિત ડિઝાઇન સામે રિવર્સ-પાથ માન્યતા તપાસો। પહેલા પગલા તરીકે તેને વૈશ્વિક રીતે બંધ કરવું રૂટિંગ ભૂલને સ્પૂફિંગ જોખમ સાથે બદલે છે, અને તમે શોધવા માગતા હતા તે અસમપ્રમતાને છુપાવે છે।

પગલું 5: દરેક માર્ગ માટે એક પ્રવાહ ચકાસો

મંજૂર શાખા વિનંતી અને અસંબંધિત ઇન્ટરનેટ વિનંતી અલગ રીતે ચકાસો, દરેક તેના વાસ્તવિક સ્રોત અને ગંતવ્ય સાથે। જ્યારે શક્ય હોય ત્યારે બંને ઇન્ટરફેસ પર કેપ્ચર કરો, કારણ કે ઉપયોગી પુરાવો એ છે કે કયા ઇન્ટરફેસે જવાબ વહન કર્યો। પછી ખાતરી કરો કે ક્લાઉડ-બાજુની નીતિએ તમે ડિઝાઇન કરેલા માર્ગનું સન્માન કર્યું। એક સફળ વિનંતી એક પ્રવાહ સાબિત કરે છે, સપ્રમાણ ડિઝાઇન નહીં।

બે પરીક્ષણોને તમારી નોંધોમાં અલગ રાખો, કારણ કે તે જુદા રૂટ અને જુદા ફાયરવોલ નિયમોનો ઉપયોગ કરે છે।

બીજી NIC તમને શું આપતી નથી

બીજું ઇન્ટરફેસ નેટવર્ક જોડાણ અને બીજું સરનામું ઉમેરે છે। તે આપોઆપ સપ્રમાણ રૂટિંગ ઉમેરતું નથી અને ફાયરવોલ નીતિને ટાળતું નથી। તેને રૂટિંગ સુધારણા તરીકે ગણવું એ કારણ છે કે અનેક NIC ડિઝાઇનમાં એવા નિયમો જમા થાય છે જે પછી કોઈ સમજાવી શકતું નથી।

જો VMએ અન્ય મશીનોનું ટ્રાફિક ફોરવર્ડ કરવું હોય, તો એ રાઉટર ભૂમિકા સ્પષ્ટ રીતે યોજો, જેમાં ફોરવર્ડિંગની મંજૂરી આપતું ક્લાઉડ સેટિંગ અને તેની સાથે જતા ગેસ્ટ ફિલ્ટરનો સમાવેશ થાય છે।