જવાબ વિનાનું આઉટબાઉન્ડ ESP એટલે VPN મૃત છે એમ નહીં
ESP દરેક સંગઠન માટે એક દિશા રક્ષે છે અને કંઈ સ્વીકારતું નથી. સર્વરને પ્રતિસાદહીન કહેતા પહેલાં આંતરિક સંવાદ અને ઇનબાઉન્ડ SA મેળવો.
તમે IPsec હોસ્ટ પર ટ્રાફિક કેપ્ચર કર્યો, ESP પેકેટ જતા જોયા, કંઈ પાછું આવતું જોયું નહીં અને નિષ્કર્ષ કાઢ્યો કે દૂરની બાજુ બગડેલી છે. કેપ્ચર એ નિષ્કર્ષને સમર્થન આપતું નથી. ESP સંવાદની એક દિશા રક્ષે છે અને IP સ્તરે કંઈ સ્વીકારતું નથી, તેથી પરત ESP ન હોવું એટલું જ સહેલાઈથી એમ પણ હોઈ શકે કે એપ્લિકેશન પાસે કહેવા જેવું કંઈ ન હતું, જેટલું સહેલું કે ટનલ મૃત છે. કોઈપણ છેડાને દોષ આપતા પહેલાં આંતરિક આદાનપ્રદાન અને સ્વીકાર બાજુની સ્થિતિ વાંચો.
દંતકથા: દરેક સુરક્ષિત પેકેટ જવાબનો હકદાર છે
ESP એ વિનંતી-જવાબ પ્રોટોકોલ નથી. નીતિ જે પસંદ કરે તે બધું તે એન્ક્રિપ્ટ અને પ્રમાણિત કરે છે, અને સ્વીકારક પોતાનું પેકેટ બનાવ્યા વગર એ આંતરિક પેકેટની ચકાસણી, ડિક્રિપ્શન અને વિતરણ કરે છે. ગંતવ્ય જે UDP પ્રશ્નને અવગણે છે, અથવા ઇનબાઉન્ડ નીતિ જે ICMP પડઘો ફેંકી દે છે, તે યોગ્ય પરિણામ તરીકે બંને દિશામાં મૌન ઉત્પન્ન કરે છે. એ મૌનને પરિવહન ખામી ગણવાથી તમે એવી નેટવર્ક ખામી શોધવા જાઓ છો જે કદી હતી જ નહીં.
એકમાર્ગી કેપ્ચર ખરેખર જે સાબિત કરે છે તે એ છે કે મોકલનારનો સ્ટેક એ અવલોકન બિંદુએ કંઈક એન્ક્રિપ્ટ કરેલું છે. આવવા વિશે કંઈ નહીં, અને જવાબ આપવાના ઇરાદા વિશે પણ કંઈ નહીં. ઉપયોગી પ્રશ્ન "જવાબ કેમ નથી" નથી, પણ "આંતરિક સંવાદે શું ઉત્પન્ન કરવું જોઈતું હતું" છે.
બે SA, બે SPI, એક સંવાદ
IPsec સુરક્ષા સંગઠનો એકમાર્ગી છે, તેથી સામાન્ય સુરક્ષિત આદાનપ્રદાનમાં અલગ ઓળખકર્તા અને સ્વતંત્ર સ્થિતિ સાથેનું ઇનબાઉન્ડ અને આઉટબાઉન્ડ સંગઠન હોય છે. તેથી આઉટબાઉન્ડ પેકેટના SPI માટે પરત ટ્રાફિક શોધવો એ વર્ગીય ભૂલ છે, કારણ કે કોઈપણ જવાબ સાથીના પોતાના આઉટબાઉન્ડ SA હેઠળ તેના પોતાના SPI સાથે જાય છે. તેના બદલે ટ્રાફિક સિલેક્ટર અને સાથીના સરનામાંથી જોડી મેળવો.
કી પુનર્જનન એક સમયે થોડી સેકન્ડ માટે ચિત્ર જટિલ બનાવે છે, કારણ કે જૂની અને બદલીની સ્થિતિ ઓવરલેપ થઈ શકે છે. જો લક્ષણ કી પુનર્જનન આસપાસ શરૂ થયું હોય, તો ફક્ત કનેક્શનનું નામ નહીં, સંગઠન ઓળખકર્તા અને સમયચિહ્નો સાથે એકઠા કરો.
કંઈપણ જવાબ આપે તે પહેલાં સ્વીકારકે શું કરવું
| Stage | What to look at | Wrong conclusion if skipped |
|---|---|---|
| Sender encrypts | outbound SA packet counter | "the tunnel is up" |
| Peer receives | inbound SA counter and replay window | "the peer is down" |
| Inner delivery | target host or service logs | "routing is broken" |
| Application replies | the app's own trace | "the reply was dropped" |
| Protected return | the peer's outbound SA | "ESP only works one way" |
દરેક પંક્તિ સ્વતંત્ર રીતે નિષ્ફળ જાય છે અને દરેક નિષ્ફળતાનો માલિક અલગ હોય છે, તેથી એક કેપ્ચર તેમને અલગ પાડી શકતું નથી. ઇનબાઉન્ડ કાઉન્ટર આવવાનો એકમાત્ર સીધો પુરાવો છે, કારણ કે જે પેકેટ તેની પ્રમાણીકરણ કે રિપ્લે ચકાસણીમાં નિષ્ફળ જાય છે તે કોઈપણ પ્રતિસાદ વગર ફેંકી દેવાય છે. જેનું ઇનબાઉન્ડ કાઉન્ટર ખસ્યું નથી તેવો સાથી તેથી તમને તેની નીતિ વિશે કંઈપણ માહિતી આપતો નથી.
વિતરણ ડિક્રિપ્શનથી અલગ પગલું છે. સ્થિતિ માન્ય હોઈ શકે અને પેકેટ પછી ઇનબાઉન્ડ નીતિ કે એવા માર્ગ દ્વારા ફેંકાઈ શકે જેમાં આંતરિક ગંતવ્ય સમાવિષ્ટ ન હોય, તેથી સ્વચ્છ કાઉન્ટર એટલે પેકેટ તમે ઇચ્છતા હતા ત્યાં ગયું એમ માનવાને બદલે લક્ષ્ય હોસ્ટે સાદું લખાણ જોયું કે નહીં તે ચકાસો.
મૂળ ESP એ UDP નથી
મૂળ ESP એ IP પ્રોટોકોલ 50 છે, જે TCP પણ નથી UDP પણ નથી અને તેમાં કોઈ પોર્ટ જ નથી. તેથી UDP 500 પર IKE ને મંજૂરી આપતો ફાયરવોલ નિયમ ડેટા માર્ગ વિશે કંઈ કહેતો નથી, અને પોર્ટની આસપાસ લખાયેલો ફિલ્ટર ટનલને વાટાઘાટ કરવા દઈને પછી તેમાં વહન થતું બધું ફેંકી શકે છે. ડેટા માર્ગને અલગથી, તમે ખરેખર અવલોકન કરેલા મોડમાં ચકાસો.
NAT પાછળ આકાર બદલાય છે: સુરક્ષિત પેલોડ UDP ની અંદર મુસાફરી કરે છે, સામાન્ય રીતે 4500 પોર્ટ પર, જેમ RFC 3948 વ્યાખ્યાયિત કરે છે. કોઈપણ નિયમ લખતા પહેલાં સક્રિય મોડ નોંધો, કારણ કે માર્ગ પરનું ઉપકરણ મૂળ ESP અને UDP-એન્કેપ્સ્યુલેટેડ ESP સાથે સંપૂર્ણપણે અલગ વ્યવહાર કરી શકે છે, અને કેટલાક મિડલબોક્સ એકને મંજૂરી આપે છે અને બીજાને ફેંકી દે છે.
આ ઘટનાના પોતાના કાઉન્ટર વાંચો
strongSwan હોસ્ટ પર, swanctl --list-sas દરેક સંગઠન માટે બંને દિશામાં પેકેટ અને બાઇટ કાઉન્ટર જણાવે છે, જે "કદી આવ્યું નહીં" અને "આવ્યું પણ જવાબ ન મળ્યો" અલગ પાડવા પૂરતું છે. Linux પર, /proc/net/xfrm_stat ખૂટતી સ્થિતિ, ખૂટતી નીતિ અને પ્રોટોકોલ ભૂલો જેવી સંચિત નિષ્ફળતાઓ ગણે છે. એ સરવાળા બૂટથી એકઠા થાય છે અને એક નેટવર્ક નામસ્થાનના છે, તેથી મોટી સંખ્યા એ આરોપણ નથી.
યોગ્ય નામસ્થાનમાં ઘટનાની બારી આસપાસ બે વાંચન લો અને તફાવતોની તુલના કરો, નહીંતર તમે ગયા અઠવાડિયાની ભૂલો આજ બપોરની ટિકિટ પર ચોંટાડશો. નામસ્થાન અને બંને સમયચિહ્નો ટિકિટમાં લખો જેથી આગલો વાચક કુલ પર ભરોસો કરવાને બદલે તુલના પુનઃઉત્પાદિત કરી શકે.
શંકાસ્પદને નહીં, તબક્કાને નામ આપો
ઉપયોગી નિષ્કર્ષ કહે છે પેકેટ ક્યાં થોભ્યું: કદી મળ્યું નહીં, મળ્યું અને ફેંકાયું, પહોંચાડાયું પણ જવાબ વગર, અથવા જવાબ મળ્યો અને પાછા ફરતા માર્ગે ખોવાયું. એમાંનું દરેક અલગ માલિક અને અલગ આગળના આદેશ તરફ ઇશારો કરે છે. "VPN સર્વર તરફથી કોઈ પ્રતિસાદ નથી" ચાર અલગ ખામીઓને એક વાક્યમાં દબાવી દે છે જેને કેપ્ચરે કદી ન્યાયી ઠેરવ્યું નથી.
કેપ્ચર સાંકડા રાખો, અને કાચી કર્નલ સ્થિતિ ટિકિટની બહાર રાખો, કારણ કે તે એવી કી સામગ્રી લઈ શકે છે જેને હોસ્ટની બહાર જવાનું કોઈ કામ નથી. કાઉન્ટરના તફાવતો અને સમયચિહ્નો એ જ ભાગ છે જે આગલી વ્યક્તિને આપવા લાયક છે.