NAT દ્વારા L2TP/IPsec: ખરેખર શું તૂટે છે અને કેમ

NAT L2TP/IPsec તોડે છે એ દાવો અડધો સાચો છે અને તેથી નકામો છે. સરનામાંનું ભાષાંતર સામાન્ય છે, NAT ટ્રાવર્સલ એને ટકી રહેવા માટે જ છે, અને લાખો ક્લાયન્ટ દરરોજ રાઉટર પાછળથી જોડાય છે. જે તૂટે છે તે ચોક્કસ આદાનપ્રદાનનો ચોક્કસ તબક્કો છે: IKEને ક્યારેય જવાબ મળતો નથી, એન્કેપ્સ્યુલેટેડ ટનલને ફક્ત એક પ્રોટોકોલની પરવાનગી આપતી નીતિ દ્વારા કાઢી નાખવામાં આવે છે, અથવા ટનલ નિષ્ક્રિય હોય ત્યારે મેપિંગ સમાપ્ત થાય છે. તમે કયા તબક્કામાં છો તે જાણ્યા પછી, ઉકેલ સામાન્ય રીતે એક નિયમ અથવા keepalive હોય છે, નવી VPN ડિઝાઇન નહીં.

દંતકથા એ ખોટો પ્રશ્ન છે

ઉપયોગી પ્રશ્ન એ નથી કે “NAT આ તોડે છે કે નહીં”, પણ એ છે કે “આદાનપ્રદાનનો કયો ભાગ ભાષાંતરિત થાય છે, અને ભાષાંતર કરતું ઉપકરણ તેની સાથે શું કરે છે”. L2TP/IPsec સ્તરીય પ્રોટોકોલ છે: IKE વાટાઘાટ કરે છે, ESP રક્ષણ આપે છે, અને L2TP તે રક્ષણની અંદર PPP વહન કરે છે. સરનામાંનું ભાષાંતર દરેક સ્તર સાથે અલગ રીતે ક્રિયાપ્રતિક્રિયા કરે છે, અને ભૂલ સંવાદને બદલે વાટાઘાટના તબક્કાને જોશો તો નિષ્ફળતાની સહીઓ અલગ ઓળખી શકાય છે.

સફળતાપૂર્વક વેબ બ્રાઉઝ કરતું રાઉટર ફક્ત એ પુરવાર કરે છે કે સ્રોત પોર્ટ ભાષાંતર સાથે TCP કામ કરે છે. તે UDP 500, UDP 4500 કે પ્રોટોકોલ 50 વિશે કંઈ કહેતું નથી, અને આ જમાવટ આ ત્રણ વસ્તુઓ પર આધારિત છે.

તબક્કો 1: IKEને અનિવાર્યપણે જવાબ મળવો જોઈએ

પ્રથમ આદાનપ્રદાન UDP 500 પર જવાબદાતા પાસે જાય છે. જો કોઈ જવાબ પાછો ન આવે, તો બીજું કંઈ મહત્વનું નથી: પૂર્વ-શેર કરેલી કી, પ્રસ્તાવ અને ઓળખપત્રો વાંચ્યા વિના રહે છે. ક્લાયન્ટના ટાઇમઆઉટ પરથી અનુમાન કરવાને બદલે વિનંતી અને જવાબ પર નજર રાખો:

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

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

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

તબક્કો 2: એન્કેપ્સ્યુલેશન ફાયરવોલ જે જુએ છે તે બદલે છે

ESP એ IP પ્રોટોકોલ છે, TCP કે UDP પોર્ટ નથી, અને સામાન્ય પોર્ટ સરનામાં ભાષાંતરમાં ફરીથી લખવા માટે કોઈ પોર્ટ ક્ષેત્ર નથી. તેથી જ NAT ટ્રાવર્સલ સુરક્ષિત પેલોડને UDP 4500માં ખસેડે છે: એન્કેપ્સ્યુલેશન ભાષાંતર કરતા ઉપકરણને એવું કંઈ આપે છે જે તેને ભાષાંતર કરવાનું આવડે છે. એવું થયા પછી, ફક્ત UDP 500 માટે લખાયેલો ફાયરવોલ નિયમ વાટાઘાટને મંજૂરી આપે છે અને ટનલ કાઢી નાખે છે, જે એ મૂંઝવણભરી પરિણામ આપે છે જ્યાં લોગ સફળ તબક્કો 1 બતાવે છે અને કોઈ ટ્રાફિક નહીં.

