ડોમેન ફ્રન્ટિંગ એ VPN નથી: બે નામ, એક વિનંતી
એક HTTPS વિનંતીમાં બે નામ ટનલ નથી. ફ્રન્ટિંગ પ્રદાતાના રૂટિંગ નિયમો પર આધાર રાખે છે; VPN પસંદ કરે છે કે કયા પેકેટ જાય છે. તેમને અલગ દોરો.
બંને ટેકનિક એકસાથે ફાઇલ થાય છે કારણ કે બંનેમાં એક મધ્યસ્થી હોય છે અને બંને છુપાવવા જેવા સંભળાય છે. તેઓ અલગ વસ્તુઓ પર કામ કરે છે. ડોમેન ફ્રન્ટિંગ એ છે કે એક HTTPS વિનંતીના કયા સ્તરે કયું નામ દેખાય છે. VPN એ છે કે કયા પેકેટ કોઈ ચોક્કસ માર્ગે પીઅર સુધી જાય છે. ફ્રન્ટિંગને VPN નો પ્રકાર કહેવાથી એવી ડિઝાઇન સુધી પહોંચાય છે જે કામ કરી શકતી નથી, અને એવી સમીક્ષાઓ સુધી જે ખોટો પ્રશ્ન પૂછે છે.
બે નામ, બે સ્તર
TLS કનેક્શન તેના હેન્ડશેકમાં સર્વરનું નામ લઈ શકે છે. કનેક્શન અસ્તિત્વમાં આવ્યા પછી, HTTP વિનંતી જે સત્તા જોઈએ છે તેને ઓળખે છે, સામાન્ય રીતે Host હેડરમાં. આ બે ક્ષેત્રો છે જે બે અલગ ક્ષણોમાં બે અલગ સોફ્ટવેર ભાગો દ્વારા વાંચવામાં આવે છે.
| Layer | What carries the name | Who reads it |
|---|---|---|
| TLS handshake | Server name indication | The TLS terminator in front of the service |
| HTTP request | Authority or Host header | The routing layer that picks a backend |
| Network path | Destination address and port | Routers, and the VPN peer if one is in use |
ડોમેન ફ્રન્ટિંગ પ્રથમ બે વચ્ચેના તફાવતનો ઉપયોગ કરે છે જેથી ફ્રન્ટિંગ સેવા કનેક્શન સ્વીકારે અને પછી વિનંતીને બીજે રૂટ કરે. તે ફક્ત ત્યાં જ કામ કરે છે જ્યાં તે સેવા તેને રૂટ કરવા તૈયાર હોય, જે પ્રોટોકોલ યુક્તિ નહીં પણ પ્રદાતાની નીતિનો પ્રશ્ન છે.
ફ્રન્ટિંગ ટેકનિક પર નહીં, પ્રદાતા પર આધાર રાખે છે
મર્યાદિત ઉદાહરણ તરીકે, Front Door માટેના સામાન્ય પ્રશ્નો Azure નું માર્ગદર્શન ડોમેન ફ્રન્ટિંગ સામેના રક્ષણોનું દસ્તાવેજીકરણ કરે છે. તે એક જ સબ્સ્ક્રિપ્શન અને ગોઠવાયેલા રૂટ વચ્ચેના ડોમેન માટે માન્ય અસંગતિનું વર્ણન કરે છે, અને જ્યારે અસંગતિ સંરક્ષણ વિનંતીને અવરોધે ત્યારે 421 Misdirected Request પ્રતિસાદનું વર્ણન કરે છે.
આ એક દસ્તાવેજી નીતિ એકસાથે બંને સૂત્રોને રદ કરે છે. દરેક અલગ નામની જોડી કામ કરતી નથી, અને દરેક અસંગતિ પ્રતિબંધિત પણ નથી. અન્ય સેવાઓની પોતાની તપાસ, પોતાની જમાવટની જરૂરિયાતો અને પોતાના ભૂલ કોડ છે.
આ બીજા નેટવર્કના નિયંત્રણોને ટાળવાની સૂચના પણ નથી. પ્રદાતાના રૂટિંગ નિયમો વાંચીને તે શું માન્ય કરે છે તે સમજવું એ આર્કિટેક્ચરનું કામ છે; તે નિયમોને ટાળવાની રેસીપી તરીકે ગણવું એ અલગ પરિણામો સાથેની અલગ પ્રવૃત્તિ છે. તમે લખો છો તે દસ્તાવેજમાં આ બે પ્રવૃત્તિઓ અલગ રાખો. બીજી જ એ છે જે સમીક્ષામાં ડિઝાઇન નામંજૂર કરાવે છે.
VPN ખરેખર શું પસંદ કરે છે
નેટવર્ક VPN માં, રૂટિંગ અને પ્લેટફોર્મ નીતિ પીઅર તરફના ટનલ માટે આંતરિક ટ્રાફિક પસંદ કરે છે. ગોઠવણી પ્રમાણે તે ઘણી એપ્લિકેશનો અથવા નિર્ધારિત ઉપગણને આવરી શકે છે, અને એવા પ્રોટોકોલ લઈ જઈ શકે છે જેમાં બિલકુલ HTTP વિનંતી નથી.
ફ્રન્ટિંગ એમાંથી કંઈ કરતું નથી. ફ્રન્ટિંગ સેવા દ્વારા એક HTTPS વિનંતી ગોઠવવાથી ખાનગી નેટવર્ક રૂટ ઇન્સ્ટોલ થતો નથી, મનસ્વી UDP એપ્લિકેશનો લઈ જવાતી નથી, અને ઉપકરણના દરેક પ્રોગ્રામને સેવા વાપરવા મજબૂર કરાતું નથી. જો તમને તે આવરણ જોઈએ, તો તમને પ્રોક્સી અથવા ટનલ જોઈએ, નામની યુક્તિ નહીં.
તેથી જ સમીક્ષામાં બંને ભેગા થઈ જાય છે: બંનેને મધ્યસ્થી તરીકે વર્ણવવામાં આવે છે, અને બંને પ્રવેશ વિશેના દસ્તાવેજોમાં દેખાય છે. દરેક જે ઇન્ટરફેસ આપે છે તે સંપૂર્ણપણે અલગ છે, અને તેમાંથી ફક્ત એક જ નેટવર્ક માર્ગ છે.
દૃશ્યતા દ્વિસંખ્યાત્મક નથી
સરખામણી પણ ફક્ત છુપાયેલા વિરુદ્ધ દૃશ્યમાન નથી. DNS પ્રશ્નો, લક્ષ્ય સરનામાં, હેન્ડશેકની લાક્ષણિકતાઓ, પેકેટનું માપ અને સમય — બધું તે વ્યક્તિ માટે અવલોકનયોગ્ય રહે છે જે તેમને જોવાની સ્થિતિમાં હોય, અને તે અવલોકનકાર શું શીખે છે તે તે ક્યાં બેઠો છે તેના પર આધાર રાખે છે.
એપ્લિકેશન ડેટા પણ તેને સમાપ્ત કરતા છેડા પર દૃશ્યમાન હોય છે. તમારી વિનંતી રૂટ કરતી ફ્રન્ટિંગ સેવા તે છેડાઓમાંની એક છે, અને VPN પીઅર બીજો છે. બંનેમાંથી કોઈ ગોઠવણી સામગ્રીને તે પક્ષ માટે અસ્પષ્ટ બનાવતી નથી જેણે તમને સેવા આપવા તેને વાંચવી પડે.
ત્રણ બોક્સ દોરો
આર્કિટેક્ચર સમીક્ષા માટે, TLS છેડો, HTTP રૂટિંગ સેવા અને અંતિમ એપ્લિકેશનને ત્રણ અલગ બોક્સ તરીકે દોરો, અને પછી કોઈપણ VPN પીઅરને ફરી બીજે ક્યાંક દોરો. વેબ લક્ષ્ય પસંદ કરતું સ્થળ અને ખાનગી નેટવર્કના પેકેટ લઈ જતું સ્થળ એક જ સિસ્ટમ હોવાની જરૂર નથી, અને સામાન્ય રીતે હોતું નથી.
બોક્સ અલગ થઈ જાય પછી પ્રશ્નોના જવાબ મળે છે: આ પ્રદાતા કયા નામ સ્વીકારે છે, કયા પ્રોટોકોલને વહનની જરૂર છે, અને કયો પક્ષ શું જોઈ શકે છે. જે આકૃતિ તેમને ભેગા કરે છે તે એવી ડિઝાઇન આપે છે જે કોઈ અમલમાં મૂકી શકતું નથી, અને એવી સમીક્ષા જે શબ્દભંડોળ પર દલીલ કરે છે.