VPN સરનામું વ્હાઇટલિસ્ટ કર્યું અને હજી પણ બ્લોક છે? તેને ટ્રેસ કરો

VPN એપ જે સરનામું બતાવે છે તેને વ્હાઇટલિસ્ટમાં ઉમેરવાથી બ્લોક થયેલો પોર્ટ ભાગ્યે જ ઠીક થાય છે, અને પેકેટ જ કારણ સમજાવે છે. ફાયરવૉલ તમારા નિયમને અવગણતો નથી; તે એવું સ્રોત સરનામું મૂલ્યાંકન કરે છે જે ક્લાઇન્ટ સ્ક્રીન પર કંઈ બતાવતું નથી. જ્યાં સુધી ગંતવ્ય તે મૂલ્યની જાણ ન કરે, ત્યાં સુધી દરેક નિયમ સંપાદન એક અનુમાન છે.

સેવા સુધી પહોંચતી વિનંતીથી શરૂ કરો. ટનલ સરનામું, એક્ઝિટ સરનામું અને તેમની વચ્ચેનું કોઈપણ ભાષાંતર ત્યાં સુધી પરિકલ્પનાઓ જ રહે છે જ્યાં સુધી ગંતવ્ય તેમાંથી એકની પુષ્ટિ ન કરે.

એપમાં દેખાતું સરનામું પહોંચતું સરનામું નથી

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

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

એક વિનંતીને તેની ફિલ્ટરિંગ સીમા સુધી ટ્રેસ કરો

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

અધિકૃત Linux હોસ્ટ પર, બદલતાં પહેલાં જીવંત નિયમો ક્રમમાં વાંચો. ફોરવર્ડ થયેલી અને કન્ટેનર સેવાઓ ઘણી વાર તેમની પોતાની ચેઇનમાં કૂદે છે, તેથી અંતિમ ચુકાદા સાથે કૂદકાનું લક્ષ્ય પણ તપાસો.

iptables -vnL INPUT --line-numbers
iptables -S INPUT | head -n 40
ss -ltnp | grep -E ':(443|9443)\b'

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

એક મર્યાદિત કેપ્ચરથી માર્ગ ચકાસો

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

tcpdump -ni any 'tcp dst port 9443' -c 20

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

ફક્ત નિયમ નહીં, ચેઇનનો ક્રમ વાંચો

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

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

જે નિયમનો માલિક નિયંત્રણ કરે છે તે નિયમ બદલો

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

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