બીજી WAN VPN એન્ટ્રી નિષ્ફળ જાય છે જ્યારે પ્રાથમિક કામ કરતી રહે છે

પ્રાથમિક ટનલ ચાલુ રહે છે, વપરાશકર્તાઓ કામ ચાલુ રાખે છે, અને બીજું ISP સર્કિટ તમે શું બદલો તો પણ નિષ્ક્રિય પડ્યું રહે છે. તમે બેકઅપ સર્કિટ માટે સરનામું પ્રકાશિત કર્યું, તેના પર નામ દિશામાન કર્યું, કદાચ ક્લાયન્ટમાં બેકઅપ એન્ટ્રી ઉમેરી, અને ક્લાયન્ટ ક્યારેય તેનો પ્રયાસ કરતું નથી અથવા પ્રમાણીકરણ કરીને પછી મરી જાય છે. મેં અનુસરેલા કિસ્સાઓમાં ફેલઓવર સુવિધા સામાન્ય રીતે ઠીક હતી; જે ખૂટતું હતું તે પાંચમાંથી એક વસ્તુ હતી જે એન્ટ્રીને ઉપયોગી બનાવે છે. નામ બેકઅપ સરનામા પર ઉકેલાઈ શકે છે જ્યારે તે ઇન્ટરફેસ પર કંઈ સાંભળતું નથી, અને શ્રોતા કનેક્શન સ્વીકારી શકે છે જ્યારે જવાબ પ્રાથમિક માર્ગે નીકળે છે. દરેક WANને પોતાના કરાર સાથે અલગ એન્ટ્રી તરીકે ગણો અને નિષ્ફળતા ક્લાયન્ટ બગ જેવી લાગવાનું બંધ કરે છે.

દરેક WANને પોતાનો એન્ટ્રી કરાર જોઈએ

દરેક WAN માટે પાંચ ક્ષેત્રો નોંધો: જાહેર નામ અને સરનામું, ટ્રાન્સપોર્ટ અને પોર્ટ, તેને સમાપ્ત કરતું ઇન્ટરફેસ અથવા સંદર્ભ, જે પીઅર ઓળખ તે પ્રસ્તુત કરવી જોઈએ, અને જવાબ ક્યાંથી નીકળે છે. બે સર્કિટ એટલે બે સંપૂર્ણ સેટ. જો બીજા સેટમાં સમાપ્ત કરતું ઇન્ટરફેસ કે પરત માર્ગ ન હોય, તો તમારી પાસે બેકઅપ એન્ટ્રી નથી; તમારી પાસે DNS રેકોર્ડ છે જે ઇરાદો વર્ણવે છે.

ઉપકરણ અને તેની આવૃત્તિએ પણ આ ગોઠવણને સમર્થન આપવું જોઈએ. DNS રેકોર્ડ બીજા ઇન્ટરફેસ પર સેવા ખોલી શકતું નથી, અને ઘણા પ્લેટફોર્મ પર શ્રોતા ઉપકરણ પ્રમાણે નહીં પણ સરનામા પ્રમાણે રૂપરેખાંકિત થાય છે. ASA પર ઇન્ટરફેસ-આધારિત IPsec ક્રિપ્ટો મેપ અને ટનલ જૂથોને બહારના ઇન્ટરફેસ સાથે જોડે છે, તેથી બીજા અપલિંકને તે પોલિસી જોઈએ જ્યાં એ પેકેટ ખરેખર પહોંચે છે. રૂટ-આધારિત ડિઝાઇન અલગ વર્તે છે: શ્રોતા દરેક સરનામા સાથે અથવા એક નામવાળા સરનામા સાથે જોડાઈ શકે છે, અને એ પસંદગી નક્કી કરે છે કે ISP B બિલકુલ જવાબ આપી શકે છે કે નહીં.

ચકાસો કે બીજું WAN ખરેખર જવાબ આપે છે

બંને સર્કિટની બહારથી પરીક્ષણ કરો, ગેટવે પાછળની મશીનથી નહીં, અને ક્લાયન્ટ પ્રોફાઇલ જે ચોક્કસ નામ વાપરે છે તેનું પરીક્ષણ કરો. TLS શ્રોતા માટે ઝડપી ચકાસણી openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts છે, જે તમારા નેટવર્કની બહારના હોસ્ટ પરથી ચલાવવામાં આવે છે. તમારે પૂર્ણ થયેલું હેન્ડશેક જોઈએ જેની સાંકળ પ્રોફાઇલના નામ સાથે મેળ ખાય, ફક્ત TCP પોર્ટ નહીં જે કનેક્શન સ્વીકારે.

RFC 9525 સમજાવે છે કે ક્લાયન્ટ શું ચકાસે છે: જે ઓળખ સુધી પહોંચવાનું ઇરાદું હતું, તેને સેવા જે પ્રમાણપત્ર પ્રસ્તુત કરે છે તેની સાથે સરખાવે છે. બીજી એન્ટ્રી જે પ્રાથમિક એન્ટ્રીનું પ્રમાણપત્ર પરત આપે છે, અથવા ડિફોલ્ટ પ્રમાણપત્ર જે બંને નામોમાંથી કોઈને સૂચિબદ્ધ કરતું નથી, આ પરીક્ષણમાં નિષ્ફળ જાય છે છતાં પોર્ટ ખુલ્લો છે અને ફાયરવોલ તેને મંજૂરી આપે છે.

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

જવાબને અનુસરો, ફક્ત વિનંતીને નહીં

