પ્રોટોકોલ 47 વિરુદ્ધ TCP પોર્ટ 47: બે હેડર, બે નિયમ
પ્રોટોકોલ નંબર અને પોર્ટ અલગ અલગ હેડરમાં રહે છે, તેથી એક નિયમ બીજાની જગ્યા લઈ શકતો નથી. PPTP બંનેને અલગ પાડે છે, અને પોર્ટનું ખાનું GRE વ્યક્ત કરી શકતું નથી.
હોટેલના નેટવર્ક અને કોન્ફરન્સના ફાયરવોલ ઘણી વાર કસ્ટમ પરવાનગી-ખાનું બતાવે છે, અને કોઈ તેમાં 47 લખે છે એ આશામાં કે PPTP કામ કરશે. નિયમ બની જાય છે, ટનલ તો પણ નિષ્ફળ જાય છે, અને આગલો પ્રયાસ બીજો નંબર વાપરે છે. ભૂલ પેકેટમાં જ છે: IPv4માં પ્રોટોકોલ ક્ષેત્ર છે જે IP હેડર પછી શું આવે તેનું નામ આપે છે, જ્યારે TCP અને UDPમાં પોર્ટ ક્ષેત્રો છે જે ફક્ત ત્યારે જ હોય છે જ્યારે તમે એ હેડરોમાંથી એકની અંદર હો. આ એક જ પરવાનગીની બે જોડણી નથી.
IPv4 હેડર આગલા પ્રોટોકોલનું નામ આપે છે
પ્રોટોકોલ ક્ષેત્ર IPv4 હેડરમાં એક બાઇટ છે, અને તે પેલોડનું વર્ણન કરતો નંબર રાખે છે: TCP માટે 6, UDP માટે 17, GRE માટે 47, ESP માટે 50. પેકેટ ફિલ્ટર કરતું દરેક વસ્તુ ઊંડું જોતાં પહેલાં એ મૂલ્ય વાંચે છે, કારણ કે ઊંડું હેડર ફક્ત પ્રકાર જાણ્યા પછી જ અર્થપૂર્ણ બને છે. વાતચીતમાં પછી એક પોર્ટ બદલો, અને આ ક્ષેત્ર હલ્યું નથી.
તેથી પ્રોટોકોલ 47 સામે લખાયેલો નિયમ IP સ્તરનું વર્ણન કરે છે. નિર્ણયમાં કોઈ પોર્ટ ભાગ લેતું નથી.
પોર્ટ TCP અને UDPની અંદર જ હોય છે, બીજે ક્યાંય નહીં
પોર્ટ TCP અને UDP હેડરોની અંદરના સોળ-બિટ ઓળખકર્તા છે, અને તેમનું કામ એક સરનામું વહેંચતી વાતચીતોને અલગ પાડવાનું છે. GRE હેડર પ્રોટોકોલ પ્રકારનું મૂલ્ય, ઘણી વાર EtherType, સાથે મલ્ટિપ્લેક્સિંગ માટે વૈકલ્પિક કી રાખે છે. તેથી પોર્ટ 47 શબ્દસમૂહ એવું કંઈ નામ આપતું નથી જે સાથે GRE પેકેટ મેળ ખાઈ શકે.
ફાયરવોલ ઇન્ટરફેસ આમાંથી કેટલું બતાવે તેમાં અલગ પડે છે. કેટલાક પ્રોટોકોલ નંબર સ્વીકારે છે, કેટલાક નામવાળી યાદી આપે છે, અને થોડા ફક્ત પોર્ટ સાથે TCP અથવા UDP સ્વીકારે છે.
PPTP એક સાથે બંને સ્તર વાપરે છે
PPTP સૌથી સ્પષ્ટ ઉદાહરણ છે કારણ કે તે જાણી જોઈને પોતાનું કામ બે સ્તરોમાં વહેંચે છે. નિયંત્રણ જોડાણ પોર્ટ 1723 પર TCP સત્ર છે, અને ડેટા માર્ગ GRE, પ્રોટોકોલ 47 છે, ક્યાંય પણ કોઈ પોર્ટ સંડોવાયેલું નથી. જે ફાયરવોલ 1723 ને મંજૂરી આપે છે અને બીજું કંઈ નહીં, તે વાટાઘાટ શરૂ થવા દે છે અને પછી પેલોડ ફેંકી દે છે. ટનલ જોડાવામાં નિષ્ફળ જવાને બદલે પ્રમાણીકરણ પછી અટકી ગયેલી લાગે છે, અને તેથી લક્ષણ ઘણી વાર પાસવર્ડની સમસ્યા તરીકે નોંધાય છે.
| Path | Outer protocol | Port |
|---|---|---|
| Control channel | TCP, protocol 6 | 1723 |
| Data channel | GRE, protocol 47 | None |
નિયમ લખતી વખતે બે હરોળ અલગ વાંચો, અને દરેકને વેચાણકર્તાના સિન્ટેક્સ સામે ચકાસો. એક હરોળને પોર્ટ જોઈએ છે, બીજીને પ્રોટોકોલ નંબર જોઈએ છે, અને કોઈ એક જ એન્ટ્રી બંનેને આવરી લેતી નથી.
પોર્ટ-ફોર્વર્ડ પૃષ્ઠ GRE વ્યક્ત કેમ કરી શકતું નથી
ફક્ત TCP અને UDP સ્વીકારતું ફોર્વર્ડિંગ ફોર્મ GREનું વર્ણન કરી શકતું નથી, ફોર્મનું નામ ગમે તે હોય. સરનામાં અનુવાદ બીજી મુશ્કેલી ઉમેરે છે, કારણ કે GREમાં પોર્ટ નથી અને અનુવાદકને તેના બદલે કૉલ ઓળખકર્તા અનુસરવો પડે છે. કેટલાક ગ્રાહક રાઉટર સાથે આ સંભાળતું સહાયક આવે છે; ઘણા સાથે આવતું નથી, અને કોઈ વધારાની TCP પરવાનગી-એન્ટ્રી એ વર્તન ઊભું કરશે નહીં.
જ્યાં આધુનિક ટનલ જ ખરી જરૂરિયાત છે, ત્યાં અનુવાદક સાચું અનુમાન કરશે એવી આશા રાખવાને બદલે જાણી જોઈને TCP અથવા UDP વાપરતી રચના પસંદ કરો.
એન્કેપ્સ્યુલેશન નક્કી કરે છે કે ફિલ્ટર શું જુએ છે
એન્કેપ્સ્યુલેશન બહારના પેકેટને બદલે છે, અને બહારનું પેકેટ એ જ છે જે સાથે નિયમ મેળ ખાય છે. મૂળ ESP પ્રોટોકોલ 50 છે, જ્યારે NAT પસાર થવું ESPને UDP 4500ની અંદર લપેટે છે જેથી તે સરનામાં અનુવાદમાંથી બચી જાય. UDP 4500 ને મંજૂરી આપતું ફિલ્ટર ક્યારેય પ્રોટોકોલ 50 જોતું નથી, અને પ્રોટોકોલ 50 માટે લખાયેલું ફિલ્ટર ક્યારેય લપેટાયેલા સ્વરૂપ સાથે મેળ ખાતું નથી.
ક્લાઇન્ટ અને ગેટવે કયા એન્કેપ્સ્યુલેશન પર સહમત થયા તે પૂછો, પછી નિયમ ફક્ત એ બહારના આકાર માટે લખો, તેનાથી વધુ કંઈ નહીં.
નિયમ એવી રીતે લખો કે કોઈ તેને ચકાસી શકે
દરેક નિયમને સરનામા કુટુંબ, બહારનો પ્રોટોકોલ, હોય તો પરિવહન પોર્ટ, દિશા અને બંને અંતિમ બિંદુ તરીકે વ્યક્ત કરો. સમીક્ષક એ વાક્યને પેકેટ કેપ્ચર સાથે સરખાવીને ચુકાદે પહોંચી શકે છે. 47 ખોલવાની સૂચના કોઈ ચકાસી શકતું નથી, અને એટલે જ તે વર્ષો સુધી રનબુકમાં ટકી રહે છે.
એ સાબિત કરતી કસોટી ઉમેરો: બહારના ઇન્ટરફેસ પર કેપ્ચર કરતી વખતે જોડાઓ, અને ટ્રેસમાં ખરેખર દેખાતા બહારના પ્રોટોકોલ અને પોર્ટની પુષ્ટિ કરો.