Azure નું IP ફ્લો વેરિફાય કહે છે મંજૂર, પણ VPN હજુ પણ નિષ્ફળ જાય છે

સાઇટ-ટુ-સાઇટ ટનલ જોડાયેલી છે, VM સ્વસ્થ છે, પણ ઓન-પ્રેમાઇઝ ક્લાયન્ટને કંઈ મળતું નથી. તમે Network Watcher ખોલો છો, IP ફ્લો વેરિફાય ચલાવો છો, અને તે કહે છે Access allowed, તેથી ટિકિટ VPN સમસ્યા તરીકે બંધ થાય છે. આ પરિણામ દેખાય છે તેવું અર્થ ધરાવતું નથી, કારણ કે IP ફ્લો વેરિફાય તમે વર્ણવેલા ફ્લો માટેની સુરક્ષા નિયમોનું મૂલ્યાંકન કરે છે અને Azure પાસે તમારા ઓન-પ્રેમાઇઝ પ્રીફિક્સ સુધીનો રૂટ છે કે નહીં તે ક્યારેય ચકાસતું નથી.

ફિલ્ટરિંગ પ્રશ્ન અને રાઉટિંગ પ્રશ્ન અલગ છે, અને Network Watcher તેમને જુદા જુદા સાધનોથી જવાબ આપે છે. તમે કયો પૂછ્યો તે જાણવું એ નિદાનનો મોટો ભાગ છે.

IP ફ્લો વેરિફાય ખરેખર શું નક્કી કરે છે

IP ફ્લો વેરિફાય એક VM, નેટવર્ક ઇન્ટરફેસ, દિશા, પાંચ-ગણા મૂલ્યો અને પ્રોટોકોલ લે છે, પછી તે ફ્લો માટે NSG અને સુરક્ષા-વ્યવસ્થાપક નિયમનો નિર્ણય જણાવે છે. તે TCP અને UDP પર કામ કરે છે, તેથી તે ICMP નિયમ પરીક્ષક નથી અને અવરોધિત ping તમારી સેવા વિશે કંઈ સાબિત કરતું નથી. તેને અનુમાનને બદલે વાસ્તવિક ફ્લો આપો. ઓન-પ્રેમાઇઝથી ડેટાબેઝ પોર્ટ સુધીનું ઇનબાઉન્ડ કનેક્શન, VM શરૂ કરે તે આઉટબાઉન્ડ કનેક્શન કરતાં જુદું વર્ણન છે.

જો ગેટવે સરનામાંનું ભાષાંતર કરે છે, તો તમે મૂલ્યાંકન કરી રહ્યા છો તે સીમા સુધી પહોંચતું સ્રોત સરનામું વાપરો, ક્લાયન્ટ કોન્ફિગમાંનું નહીં. પરિણામ પણ જે છે તે પ્રમાણે વાંચો. Access allowed એટલે કે ફિલ્ટર સ્તર પેકેટ આવે તો મંજૂરી આપે, અને તેનાથી વધુ કંઈ નહીં.

તે તમને જે કહી શકતું નથી તે છે Azure એ પસંદ કરેલો રૂટ, ગેસ્ટ ફાયરવોલ પોર્ટને મંજૂરી આપે છે કે નહીં, અથવા કંઈ સાંભળી રહ્યું છે કે નહીં. તે અન્ય સ્તરોમાં રહે છે.

આગળનો હોપ અને અસરકારક રૂટ શું ઉમેરે છે

આગળનો હોપ ફોરવર્ડિંગ પ્રશ્નનો જવાબ આપે છે: આ ગંતવ્ય માટે Azure કયો આગળના હોપનો પ્રકાર પસંદ કરે છે, કયા સરનામે, કયા રૂટ ટેબલમાંથી. અસરકારક રૂટ સૂચિબદ્ધ કરે છે કે NIC પાસે ખરેખર શું છે. બંને ચલાવો અને તમને Azure બાજુનો માર્ગ મળે છે જે લીલું IP ફ્લો વેરિફાય ખાલી છોડી દે છે.

Microsoft નું IP ફ્લો વેરિફાય ઝાંખી ફિલ્ટરિંગ વ્યાપ સીધો જણાવે છે, જ્યારે આગળના હોપ અને રૂટ-નિદાન પૃષ્ઠો ફોરવર્ડિંગ બાજુને આવરી લે છે. તમે તારણ લખો ત્યારે યોગ્ય પૃષ્ઠ ટાંકો.

આદેશો શેલમાંથી ચલાવવા પૂરતા ટૂંકા છે. az network nic show-effective-route-table ઇન્ટરફેસ પર લાગુ થયેલા રૂટની સૂચિ આપે છે. az network watcher show-next-hop સ્રોત અને ગંતવ્ય સાથે પસંદ કરેલો હોપ પરત આપે છે. તમારા માટે મહત્વનું પ્રીફિક્સ તે ટેબલ સાથે સરખાવો, પછી કઈ એન્ટ્રી જીતે છે તેની ખાતરી કરો.

VM ના NIC થી પરતનો માર્ગ ચાલો

આ લક્ષ્ય VM ના NIC થી, ઓન-પ્રેમાઇઝ ક્લાયન્ટ પ્રીફિક્સ માટે કરો, ઇન્ટરનેટ માટે નહીં. પરતનો માર્ગ એ છે જ્યાં સાઇટ-ટુ-સાઇટ ખામીઓ છુપાય છે, કારણ કે ટનલ-સ્થિતિ ચકાસણી ફક્ત એ જણાવે છે કે સુરક્ષા સંગઠનો ઉપર છે.

જો અપેક્ષિત રૂટ ખૂટે છે, તો ગેટવે કોન્ફિગ આપે છે તે રિમોટ પ્રીફિક્સ, VNet કનેક્ટિવિટી ડિઝાઇન અને કોઈપણ રૂટ-પ્રસાર સેટિંગ તપાસો. સ્થાનિક નેટવર્ક ગેટવે ઑબ્જેક્ટ ઓન-પ્રેમાઇઝ બાજુનું વર્ણન કરે છે; તેનું અસ્તિત્વ સાબિત કરતું નથી કે દરેક જરૂરી પ્રીફિક્સ NIC પર હાજર છે અને પ્રાધાન્ય પામે છે. આ જુદી જુદી હકીકતો છે, અને તેમાંથી ફક્ત એક જ પોર્ટલ સારાંશમાં દેખાય છે.

ઉદાહરણ કૉપિ કરવાને બદલે આગળના હોપનો પ્રકાર વાંચો

મેનેજ્ડ VPN ગેટવે માર્ગ સામાન્ય રીતે આગળના હોપ પ્રકાર તરીકે VirtualNetworkGateway બતાવે છે. VirtualAppliance જુદી ફોરવર્ડિંગ ડિઝાઇનનું વર્ણન કરે છે, સામાન્ય રીતે ફાયરવોલ અથવા નેટવર્ક વર્ચ્યુઅલ એપ્લાયન્સ.

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

હજુ નિષ્ફળ જતી સીમા તરફ જાઓ

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

મંજૂર એપ્લિકેશન વિનંતી અને બંને છેડાના અવલોકનો સાથે સમાપ્ત કરો. allow પરિણામ અને સાચો આગળનો હોપ એ પુરાવાના બે ટુકડા છે, કનેક્શન સફળ થયું તેનો પુરાવો નહીં.