L2TP/IPsec ને IPsec ઉપરાંત UDP 1701 કેમ જોઈએ

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

બે પ્રોટોકોલ, બે પોર્ટ સેટ

L2TP/IPsec જોડાણ UDP 500 પર IKE, જ્યાં અનુવાદ હોય ત્યાં UDP 4500 પર NAT ટ્રાવર્સલ, અને જ્યાં ન હોય ત્યાં IP પ્રોટોકોલ 50 તરીકે ESP વાપરે છે. L2TP પોતે UDP 1701 પર સુરંગ પ્રોટોકોલ છે, અને IPsec સામેના પક્ષને પ્રમાણિત કર્યા પછી તે ચાલે છે. બંને અર્ધ ભાગ અલગ રીતે નિષ્ફળ જાય છે, અને તેમની જાણ કરતી લોગ લાઇન વિવિધ ઘટકોમાંથી આવે છે. ફક્ત પ્રથમ અર્ધને આવરી લેતો નિયમ સમૂહ એવું જોડાણ બનાવે છે જે વાટાઘાટ કરે અને પછી સુરંગ તબક્કે મરી જાય.

પોર્ટ નંબર પરિવહન અંતિમ બિંદુઓનું વર્ણન કરે છે, અને ESP બિલકુલ પોર્ટ નથી. તેથી જ ફક્ત TCP અને UDP નિયમો આપતું ફાયરવોલ ઇન્ટરફેસ સંપૂર્ણ IPsec નીતિ વ્યક્ત કરી શકતું નથી. પ્રોટોકોલ 50 ને પ્રોટોકોલ તરીકે મંજૂરી આપવી પડે છે, અને ફક્ત UDP નો ઉલ્લેખ કરતો નિયમ તેની સાથે ક્યારેય મેળ ખાશે નહીં.

આવરણ પોર્ટની સમજૂતી આપે છે

વાયર પર, L2TP/IPsec જોડાણ સામાન્ય રીતે 500 પર IKE અને 4500 પર આવરિત ESP બતાવે છે. UDP 1701 હેડર સુરક્ષિત પેલોડની અંદર બેસે છે, તેથી બહારના ઇન્ટરફેસ પરનું કેપ્ચર તેને બતાવતું નથી. સ્થાનિક યજમાને હજી પણ તે ડેટાગ્રામ L2TP ડિમનને પહોંચાડવું પડે છે, અને પહોંચાડવાનું કામ ડિકેપ્સ્યુલેશન પછી થાય છે. તેથી 1701 નિયમ એન્ડપોઇન્ટની પોતાની ફાયરવોલ પર જ આવે છે, જ્યારે કોઈ મધ્યસ્થ બોક્સ તે પોર્ટ ક્યારેય જોતું નથી ત્યારે પણ.

પ્રક્રિયાનો ક્રમ મોટાભાગની ગૂંચવણ સમજાવે છે. જો સ્ટેક યજમાન ફિલ્ટર પહેલાં IPsec નીતિ લાગુ કરે, તો ડિકેપ્સ્યુલેટેડ L2TP પેકેટ UDP 1701 તરીકે મેળ ખાય છે; જો ક્રમ ઊલટો હોય, તો નિયમ સમૂહ બહારના પોર્ટ જુએ છે. બંને વર્તન વ્યવહારમાં હાજર છે, તેથી જ એક જ નિયમ સમૂહ એક પ્લેટફોર્મ પર કામ કરતો અને બીજા પર નિષ્ફળ જતો લાગે છે.

ક્રમમાં માર્ગ તપાસો

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

sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'
sudo nft list ruleset | grep -i -A2 1701
sudo ss -lunp | grep 1701

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

પોર્ટ સ્કેન શું બતાવી શકતું નથી

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

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