સળંગ બે VPN હોપ: તમારો ટ્રાફિક ખરેખર કોણ જુએ છે?
સીરિયલ હોપ પ્રથમ ગેટવે પર ડિક્રિપ્ટ અને ફરી એન્ક્રિપ્ટ કરે છે; નેસ્ટેડ હોપ ફક્ત બહારનું સ્તર દૂર કરે છે. બંને ડિઝાઇન જુઓ અને જાણો કયો ઓપરેટર શું વાંચે છે.
દરેક ક્લાઇન્ટ પ્રોફાઇલ એક સર્વરનું નામ આપે છે, તેથી વપરાશકર્તાની જગ્યાએથી એક ટનલ અને એક જગ્યા છે જ્યાં સુરક્ષા પૂરી થાય છે. તે પ્રથમ ગેટવે પછી શું થાય છે તે એવો ડિઝાઇન નિર્ણય છે જે ક્લાઇન્ટ ક્યારેય જોતો નથી, અને બંને સામાન્ય ડિઝાઇન તપાસ હેઠળ ખૂબ જ અલગ રીતે વર્તે છે. સીરિયલ ચેઇનમાં પ્રથમ ગેટવે ડિક્રિપ્ટ કરે છે અને ફરી એન્ક્રિપ્ટ કરે છે. નેસ્ટેડ ચેઇનમાં તે બહારનું સ્તર દૂર કરે છે અને અંદરની ટનલ મોકલે છે જે તે ખોલી શકતું નથી. હોપની સંખ્યા બંનેમાં સમાન છે, તેથી તફાવત ગણવાનો નહીં, દોરવાનો છે.
ક્લાઇન્ટથી શરૂ કરો અને બંને છેડાને નામ આપો
વપરાશકર્તા જ્યાંથી શરૂ કરે છે ત્યાંથી શરૂ કરો, કનેક્શન પ્રોફાઇલમાં. તેમાં એક દૂરનું સરનામું, એક પ્રમાણીકરણ પદ્ધતિ અને, જ્યારે ડિઝાઇન ટેકો આપે ત્યારે રૂટની યાદી હોય છે. ક્લાઇન્ટથી ગેટવે A સુધીની તે બહારની ટનલને લેબલ કરો અને તેને ઉદાહરણ સરનામાં આપો: ક્લાઇન્ટનું ટનલ સરનામું 10.77.0.2, Aનું 10.77.0.1, અને Aનું જાહેર અંતિમ બિંદુ 198.51.100.10, TEST-NET-2 દસ્તાવેજી શ્રેણીમાંથી લીધેલું જેથી ઉદાહરણમાં કંઈ પણ વાસ્તવિક હોસ્ટ સાથે ટકરાય નહીં.
તે પ્રોફાઇલમાં ગેટવે Bનો કોઈ ઉલ્લેખ નથી, અને તે ખામી નથી. બીજો હોપ Aનો છે, અને ક્લાઇન્ટની એકમાત્ર જવાબદારી ટ્રાફિક A સુધી પહોંચાડવાની અને જે પાછું આવે તે સ્વીકારવાની છે. A ટનલ સમાપ્ત કરે છે, મોકલે છે કે નવી ખોલે છે — આ પ્રશ્નનો જવાબ આ આખા ફેરાનો બાકીનો ભાગ આપે છે, અને તે જ નક્કી કરે છે કે A શું વાંચી શકે છે.
સીરિયલ: A ડિક્રિપ્ટ કરે છે, પછી ફરી એન્ક્રિપ્ટ
સીરિયલ ડિઝાઇનમાં A ટ્રાફિક બે વાર સમાપ્ત કરે છે. તે ક્લાઇન્ટ પાસેથી સુરક્ષા દૂર કરે છે, એપ્લિકેશનનું IP પેકેટ મેળવે છે, અને પછી તે પેકેટને A દ્વારા B તરફ બનાવેલી બીજી ટનલ દ્વારા મોકલે છે. આ બે ક્રિયાઓ વચ્ચે પેકેટ Aના ફોરવર્ડિંગ માર્ગમાં ખાનગી ગંતવ્યને સંબોધિત સામાન્ય IP પેકેટ તરીકે બેસે છે.
એનાથી બે પરિણામ આવે છે જે સ્પષ્ટ કહેવા યોગ્ય છે. A અંદરના પેકેટ પર નીતિ લાગુ કરી શકે છે, રૂટ, ફિલ્ટર નિયમો અને સ્રોત તથા ગંતવ્યના લોગિંગના રૂપમાં, અને Aએ બે સેટ ઓળખપત્રો રાખવા પડે છે: એક ક્લાઇન્ટ માટે સર્વર તરીકે અને એક Bના ક્લાઇન્ટ તરીકે. દરેક ક્ષણે સુરક્ષા હાજર છે, તોપણ સુરક્ષિત વસ્તુ A પર ઓળખ બદલે છે.
એનો અર્થ એ નથી કે A એપ્લિકેશનનું સાદું લખાણ વાંચે છે. જ્યારે ક્લાઇન્ટ અને સેવા TLS ચલાવે છે અને એકબીજાના પ્રમાણપત્રો ચકાસે છે, A વાંચી શકાય તેવી વિનંતીને બદલે TLS રેકોર્ડ પ્રવાહ જુએ છે. તે સુરક્ષા ક્યાં પૂરી થાય છે તેની પુષ્ટિ કરવા ટનલનું રેખાચિત્ર નહીં, સેવાની પ્રમાણપત્ર શૃંખલા જોવી પડે છે.
નેસ્ટેડ: A ફક્ત બહારનું સ્તર દૂર કરે છે
નેસ્ટેડ ડિઝાઇનમાં ક્લાઇન્ટ પહેલા B તરફ અંદરની ટનલ બનાવે છે અને પછી તે ટનલને બહારની અંદર લઈને A સુધી જાય છે. A બહારનું હેડર ઉતારે છે, અંદરની ટનલ શોધે છે અને તેની ચાવીઓ રાખ્યા વિના તેને મોકલે છે, તેથી અંદરની સુરક્ષા હજી પણ B પર પૂરી થાય છે.
પછી ક્લાઇન્ટની ઉપરની લિંક બે સ્તર વહન કરે છે, જ્યારે A અને B વચ્ચેનો માર્ગ એક. A અંદરની ટનલના બહારના સરનામાં જુએ છે, જે ટ્રાફિક છે અને લગભગ ક્યાં જાય છે તે જાણવા માટે પૂરતું છે, અને પેલોડ વાંચવા માટે પૂરતું નથી. સીરિયલ કિસ્સાથી આખો તફાવત આ જ છે, અને કોઈ હોપ કાઉન્ટર તેને બતાવતું નથી. A હજી જે કરી શકે છે તે છે જે વાંચી શકતું નથી તે મોકલવાનો ઇનકાર કરવો, અને તે તે ગેટવેના ઓપરેટર માટે હંમેશા ઉપલબ્ધ છે.
નેસ્ટિંગ તે ગુણધર્મની કિંમત લે છે. દરેક સ્તર હેડર ઓવરહેડ ઉમેરે છે, તેથી MTU અને MSS આયોજન સુઘડને બદલે ફરજિયાત બને છે, અને એક સ્તર સાથે ચાલતો માર્ગ બે સાથે મોટા પેકેટ ચૂપચાપ ગુમાવી શકે છે. દરેક સ્તરને પોતાનું ફરી-જોડાણ અને કીપએલાઇવ વર્તન પણ જોઈએ, અને એક સ્તરમાં નિષ્ફળતા બીજા દ્વારા આંશિક વિક્ષેપ જેવી દેખાય છે.
ફક્ત ટનલ નહીં, નિરીક્ષકો દોરો
ટનલ ચિત્રનો સહેલો ભાગ છે. નિરીક્ષકો એ ડિઝાઇનનો વિષય છે, તેથી દરેક દૃષ્ટિકોણ માટે એક પંક્તિ લખો અને દરેક ખરેખર શું વાંચી શકે તે ભરો.
| Vantage point | Serial chain | Nested chain |
|---|---|---|
| Client's access network | Outer tunnel only | Outer tunnel only |
| Operator of A | Inner IP packet between A and B | Outer addresses of the inner tunnel, not its payload |
| Path between A and B | Second tunnel | Second tunnel |
| Operator of B | Inner packet re-originated by A | Payload after the inner layer is removed |
| Service edge | Traffic from the exit address | Traffic from the exit address |
બે પંક્તિઓ સતત ભેળસેળ થાય છે: Aનો ઓપરેટર અને ક્લાઇન્ટની ટનલનો પ્રદાતા. તેઓ એક જ સંસ્થા હોઈ શકે છે, અને અલગ ગેટવે નામ તેમને સ્વતંત્ર બનાવતા નથી. સ્વતંત્ર માલિકીને અલગ વહીવટી નિયંત્રણ, અલગ ઓળખપત્રો અને અલગ લોગિંગ જોઈએ.
મેટાડેટા બંને ડિઝાઇનમાં ટકી રહે છે. સમય, પેકેટના કદ અને કનેક્શનની સંખ્યા દરેક હોપ પર અવલોકનક્ષમ રહે છે, તેથી બે હોપ સંકેત દૂર કરવાને બદલે સહસંબંધની કિંમત વધારે છે. અદૃશ્યતાનું વચન આપતી ડિઝાઇન કોઈ તેના પર આધાર રાખે તે પહેલાં તે યાદી સામે ચકાસવી જોઈએ.
પસંદ કરતા પહેલાં નિષ્ફળતાના માર્ગો ચાલો
વપરાશકર્તાને જે ક્રમમાં મળે તે ક્રમમાં ક્લાઇન્ટથી જાણી જોઈને વસ્તુઓ તોડો. ઇન્ટરફેસ અને તેના MTUથી શરૂ કરો, કારણ કે નેસ્ટિંગ પ્રમાણીકરણમાં નિષ્ફળ થવા કરતાં પેકેટના કદમાં ઘણું પહેલાં નિષ્ફળ થાય છે.
ip -4 addr show dev tun0
ip link show dev tun0 | grep mtu
ping -M do -s 1380 -c 2 10.77.1.1પછી સુરક્ષાના અંતિમ બિંદુઓને ધારવાને બદલે પુષ્ટિ કરો. જે ટનલ ચાલુ હોય તેની અંદરથી સેવા પાસેથી તેનું પ્રમાણપત્ર માંગો, અને ક્લાઇન્ટ જે શૃંખલા જુએ છે તેની સરખામણી સેવા ખરેખર જે શૃંખલા રજૂ કરે છે તેની સાથે કરો. ફરી સહી કરતું કે અટકાવતું ગેટવે તે પ્રમાણપત્ર બદલે છે, અને તપાસ એક જ આદેશમાં દૃશ્યમાન બને છે.
openssl s_client -connect intranet.example.com:443 -brief < /dev/nullફરી-જોડાણ મેટ્રિક્સ સાથે પૂરું કરો: ક્લાઇન્ટની ટનલ પડે છે, Bની ટનલ પડે છે, A અને B વચ્ચેનો માર્ગ બદલાય છે. શું પાછું આવે છે અને શું નહીં, અને અંદરનું જોડાણ ક્યારેય તેના ઇચ્છિત વાહકની બહારના માર્ગ પર પડે છે કે નહીં તે નોંધો. દરેક પરીક્ષણે વાપરેલા સરનામાં નોંધો, કારણ કે બીજા એક્સેસ નેટવર્ક પર તેનું પુનરાવર્તન બીજા પ્રશ્નનો જવાબ આપે છે. દરેક ફરી-જોડાણ પછી MTU પ્રોબ પણ ફરીથી ચલાવો, કારણ કે બદલાયેલો માર્ગ એક પણ ગોઠવણી લીટી ખસ્યા વિના ઉપયોગી કદ ઘટાડી શકે છે.
જ્યારે Aએ અંદરના પેકેટ પર નીતિ લાગુ કરવી હોય, અથવા જ્યારે ક્લાઇન્ટ બે થરાયેલી ટનલ ચલાવી શકતો ન હોય ત્યારે સીરિયલ પસંદ કરો. જ્યારે અંદરનો પેલોડ A પર અવાંચ્યો રહેવો જોઈએ ત્યારે નેસ્ટિંગ પસંદ કરો. પસંદગી તેના નિરીક્ષકો અને MTU આંકડાઓ સાથે લખો, અને આગલી વ્યક્તિએ એક પ્રશ્નનો જવાબ આપવા આખું ચિત્ર ફરી દોરવું નહીં પડે.