L2TP/IPsec એક નેટવર્ક પર જોડાય છે અને બીજા પર સમય પૂરો થાય છે

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

નેટવર્કની સરખામણી પહેલાં ક્લાયન્ટ નક્કી કરો

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

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

ચાર તબક્કા, ચાર અલગ ભૂલ સંદેશ

L2TP/IPsec કનેક્શન ચાર તબક્કામાંથી પસાર થાય છે, અને RFC 3193 એ ગોઠવણીનું વર્ણન કરે છે જે પહેલા બેને જોડે છે. IKE વાટાઘાટ એ જગ્યા છે જ્યાં ફિલ્ટર કરેલો માર્ગ શાંત સમય-સમાપ્તિ પેદા કરે છે. IPsec પ્રમાણીકરણ એ જગ્યા છે જ્યાં પ્રમાણપત્ર અથવા અગાઉ શેર કરેલી કીની અસમાનતા તેના બદલે સ્પષ્ટ અસ્વીકાર પેદા કરે છે. L2TP ટનલની સ્થાપના એ જગ્યા છે જ્યાં પહેલેથી સ્થાપિત સુરક્ષા સંગઠન તો પણ ક્યાંય ન લઈ જઈ શકે, અને PPP લોગિન એ જગ્યા છે જ્યાં ખોટું ક્રેડેન્શિયલ આખરે દેખાતી નિષ્ફળતા પેદા કરે છે. જે તબક્કો અટક્યો તેનો લોગ વાંચો, છેલ્લી છપાયેલી લાઇનનો નહીં.

journalctl -u strongswan --since '-5 min' | tail -20
journalctl -u xl2tpd --since '-5 min' | tail -20
ip -4 route get 198.51.100.10

strongSwan નો લોગ દર્શાવે છે કે IKE આદાનપ્રદાન કોઈ પ્રસ્તાવ સુધી પહોંચ્યું કે નહીં અને સામેની બાજુએ બિલકુલ જવાબ આપ્યો કે નહીં, જે પહોંચને નીતિથી અલગ કરે છે. xl2tpd નો લોગ જ્યાં IPsec સમાપ્ત થાય ત્યાંથી ચાલુ રહે છે, તેથી તે લોગમાં કંઈ ન હોય તેવું સ્થાપિત સુરક્ષા સંગઠન L2TP તબક્કા તરફ સંકેત કરે છે. રૂટ પ્રશ્ન પુષ્ટિ કરે છે કે ક્લાયન્ટ તમે ધારો છો તે સર્વર સરનામા તરફ મોકલી રહ્યું છે, અને આ અગાઉના નેટવર્કથી વારસાગત મળેલો જૂનો DNS જવાબ પકડે છે. સાથે મળીને, ત્રણ આઉટપુટ લક્ષણને બદલે તબક્કાનું નામ આપે છે.

NAT ની ઊંડાઈ અને સહાયકનું વર્તન સરખાવો

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

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

બહાર જતું ક્લાયન્ટ, અંદર આવતું સર્વર: બે અલગ સમસ્યાઓ

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

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