બીજું WAN સામાન્ય રીતે પરત માર્ગે તૂટે છે. વિનંતી ISP B થઈને આવે છે, ઉપકરણ જવાબ આપે છે, અને જવાબ ISP A પરના ડિફોલ્ટ રૂટ થઈને એવા સ્રોત સરનામા સાથે નીકળે છે જે ક્લાયન્ટે ક્યારેય માંગ્યું ન હતું. સ્ટેટફુલ ટ્રાન્સલેશન તેને વધુ ખરાબ કરે છે: જો મેપિંગ પ્રાથમિક ઇન્ટરફેસ માટે બનાવવામાં આવ્યું હોય, તો પરત આવતું પેકેટ ટ્રાન્સલેશન ચૂકી જાય છે અથવા એવો સ્રોત વહન કરે છે જે ક્લાયન્ટની ફાયરવોલ ફેંકી દે છે. પ્રદાતાઓ પણ એવા સ્રોત સરનામા ફેંકી દે છે જે તેમણે આપેલા સર્કિટના નથી, તેથી આ સ્વચ્છ પ્રોટોકોલ ભૂલને બદલે એકમાર્ગી બ્લેક હોલ જેવું લાગે છે.

બીજી એન્ટ્રીમાંથી ઉદ્ભવતા ટ્રાફિક માટે રૂટિંગ નિર્ણય ચકાસો. જવાબ તે ઇન્ટરફેસ છોડવો જોઈએ જ્યાં વિનંતી આવી હતી, અથવા ઓછામાં ઓછું એવું સરનામું વહન કરવું જોઈએ જે દૂરની બાજુ તે માર્ગનું ગણીને સ્વીકારે. પોલિસી-રૂટિંગ પ્લેટફોર્મ પર તેનો અર્થ ઇનકમિંગ ઇન્ટરફેસ અથવા અનુવાદિત સ્રોત સાથે જોડાયેલો નિયમ, ઉપરાંત દરેક બહારના ઇન્ટરફેસ સાથે બંધાયેલું ટ્રાન્સલેશન વિધાન છે. ક્લાયન્ટ જોડાય ત્યારે એકસાથે બંને ઇન્ટરફેસ પર કેપ્ચર કરો; ISP B પર આવતું SYN અને ISP A પરથી નીકળતું SYN-ACK એક જ દોડમાં પ્રશ્ન હલ કરે છે.

ક્લાયન્ટને બીજી એન્ટ્રી વિશે જાણવાનો રસ્તો આપો

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

પદ્ધતિ ગમે તે હોય, ક્લાયન્ટે પ્રાથમિક માર્ગ ગુમાવતા પહેલાં વૈકલ્પિક નામ ઉકેલી શકવું જોઈએ. એ જ નિર્ભરતા લોકો ચૂકી જાય છે: જો બેકઅપ નામનો જવાબ એવા રિઝોલ્વર દ્વારા મળે જે ફક્ત હમણાં નિષ્ફળ ગયેલી ટનલ દ્વારા પહોંચી શકાય, તો ફોલબેક શરૂ પણ થઈ શકતું નથી. બીજું નામ એવા રિઝોલ્વરમાં પ્રકાશિત કરો જે સ્થાનિક રીતે અથવા ઇન્ટરનેટ દ્વારા જવાબ આપે. સ્થળાંતર પછી નવું પ્રમાણીકરણ અને નવું એપ્લિકેશન સત્ર અપેક્ષિત કરો, કારણ કે ક્લાયન્ટ ફેલઓવર સ્ટેટફુલ ફેલઓવર નથી અને લાંબા સત્રો તેમાંથી પસાર થતાં નથી.

બે પ્રદાતાઓ પર એક સરનામું એ બીજું ઉત્પાદન છે

એક જાહેર સરનામું બંને સર્કિટ દ્વારા પહોંચી શકાય તેવું રાખવું એ રૂટિંગ સેવા છે, VPNમાંનું ચેકબોક્સ નહીં. તેને એવી સરનામા જગ્યા જોઈએ જે બંને પ્રદાતાઓ વહન કરવા તૈયાર હોય, જે તેમના નેટવર્ક સ્વીકારે તે રીતે જાહેર કરાયેલી હોય, અને પ્રદાતા-સ્વતંત્ર જગ્યા તથા BGP સાથેનું મલ્ટિહોમિંગ તે જ આપે છે. ISP Aનું સરનામું ISP Bના ઇન્ટરફેસ પર સોંપવાથી ત્યાં પહોંચાય નહીં; પેકેટ એવા નેટવર્ક પર પહોંચે છે જેણે ક્યારેય પ્રીફિક્સની જાહેરાત કરી નથી અને ઉપરવાસમાં ફેંકાઈ જાય છે.

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

આગળ શું ચકાસવું

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

દરેક WAN માટે સરનામું, પોર્ટ, સમાપ્ત કરતું ઇન્ટરફેસ, પ્રમાણપત્રનું નામ, પરત માર્ગ અને ટ્રાન્સલેશન નિયમ સાથે ટૂંકો રેકોર્ડ રાખો, અને સર્કિટ, NAT ઉપકરણ કે ક્લાયન્ટ આવૃત્તિ બદલાય ત્યારે તેને ફરી ચકાસો. નિષ્ક્રિય બેકઅપ માર્ગ ચૂપચાપ સડી જાય છે: કોઈ વાપરતું નથી તે એન્ટ્રી વિશે કોઈ ચેતવણી આપતું નથી, જે દિવસે બધા તેના પર નિર્ભર બને તે દિવસ સુધી.