સાઇટ-થી-સાઇટ VPN એક જ દિશામાં કામ કરે છે: બે જુદી જુદી ખામીઓ

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

એ ભેદ જ નક્કી કરે છે કે કયા આદેશો ચલાવવા યોગ્ય છે.

એકસરખી દેખાતી બે ખામીઓ

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

પૂછો કે નિષ્ફળ થયેલો પ્રયાસ કઈ બાજુએ શરૂ કર્યો હતો. એ એક હકીકત જ અડધા સંભવિત કારણો દૂર કરે છે.

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

પ્રથમ કિસ્સો: પરત માર્ગ ગેરહાજર છે

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

અનુવાદ પછી ગંતવ્ય ખરેખર જે સરનામું જુએ છે તે ચકાસો, અને મૂળ સબનેટને બદલે એ સરનામા માટે પરત રૂટ ચકાસો.

બીજો કિસ્સો: નીતિએ તેને કદી મંજૂરી આપી નહોતી

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

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

એ જ હોસ્ટ પર પહેલાં અને પછીની સરખામણી કરો

એક જ પ્રયાસના બંને છેડા જુઓ, બે અલગ પ્રયાસો નહીં. શરૂ કરતા હોસ્ટના ગેટવે પર અને ગંતવ્ય પર કૅપ્ચર કરો, પછી સરખાવો કે શું અંદર આવ્યું, શું બહાર ગયું અને દૂરની બાજુએ કયું સરનામું જોયું.

tcpdump -ni any host 10.20.30.40 and port 445
conntrack -L | grep 10.20.30.40
ip route get 10.20.30.40
swanctl --list-sas

જો ગંતવ્ય પરનું કૅપ્ચર વિનંતી અણધાર્યા સ્રોત સરનામા સાથે બતાવે, તો જવાબ અનુવાદ કે રાઉટિંગમાં છે, ટનલની સુરક્ષા નીતિમાં નહીં. જો ગંતવ્ય કોઈ વિનંતી જ બતાવતું નથી, તો પેકેટ કદી સુરક્ષિત માર્ગ પાર કર્યો નથી.

સુધારા પછી એ જ હોસ્ટથી એ જ પરીક્ષણ ફરીથી કરો અને ખાતરી કરો કે અસંબંધિત પ્રવેશ હજી નકારાય છે. “established” ટનલ સ્થિતિ એકલી બંનેમાંથી કોઈ પણ તારણને ટેકો આપતી નથી.