બે WAN વાળી VPN નીતિએ કયા પેકેટ સાથે મેળ ખાવો જોઈએ?

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

બે સંવાદોને નામ આપો

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

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

તમારી નીતિ ખરેખર ક્યાં પેકેટ જોઈ શકે છે તે શોધો

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

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

તમે જે પરિવહન પર સંમતિ આપી તેની ખાતરી કરો

UDP માં એન્કેપ્સ્યુલેટેડ IPsec માટે, RFC 3948 ESP ને UDP ની અંદર મૂકે છે અને શેર કરેલા પોર્ટ પર IKE ને અલગ ઓળખી શકાય તે માટે બિન-ESP માર્કર વાપરે છે. સાદું ESP એ IP પ્રોટોકોલ છે, TCP કે UDP પોર્ટ નથી, તેથી પોર્ટ નંબર પર લખાયેલો ફાયરવોલ નિયમ તેની સાથે બિલકુલ મેળ ખાશે નહીં. આ ભેદ નક્કી કરે છે કે તમારી WAN નીતિને UDP નિયમ, પ્રોટોકોલ નિયમ કે બંને જોઈએ છે.

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

પ્રતિબદ્ધ થવા પહેલાં પરત માર્ગ તપાસો

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

નેટવર્ક સરનામા ભાષાંતરની સ્થિતિ WAN ફેરફારનો સામાન્ય ભોગ છે. પસંદ કરેલો અપલિંક, અપેક્ષિત બહારનું સ્રોત સરનામું, વપરાતું ભાષાંતર અને પીઅરની પાછળ સુધીની પહોંચ નોંધો, પછી પરિવહનને તે વહન કરે છે તે ટનલમાં મોકલ્યા વિના પહોંચયોગ્ય રાખો.

બે કેપ્ચર સાથે બંને સ્તરો ચકાસો

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

sudo tcpdump -ni wan1 'udp port 4500' -c 20
sudo tcpdump -ni tun0 'tcp port 443 and host 203.0.113.10' -c 20
ip route get 203.0.113.10 from 10.8.0.6

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