Android પર IKEv2 બિન-માનક UDP પોર્ટ પર કેમ નિષ્ફળ જાય છે

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

ફોન ખરેખર શું મોકલ્યું

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

Android પરનું મૂળ IKEv2 પ્રોફાઇલ, Windows ના બિલ્ટ-ઇન VPN ક્લાયન્ટની જેમ, માનક IKE પોર્ટ પર નિશ્ચિત છે. બંનેથી કોઈ પોર્ટ ફીલ્ડ દર્શાવતું નથી, અને પ્રોફાઇલ સંપાદન કરીને એક પણ ઉમેરી શકાતું નથી. જો ઓપરેટરનું લિસનર ખરેખર 4443 પર હોય, તો બિલ્ટ-ઇન ક્લાયન્ટ ખોટું સાધન છે, ખોટી રીતે ગોઠવાયેલું નહીં.

એવો ક્લાયન્ટ વાપરો જે પોર્ટ દર્શાવે

strongSwan નો Android ક્લાયન્ટ તેની અદ્યતન પ્રોફાઇલ સેટિંગ્સમાં ગોઠવી શકાય તેવા સર્વર પોર્ટનું દસ્તાવેજીકરણ કરે છે, તેથી તે આ ડિઝાઇન માટેની લગભગ દરેક કાર્યકારી રેસીપીમાં દેખાય છે. એ સમર્થન તે ક્લાયન્ટનું છે: બીજી IKEv2 એપ્લિકેશન, અથવા એ જ એપ્લિકેશનની વેન્ડર ફોર્ક, એ જ ફીલ્ડ દર્શાવે ન પણ શકે, જોકે નીચેનું strongSwan ડિમન તેને સમર્થન આપે છે.

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

સર્વરને બે પોર્ટ છે, અને બંને મેળ ખાવા જોઈએ

IKE UDP 500 પર શરૂ થાય છે, અને NAT ટ્રાવર્સલ સામાન્ય રીતે IKE અને એન્કેપ્સ્યુલેટેડ ESP ને UDP 4500 પર ખસેડે છે. આ strongSwan માં અલગ સેટિંગ્સ છે, તેથી એક કસ્ટમ પોર્ટ પર ખસેડાયેલા સર્વરે બંનેને એક જ મૂલ્યમાં બદલવા પડશે:

plugins {
  socket-default {
    port = 4443
    port_nat_t = 4443
  }
}

બંને ભૂમિકાઓ માટે એક જ પોર્ટ હોય તો ડિમનને એ જ સોકેટ પર IKE ને ESP-in-UDP થી અલગ પાડવું પડે, જે તે IKE સંદેશ પહેલાં આવતા ચાર-બાઇટના બિન-ESP માર્કર દ્વારા કરે છે. તેથી ક્લાયન્ટ કસ્ટમ પોર્ટ પર વાટાઘાટ કરીને પછી ચૂપચાપ 4500 પર ચાલુ રાખી શકતો નથી, અને તેથી “ફક્ત પોર્ટ બદલો” વાક્ય ફ્રેમિંગની શરત છુપાવે છે.

ફોર્વર્ડ કરવું એ લિસનર નથી

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

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

પરીક્ષણ કરતી વખતે ત્રણ તબક્કા અલગ કરો

ક્લાયન્ટ એક વાર પ્રયાસ કરે ત્યારે સર્વર પર કેપ્ચર કરો. જે વિનંતી ક્યારેય આવતી નથી તે અંતિમ બિંદુ કે ફાયરવોલનો પ્રશ્ન છે; જે વિનંતી જવાબ વિના આવે છે તે લિસનર કે નીતિનો પ્રશ્ન છે; જે જવાબ પછી મૌન આવે છે તે ફ્રેમિંગ કે ઓળખનો પ્રશ્ન છે.

tcpdump -ni eth0 -vv udp port 4443

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