Squid દ્વારા એક VPN એન્ડપોઇન્ટ: એક સાંકડો CONNECT અપવાદ

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

Squid CONNECT વિનંતીનો નિર્ણય કેવી રીતે કરે છે

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

રૂઢિગત ગાર્ડ Safe_ports ની બહારનું બધું નકારે છે અને SSL_ports ની બહાર CONNECT નકારે છે. આ નામો તમારી પોતાની રૂપરેખામાં વ્યાખ્યાયિત ACL છે, તેથી તેમની સામગ્રી પ્રોટોકોલની નહીં, તમારી છે. વિતરણ Safe_ports તરીકે વિશાળ પોર્ટ શ્રેણીની મંજૂરી આપી શકે છે જ્યારે CONNECT અલગથી મર્યાદિત કરે છે. પોર્ટ ડિઝાઇનથી અવરોધિત છે એમ માનતા પહેલાં જીવંત મૂલ્યો વાંચો.

ખાતરી કરો કે પ્રોક્સી જ તે ઘટક છે જે વિનંતી નકારે છે. Squid દ્વારા ઉત્પન્ન થયેલ 403 VPN સર્વરની TLS ચેતવણી જેવું બિલકુલ દેખાતું નથી, અને બંનેને એક સમસ્યામાં ભેગા કરવાથી પહેલો કલાક જાય છે. વિનંતી માટે એક્સેસ લોગની લાઇન તપાસો, કારણ કે તે ક્રિયા અને તેને ઉત્પન્ન કરનાર નિયમ બંને નોંધે છે.

ત્રણ છૂટા ACL ને બદલે એક સંયુક્ત મેળ બનાવો

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

નીચેનું સ્વરૂપ દસ્તાવેજીકરણ શ્રેણીઓ વાપરે છે જે સમીક્ષિત મૂલ્યોથી બદલવી પડશે. Squid આમાંનું કોઈ પણ નામ સ્વયં માટે અનામત રાખતું નથી, તેથી તે પસંદ કરવાનું અને સુસંગત રાખવાનું તમારું કામ છે. આ રેસીપી Squid 6 અને 7 પૂરતી મર્યાદિત છે, જેની દસ્તાવેજીકૃત રૂપરેખા all-of જૂથને ટેકો આપે છે. વર્તમાન સંદર્ભ તે સૂચનાઓને Squid 8 માં અનુપલબ્ધ ગણે છે, તેથી આને સ્થળાંતરણ માર્ગ નહીં પણ આવૃત્તિ-બંધ રેસીપી તરીકે લો, અને લાગુ કરતા પહેલાં તમારી પોતાની આવૃત્તિના સંદર્ભમાં સૂચના ચકાસો.

acl pvpn_src src 192.0.2.128/25
acl pvpn_dst dst 198.51.100.77/32
acl pvpn_port port 1194
acl pvpn_ok all-of CONNECT pvpn_port pvpn_dst pvpn_src

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

પોર્ટ ગાર્ડ દૂર કર્યા વિના તેમને વાળો

તેમની હાલની જગ્યાએ બે રૂઢિગત ગાર્ડ લાઇન આવી દેખાય છે. તે સામાન્ય રીતે પ્રમાણીકરણ પછી અને બધું મંજૂર કરતી નીતિ લાઇનો પહેલાં રહે છે.

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

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

http_access deny CONNECT !SSL_ports !pvpn_ok
http_access deny !Safe_ports !pvpn_ok

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

અપવાદ ક્યાં મૂકવો ન જોઈએ

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

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

વિચારો કે એન્ડપોઇન્ટ બિલકુલ TCP છે કે નહીં. CONNECT અપવાદ TCP પ્રવાહો વહન કરે છે, અને UDP વાપરતી OpenVPN પ્રોફાઇલ તેના દ્વારા પહોંચી શકાય તેવી નહીં બને. પ્રોફાઇલને TCP માં ફક્ત ત્યારે બદલો જ્યારે સર્વર એ રીતે સાંભળે અને ઓપરેટર વર્તનનો તફાવત સ્વીકારે.

પાર્સર અને વાસ્તવિક વિનંતીથી સીમા ચકાસો

ફરીથી લોડ કરતા પહેલાં રૂપરેખા પાર્સ કરો, અને તે કરતી વખતે બીજું સત્ર ખુલ્લું રાખો. ફરીથી લોડ કરતી વખતે વાક્યરચના ભૂલ પ્રોક્સીને જૂની રૂપરેખા પર છોડી શકે છે અથવા નવીને સંપૂર્ણ નકારી શકે છે. પાર્સર નકારેલી લાઇન જણાવે છે, જે ક્લાઇન્ટ ભૂલ તમને કહેશે તેના કરતાં વધુ છે.

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

squid -k parse
squid -k reconfigure
curl -v -p -x http://proxy.lab.internal:3128 https://vpn.lab.internal:1194/ --max-time 5

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