ફાળવેલા વર્ચ્યુઅલ IP પર IKEv2 ક્લાયન્ટ સુધી પહોંચવું

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

ટનલ સ્રોત સરનામું ઠીક કરતી નથી

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

ક્લાયન્ટ તરફ રૂટિંગ જરૂરી છે અને પૂરતું નથી. નીતિએ તમે ખરેખર વાપરેલા સ્રોતને સ્વીકારવો પડે.

સ્થાપિત નીતિ વાંચો, કન્ફિગ ફાઇલ નહીં

સક્રિય સંગઠન અને તેના સિલેક્ટરથી શરૂ કરો, કારણ કે ગતિશીલ ફાળવણી કર્નલમાં શું સ્થાપિત છે તે બદલે છે.

ipsec statusall
ip xfrm policy

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

ક્લાયન્ટે પેકેટ જ્યાં આવે ત્યાં સાંભળવું જોઈએ

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

ss -ltnp 'sport = :9090'
iptables -S INPUT

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

નવી દિશા અલગથી ચકાસો

ક્લાયન્ટથી સર્વર સુધીની કાર્યકારી વિનંતી ક્યારેય આ માર્ગનો ઉપયોગ કરતી નથી. ગેટવેથી વિનંતી બનાવો અને બંને છેડા નિરીક્ષણ કરો.

ip route get 10.90.0.42 from 192.168.50.1
tcpdump -ni any host 10.90.0.42 and tcp port 9090

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

કી બદલાવ અથવા ફરી જોડાણ પછી પરીક્ષણનું પુનરાવર્તન કરો, કારણ કે VIP બદલાઈ શકે. જે માર્ગ ફક્ત આગલા સત્ર સુધી કામ કરે તે કાર્યકારી માર્ગ નથી.