શેર કરેલ TAP VPN ને પોર્ટલ પર હજી પણ HTTPS કેમ જોઈએ
TAP VPN સહભાગીને ઓળખે છે, તેની પાછળની સેવાને નહીં. પોર્ટલ પર હોસ્ટનામ માન્યતા રાખો અને જે પડોશીઓ પર ભરોસો નથી તેમને અલગ રાખો.
બે ઉપકરણો પાસે માન્ય VPN ઓળખપત્રો છે અને તેઓ એક બ્રિજ કરેલ ઇથરનેટ સેગમેન્ટ શેર કરે છે. તેમાંથી ફક્ત એક જ ઓફિસ પોર્ટલ માટે જવાબ આપવાનું છે, અને બીજું હજી પણ તે સેગમેન્ટ પર પોર્ટલનું સરનામું દાવો કરી શકે છે. ટનલે પોતાનું કામ કર્યું: તેણે બંને સહભાગીઓને ઓળખ્યા અને સર્વર સુધીનો દરેક માર્ગ એન્ક્રિપ્ટ કર્યો. જે તેણે કર્યું નહીં તે એ છે કે તેમાંથી કોણ સેવાના નામનો માલિક છે તેની પ્રમાણિતતા આપી, અને આ જ ખાલીપો એ કારણ છે કે પોર્ટલને હજી પણ માન્ય પ્રમાણપત્રની જરૂર છે.
VPN ખરેખર શું ઓળખે છે
VPN હેન્ડશેક એક પ્રશ્નનો જવાબ આપે છે: કયા સહભાગીએ આ ટનલ કઈ કી સામગ્રી સાથે પૂર્ણ કરી. એ જવાબ દરેક સહભાગી અને દરેક જોડાણ માટે અલગ છે, અને તે સહભાગી પછી જે સેવાઓ પ્રગટ કરે છે તેના વિશે કંઈ કહેતો નથી. TAP સેગમેન્ટમાં સહભાગી એક સરનામું પણ નથી, કારણ કે તે કોઈપણ MAC અને કોઈપણ IP રજૂ કરી શકે છે જે બ્રિજ શીખવા તૈયાર હોય. ઓળખ ટનલના અંતિમ બિંદુ પર અટકે છે, એપ્લિકેશન પર નહીં.
ત્રણ પ્રશ્નોને એકમાં ભેળવવાને બદલે અલગ કરો. દરેકની પોતાની પદ્ધતિ અને પોતાની નિષ્ફળતાની રીત છે.
| Question | Answered by |
|---|---|
| Which peer sent this packet? | VPN transport authentication |
| Which device owns this IPv4 address? | ARP, trusted only as far as the segment |
| Which service am I talking to? | Application TLS and hostname validation |
એક ડિપ્લોયમેન્ટમાં સંપૂર્ણ ઓળખાયેલ ટનલ અને તેની પાછળ સંપૂર્ણ અપ્રમાણિત સેવા હોઈ શકે છે. તેમાં બીજા સ્તરનું સરનામું બીજા સહભાગી દ્વારા દાવો કરાયેલા હોસ્ટ પર માન્ય પ્રમાણપત્ર પણ હોઈ શકે છે, અને તેથી ડિઝાઇનમાં એક બીજાને બદલવાને બદલે બંને નિયંત્રણો હોવા જોઈએ. કોષ્ટક ત્રણ પંક્તિમાં આખી દલીલ છે.
શેર કરેલ સેગમેન્ટ પર ARP ડિરેક્ટરી નથી
ARP સ્થાનિક લિંક પર IPv4 સરનામાને MAC સાથે મેપ કરે છે અને તે લિંક પર કોઈપણ તરફથી જવાબ સ્વીકારે છે. છૂટછાટવાળા બ્રિજ કરેલ સેગમેન્ટમાં સહભાગી બીજા ઉપકરણનું સરનામું દાવો કરી શકે છે, અને બ્રિજ ફ્રેમ્સને છેલ્લે જવાબ આપનારને મોકલે છે. સર્વર સુધીના દરેક ક્લાયન્ટ માર્ગને એન્ક્રિપ્ટ કરવાથી તે બદલાતું નથી, કારણ કે ફ્રેમ્સ બ્રિજ સુધી પહોંચતા પહેલાં ડિક્રિપ્ટ થાય છે. ARP ની ભરોસાની સીમા સેગમેન્ટ છે, ટનલ નહીં.
હોસ્ટે ખરેખર શું શીખ્યું તે જુઓ: ip neigh show વર્તમાન મેપિંગ અને તેમની સ્થિતિ સૂચિબદ્ધ કરે છે, અને સામાન્ય કામગીરી દરમિયાન બે MAC સરનામાં વચ્ચે બદલાતી એન્ટ્રી અવગણવાને બદલે તપાસવા લાયક લક્ષણ છે. સ્વસ્થ નાના સેગમેન્ટમાં તે એન્ટ્રીઓ લાંબા સમય સુધી સ્થિર રહે છે.
સહભાગી અલગાવ અને બ્રિજ નીતિ બરાબર આ કેસ માટે જ છે. જ્યારે સેવા ફક્ત IP હોય અને ઉપકરણોને એકબીજાની ફ્રેમ્સ જોવાનું કોઈ કારણ ન હોય ત્યારે રૂટ કરેલ ડિઝાઇન સામાન્ય રીતે વધુ સારો જવાબ છે.
પ્રમાણપત્રની માન્યતા ત્યાં જ રાખો જ્યાં સેવા છે
એપ્લિકેશન TLS એ પ્રશ્નનો જવાબ આપે છે જે ટનલ આપી શકતી નથી: શું આ એ જ સેવા છે જ્યાં હું પહોંચવા માંગતો હતો. બ્રાઉઝર હોસ્ટનામને પ્રમાણપત્ર સામે તપાસે છે, અને એ તપાસ એ જ સાંકળનો એકમાત્ર ભાગ છે જે સહભાગીને બદલે પોર્ટલનું નામ લે છે.
ચેતવણી ઉપરછલ્લી છે એવું નક્કી કરતા પહેલાં સર્વર શું રજૂ કરે છે તે તપાસો. openssl s_client -connect portal.example.internal:443 -servername portal.example.internal સાંકળ અને વિષયના વૈકલ્પિક નામો છાપે છે. તમે લખેલું નામ તે સૂચિમાં ન હોય તો ચેતવણી સાચી છે અને પ્રમાણપત્ર એ છે જે સુધારવાની જરૂર છે. વપરાશકર્તાઓને તેને છોડી દેવાનું શીખવવું કાર્યરત નિયંત્રણને સજાવટમાં ફેરવે છે.
OpenVPN બ્રિજિંગ માર્ગદર્શિકા ઇથરનેટ મોડેલ અને તેની આસપાસના નીતિ વિકલ્પોનું વર્ણન કરે છે, અને સેગમેન્ટે શું માન્ય કરવું જોઈએ તે માટે તે યોગ્ય સંદર્ભ છે. બ્રિજ નિયમ હળવો કરતા પહેલાં તેને વાંચો, કારણ કે તે જે મોડેલનું વર્ણન કરે છે તે ઉપરની દરેક તપાસ ધારે છે.
નક્કી કરો કે તે સહભાગીઓએ બિલકુલ સેગમેન્ટ શેર કરવો જોઈએ કે નહીં
જ્યારે જરૂરિયાત ફક્ત IP પહોંચ હોય ત્યારે સૌથી સસ્તું સુધારણા સામાન્ય રીતે બીજા સ્તરને શેર કરવાનું બંધ કરવું છે. રૂટ કરેલ VPN દરેક ક્લાયન્ટને તેનું પોતાનું સરનામું આપે છે, શેર કરેલ બ્રોડકાસ્ટ ડોમેન દૂર કરે છે અને સહભાગીઓ વચ્ચેના ટ્રાફિકને ડિફોલ્ટને બદલે નીતિ નિર્ણયમાં ફેરવે છે. પછી પોર્ટલ પાસે સુરક્ષિત કરવા એક સરનામું હોય છે અને તેને દાવો કરી શકે તેવા પડોશી નથી.
જો સેગમેન્ટ રહેવું હોય, તો સર્વર બાજુની સેટિંગ તપાસો જે ક્લાયન્ટને એકબીજા સુધી પહોંચવા દે છે: grep -n client-to-client /etc/openvpn/server.conf. તે નિષ્ક્રિય હોય ત્યારે ક્લાયન્ટ ટ્રાફિક સર્વરમાંથી પસાર થાય છે અને ત્યાં ફિલ્ટર કરી શકાય છે. તે સક્રિય હોય ત્યારે સહભાગીઓ સીધા બ્રિજ દ્વારા ફ્રેમ્સની આપલે કરે છે અને તમારા ફિલ્ટરિંગ બિંદુઓ બ્રિજ અને હોસ્ટ ફાયરવોલ છે.
લખો કે દરેક હોસ્ટ ખરેખર કઈ સુરક્ષાઓ પર આધાર રાખે છે: ટનલ ઓળખ, સેગમેન્ટ અલગાવ, અથવા એપ્લિકેશન TLS. જે હોસ્ટ ત્રણેય પર આધાર રાખે છે તે ઠીક છે. જે હોસ્ટ પ્રથમ પર આધાર રાખે છે અને ધારે છે કે બાકીના બે તેની સાથે આવ્યા છે, તે અંતે ખોટી સામગ્રી પરોસે છે.