VPN કનેક્ટ છે પણ ફાયરવોલ હજી અવરોધે છે: કયું કારણ છે તે કેવી રીતે જાણવું

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

માર્ગને નીતિથી અલગ કરો

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

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

માર્ગ એક જ પાસમાં વાંચો

એક પણ નિયમ જોતાં પહેલાં ખાતરી કરો કે ટનલ ગંતવ્યને આવરી લે છે. જે સ્પ્લિટ ટનલ ફક્ત ઓફિસ સબનેટ વહન કરે છે તે બીજી શ્રેણીમાં વિનંતી મોકલશે નહીં, અને પછી નિષ્ફળતા ફાયરવોલ અવરોધ જેવી લાગે છે, જે તે નથી:

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

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

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

જે સ્તર જવાબ આપે છે તેમાં નીતિ વાંચો

માર્ગ સાચો થાય પછી, હોસ્ટથી બહાર તરફ નીતિમાં ચાલો અને તે એક જ સ્તર પર નજર રાખો જેના કાઉન્ટર ખસે છે:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

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

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

ટનલ ત્યાં પૂરી થાય ત્યારે ગેટવેનો નિર્ણય વાંચો

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

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

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

સૌથી સાંકડું સ્તર બદલો, પછી ચકાસો

વ્યાપક સમારકામનો પ્રતિકાર કરો. હોસ્ટ ફાયરવોલ બંધ કરવો, બધું મંજૂર કરતો નિયમ ઉમેરવો, અથવા દરેક ઇન્ટરફેસને વિશ્વસનીય પ્રોફાઇલમાં ધકેલવો — દરેક તે નિયંત્રણ દૂર કરે છે જે પોતાનું કામ કરતું હતું, અને ફેરફાર ઘટના પછી પણ ટકે છે. સ્રોત શ્રેણી અને સંબંધિત પોર્ટ સુધી મર્યાદિત નિયમ સમીક્ષા કરવા સરળ છે, દૂર કરવા સરળ છે, અને મશીનની બાકીની નીતિ અકબંધ રાખે છે.

જે કસોટી નિષ્ફળ ગઈ તે જ કસોટીથી, તે જ ક્લાયન્ટથી ચકાસો, અને પછી ફરી જોડાણ પછી એક વાર, કારણ કે ટનલ ફરી વાટાઘાટ કરે તે પહેલાં મેળ ખાતો નિયમ પછી મેળ ન ખાઈ શકે:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

તે બંધ કરતાં પહેલાં:

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