NAT મળ્યા પછી IKE આદાનપ્રદાન પોતે પણ UDP 4500 પર જઈ શકે છે, જે ફક્ત 500ને મંજૂરી આપનારાઓને આશ્ચર્યમાં મૂકે છે. માર્ગ પર બંને દિશામાં બંને પોર્ટની મંજૂરી આપો, અને યાદ રાખો કે સ્ટેટફુલ ફાયરવોલ પ્રવાહને ત્યારે જ રાખી શકે છે જ્યારે તેને ટ્રાફિક દેખાય.

પ્રોટોકોલ 50 ભાષાંતર વગરના માર્ગો પર અને જ્યાં મધ્યસ્થ બોક્સ તેને મંજૂરી આપવા ગોઠવાયેલું છે તેવા માર્ગો પર હજી પણ મહત્વપૂર્ણ છે. જો તમે બાકાત દ્વારા નિદાન કરો છો, તો નિયમો ઢગલામાં ઉમેરવાને બદલે પરિકલ્પના બંધ કરો: 500, 4500 અને ESPની મંજૂરી આપો, ટનલ ઉપર આવે છે તેની ખાતરી કરો, પછી જે બિનજરૂરી નીકળે તે દૂર કરો. જે નિયમ કોઈ સમજાવી શકતું નથી તે એવો નિયમ છે જે આગલા વિક્ષેપનું કારણ બન્યા પછી પણ કોઈ દૂર કરશે નહીં. સંકુચનને બદલાવ-નોંધમાં જે તબક્કો સુધાર્યો તેની સાથે લખો, જેથી આગલો ઇજનેર તમારા પુરાવાઓથી શરૂ કરે, એ જ અંગૂઠાના નિયમથી નહીં.

તબક્કો 3: મેપિંગ સમાપ્ત થાય છે અને ટનલ મરે છે

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

ડેડ પિયર ડિટેક્શન અને NAT keepalive આ માટે જ છે, અને બંને છેડે તે મોકલવા તૈયાર હોવા જોઈએ. જો તમારું સર્વર ભાષાંતર પાછળ હોય, તો Windows બાજુની આવશ્યકતા એક દસ્તાવેજીકૃત રજિસ્ટ્રી સેટિંગ છે જે સર્વરને તેના પોતાના આઉટબાઉન્ડ પેકેટ માટે UDP એન્કેપ્સ્યુલેશન ધારી લેવા દે છે; તેના વિના જવાબદાતા ESP મોકલે છે જે ભાષાંતર કરતું ઉપકરણ પાછું મેપ કરી શકતું નથી. આ સર્વર રૂપરેખાંકનનો મુદ્દો છે, ક્લાયન્ટનો નહીં.

WAN સરનામું બદલાવવાથી બીજી દિશામાંથી એ જ પરિણામ આવે છે: મેપિંગ નવા સરનામા ફરતે ફરીથી બને છે, અને જૂનું સુરક્ષા સંગઠન હવે એવી ટ્યુપલ તરફ નિર્દેશ કરે છે જે હવે અસ્તિત્વમાં નથી. પુનઃકનેક્શનનું વર્તન ક્લાયન્ટ અમલીકરણનું છે, અને તેથી જ “રાઉટર ફરી ચાલુ થયા પછી ફરી જોડાઓ” એક ક્લાયન્ટ પર કામ કરે છે અને બીજા પર જાતે ટોગલ જરૂરી છે.

કેરિયર-ગ્રેડ NAT પાછળ હોસ્ટિંગ એ અલગ સમસ્યા છે

જો તમે ઘરે L2TP/IPsec સર્વર હોસ્ટ કરીને બહારથી તેને પહોંચવા માંગો છો, તો જરૂરિયાત અવિનંતી આવક પહોંચ છે, અને NAT ટ્રાવર્સલ એ આપતું નથી. તમારા રાઉટર સામે કેરિયર-ગ્રેડ NAT હોવાનો અર્થ એ છે કે તમે ફોરવર્ડ કરી શકો એવો કોઈ પોર્ટ નથી જે તમને પહોંચપાત્ર બનાવે, કારણ કે જાહેર સરનામું વહેંચાયેલું છે અને મેપિંગ ફક્ત આઉટબાઉન્ડ છે.

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

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