કનેક્ટેડ એ ટનલની સ્થિતિ છે, પહોંચવાની ક્ષમતા વિશેનું નિવેદન નહીં. પોઇન્ટ-ટુ-સાઇટ ક્લાયન્ટ IKE પૂર્ણ કરી શકે, સરનામું મેળવી શકે અને તેમ છતાં ક્યાંય પણ પહોંચી ન શકે, કારણ કે ગેટવે ફક્ત એ જ નેટવર્ક માટે ટ્રાફિક ફોરવર્ડ કરે છે જે VNet પહેલેથી જાણે છે. આ પાંચ તપાસ ક્રમમાં કરો અને પ્રથમ નિષ્ફળતા પર રોકાવો. આગળ કૂદવું એટલે DNS સમસ્યાને એક કલાક સુધી ફાયરવોલ સમસ્યા તરીકે ગણવી.

ક્રમ યાદી કરતાં વધુ મહત્ત્વનો છે.

તપાસ 1: ટનલ શું વહન કરવાની છે તે નક્કી કરો

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

કંઈપણ પરીક્ષણ કરતાં પહેલાં ક્લાયન્ટ ક્યાં પહોંચવું જોઈએ તે લખો. તે યાદી વિના, દરેક આંશિક પરિણામ પ્રગતિ જેવું લાગે છે.

તપાસ 2: પ્રમાણપત્રો પહેલાં સરનામાં જગ્યાઓ સરખાવો

ઓવરલેપ વિશાળ શ્રેણીઓ પર નક્કી થાય છે, તેથી સબનેટ સ્તરે જુદા દેખાતા બે નેટવર્ક પણ જો તેમના મૂળ બ્લોક ઓવરલેપ થાય તો અથડાય છે. ગેટવે સબનેટ સમર્પિત અને SKU માટે પૂરતું મોટું હોવું જોઈએ, અને ક્લાયન્ટ સરનામા પૂલ VNet અથવા peering દ્વારા પહોંચી શકાય તેવી કોઈપણ વસ્તુ સાથે અથડાવું ન જોઈએ. યોજના બદલો અને ફરી ડિપ્લોય કરો, કારણ કે વળતર માટે રૂટ ઉમેરવાથી એવી ટનલ બને છે જે કેટલાક ગંતવ્યો માટે કામ કરે છે અને અન્ય માટે અસ્પષ્ટ રીતે નહીં. અહીં પ્રોવિઝનિંગ મોટેથી નિષ્ફળ જાય છે, જે સારો કિસ્સો છે.

પ્રમાણીકરણ આગળનું દ્વાર છે. પ્રમાણપત્ર, RADIUS અને Entra ID પ્રોફાઇલ અદલાબદલી કરી શકાય તેવા નથી, અને દરેક માટે ક્લાયન્ટ પેકેજ અલગ છે.

તપાસ 3: અંદરથી ખાનગી નામ ઉકેલો

ક્લાયન્ટ પોતાનું રિઝોલ્વર રાખે છે, સિવાય કે ડાઉનલોડ કરેલી પ્રોફાઇલમાં VNet ના DNS સર્વર હોય, અને તે યાદી ડાઉનલોડ સમયે જ એમ્બેડ થાય છે. VNet ની અંદર ફોરવર્ડર ઉમેરો, તેને VNet ના DNS સર્વર તરીકે સેટ કરો, પછી ક્લાયન્ટ પેકેજ ફરી ડાઉનલોડ કરીને આયાત કરો. જૂનું પેકેજ ફરી વાપરવાથી ફક્ત જૂની રિઝોલ્વર યાદીનું પરીક્ષણ થાય છે.

પહેલાં સરનામાનું પરીક્ષણ કરો, કારણ કે તે એક જ પગલામાં રૂટિંગને નામકરણથી અલગ કરે છે: Test-NetConnection 10.20.1.4 -Port 3389.

જો સરનામું જવાબ આપે અને નામ નહીં, તો રિઝોલ્વરને સીધું પૂછો Resolve-DnsName files.corp.example -Server 10.20.0.4. જો બંને નિષ્ફળ જાય, તો દોષ DNS નો નથી અને તમારે DNS સેટિંગ્સ સંપાદિત કરવાનું બંધ કરવું જોઈએ. 168.63.129.16 પરનું Azure પ્લેટફોર્મ DNS ફક્ત VNet ની અંદરથી જ જવાબ આપે છે, તેથી બહારનો ક્લાયન્ટ તે સરનામાને રિઝોલ્વર તરીકે વાપરી શકતો નથી.

તપાસ 4: ટનલ પાછળની સેવાનું પરીક્ષણ કરો

સ્વસ્થ ટનલ અને બંધ પોર્ટ ક્લાયન્ટની દૃષ્ટિએ એકસમાન દેખાય છે. મહેમાન ફાયરવોલ તપાસો, પછી સબનેટ અથવા NIC પરનું નેટવર્ક સિક્યોરિટી ગ્રુપ, પછી સેવા ખાનગી સરનામા પર સાંભળે છે કે ફક્ત loopback પર. ઇન્ટરનેટ તરફ નિયમ ખોલવાને બદલે ક્લાયન્ટ પૂલને સ્રોત તરીકે મંજૂરી આપો, અને યાદ રાખો કે Azure Files માટે SMB ને ખાનગી એન્ડપોઇન્ટનો માર્ગ ટનલ દ્વારા રૂટ થવો જરૂરી છે. જ્યારે સંસાધન IP દ્વારા જવાબ આપે પણ નામ દ્વારા નહીં, ત્યારે ગેટવેને અડવાને બદલે તપાસ 3 પર પાછા જાઓ.

એક કોષ્ટક કામ કરતી વખતે સ્તરોને અલગ રાખે છે:

SymptomLayer to check
Name fails, private IP worksResolver setting or forwarder
Private IP also failsAddress plan, NSG, guest firewall
Private works, internet failsExpected; the gateway is not an egress
Connects, then dropsTunnel type or certificate mismatch

તપાસ 5: એસ્કેલેટ કરતાં પહેલાં પ્રોફાઇલ નોંધો

ટિકિટમાં ગેટવે પ્રકાર, ટનલ પ્રકાર, પ્રમાણીકરણ પદ્ધતિ અને ક્લાયન્ટ ઓપરેટિંગ સિસ્ટમ લખો. પ્રમાણપત્રવાળી IKEv2 પ્રોફાઇલ અને RADIUS પ્રોફાઇલ જુદા જુદા કારણોસર નિષ્ફળ જાય છે, અને બીજા ટનલ પ્રકાર માટે બનેલો ક્લાયન્ટ ફક્ત ત્યારે જ કનેક્ટ થાય છે જ્યારે ગેટવે સુસંગત પ્રોટોકોલ આપે.

નાની ટીમ માટે ટકાઉ ડિઝાઇન એ એક VNet, એક DNS ફોરવર્ડર અને દસ્તાવેજીકૃત split-tunnel ક્લાયન્ટ છે. જો જરૂરિયાત નિશ્ચિત જાહેર એગ્રેસ હોય, તો તમે નિયંત્રિત કરો છો તેવા ફાયરવોલ પર સાઇટ-ટુ-સાઇટ ટનલ સમાપ્ત કરો અને ઇન્ટરનેટ ટ્રાફિક ત્યાં રૂટ કરો, પોઇન્ટ-ટુ-સાઇટ ગેટવેને એવું કામ કરવાનું કહેવાને બદલે જેના માટે તે ક્યારેય બનાવાયું નથી.

સંબંધિત લેખો