VPN ડિસ્કનેક્ટ થયા પછી પણ કિલ સ્વિચ ટ્રાફિકને અવરોધે છે

ટનલ ગઈ છે, નેટવર્ક આઇકન સામાન્ય લાગે છે અને કંઈ લોડ થતું નથી. તમે VPN ડિસ્કનેક્ટ કર્યું, અથવા તેને અનઇન્સ્ટોલ કર્યું, અથવા રીબૂટ કર્યું, અને જે બ્લોક ડ્રોપ દરમિયાન તમને બચાવવાનો હતો તે હજી ઊભો છે. ક્લાયન્ટ વિન્ડો આ સમજાવી શકતી નથી, કારણ કે તમને અવરોધતું ક્લાયન્ટ નથી: નિર્ણય તમારા નામે કર્નલમાં લખાયો હતો, અને તેને દૂર કરવા પાછળ કંઈ બાકી રહ્યું નથી. Windows માં તે સ્થિતિ Windows Filtering Platform માં રહે છે; Linux માં તે iptables અથવા nftables માં નિયમોનો સમૂહ છે, ઘણી વાર બૂટ વખતે ફરી ચલાવાતા સ્નેપશોટ સાથે. આગળ જે છે તે મારો ક્રમ છે: સ્થિતિ વાંચો, નિષ્ફળતા સમજાવતી સૌથી સાંકડી વસ્તુ કાઢી નાખો અને પછી જે પણ તેને વારંવાર પાછી લાવે છે તે શોધો.

કિલ સ્વિચ કર્નલની સ્થિતિ છે, કોઈ સેટિંગ નહીં

ડેસ્કટોપ ક્લાયન્ટ ટનલની બહારના ટ્રાફિકને નકારતા ફિલ્ટરો ઉમેરીને બ્લોકિંગ લાગુ કરે છે. Windows માં તે કનેક્શન-રીડાયરેક્ટ અને ટ્રાન્સપોર્ટ સ્તરો પરના WFP ફિલ્ટરો છે, અને તેમાંથી કેટલાક ચીરસ્થાયી છે: તેઓ Base Filtering Engine ના પોલિસી સ્ટોરમાં નોંધાય છે અને મશીન બૂટ થતાં જ પુનઃસ્થાપિત થાય છે, કોઈપણ VPN સોફ્ટવેર ચાલે તે પહેલાં. ક્લાયન્ટ ક્યારે સફાઈ કરે તેમાં ભિન્ન છે. કેટલાક ડિસ્કનેક્ટ વખતે ફિલ્ટરો દૂર કરે છે, કેટલાક ફક્ત સ્વચ્છ એક્ઝિટ પર, અને કેટલાક ફક્ત ત્યારે જ જ્યારે કિલ સ્વિચ પહેલાં બંધ કરવામાં આવે. બ્લોક સક્રિય હોય ત્યારે અનઇન્સ્ટોલ કરો, અથવા પ્રોસેસ મારી નાખો, અને ફિલ્ટરો રહે છે.

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

કંઈપણ કાઢી નાખતા પહેલાં WFP સ્થિતિ વાંચો

Windows તમને જરૂરી સાધનો સાથે આવે છે. એક એલિવેટેડ પ્રોમ્પ્ટ ચલાવો અને પ્લેટફોર્મની સ્થિતિ ડમ્પ કરો; ડમ્પ વર્કિંગ ડિરેક્ટરીમાં wfpstate.xml તરીકે આવે છે.

netsh wfp show state
netsh wfp show filters
Get-Service bfe

XML માં ગયેલા વેન્ડરનું નામ, Block ક્રિયા અને સ્તર શોધો. કનેક્શન-રીડાયરેક્ટ અને ટ્રાન્સપોર્ટ પરના ફિલ્ટરો સામાન્ય ટ્રાફિક તોડે છે; receive-accept સ્તર પરનું ફિલ્ટર સામાન્ય રીતે તમારું કારણ નથી. જો Base Filtering Engine બિલકુલ ન ચાલતું હોય, તો બીજે શોધો, કારણ કે તે ફિલ્ટરો લાગુ કરવા બીજું કંઈ સમર્થ નથી.

સામાન્ય ફાયરવોલ દૃશ્ય પણ તપાસો, કારણ કે મોટાભાગના લોકો બેમાંથી ફક્ત એક જ જુએ છે:

netsh advfirewall show allprofiles
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

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

Linux નિયમો તે જ સિન્ટેક્સમાં વાંચો જેનાથી તમે કાઢી નાખશો

iptables -S નિયમોને તે જ સ્વરૂપમાં છાપે છે જે તેમને ઉમેરવા માટે વપરાય છે, જે આઉટપુટને કાઢી નાખવા માટે સીધું ફરી વાપરી શકાય તેવું બનાવે છે. iptables -L -v -n પેકેટ કાઉન્ટરો ઉમેરે છે, અને તે કાઉન્ટરો કહે છે કે નિયમ ખરેખર તમારી નિષ્ફળ વિનંતીઓ સાથે મેળ ખાય છે કે ફક્ત ચેઇનમાં બેઠો છે.

sudo iptables -S
sudo ip6tables -S
sudo iptables -t nat -S

ચેઇન પોલિસીઓ વાંચો, ફક્ત નિયમો નહીં: -P OUTPUT DROP કોઈ નિયમ ન મળે તો પણ ટ્રાફિક અવરોધે છે. IPv6 અલગથી તપાસો, કારણ કે બંને કુટુંબ ઇન્સ્ટોલ કરતું ક્લાયન્ટ IPv4 નિયમો ગયા પછી પણ IPv6 બ્લોક છોડી શકે છે, અને પછી લક્ષણ એના પર આધાર રાખે છે કે એપ્લિકેશન કયું કુટુંબ પસંદ કરે છે. જ્યાં nftables વપરાય છે ત્યાં nft list ruleset પણ ચલાવો; બંને સાધનો સુસંગતતા સ્તર દ્વારા સાથે રહે છે, અને એક યાદી પેકેટ પાડી શકતા દરેક નિયમને જરૂરી રીતે બતાવતી નથી.

નિષ્ફળતા સમજાવતી સૌથી સાંકડી વસ્તુ કાઢી નાખો

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

Get-ScheduledTask | Where-Object TaskName -like '*vpn*'
Get-Service | Where-Object DisplayName -like '*vpn*'

ચીરસ્થાયી ફિલ્ટરો છેલ્લો ઉપાય છે. તેઓ HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter હેઠળ રહે છે, દરેક ફિલ્ટર માટે GUID કી સાથે એક મૂલ્ય. પહેલાં કી નિકાસ કરો, જે GUID દૂર કરો છો તે નોંધો, ફક્ત ગયેલા ક્લાયન્ટના મૂલ્યો કાઢી નાખો, પછી રીબૂટ કરો જેથી એન્જિન તેની સ્થિતિ ફરી બનાવે. આખી કી કાઢી ન નાખો અને Base Filtering Engine બંધ ન કરો: Windows Firewall અને Defender તેના પર આધાર રાખે છે, અને તમે એક વિક્ષેપને વધુ ખરાબ સાથે બદલી નાખશો.

reg export "HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent" C:\temp\bfe-backup.reg

Linux માં, iptables -S જે લાઇન છાપે છે તે લો અને -A ને -D થી બદલો. ઓળખેલો એક જ નિયમ કાઢી નાખવો ચેઇન ફ્લશ કરવા કરતાં સારો છે, કારણ કે તે તમારી પોતાની પોલિસી અકબંધ રાખે છે.

sudo iptables -D OUTPUT -p udp -j REJECT

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

જે માલિક તેને પાછી મૂકે છે તેને શોધો

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

જો બ્લોક પાછો આવે, તો કાઢી નાખવું ઉપાય નહોતો; માલિક ઉપાય હતો. કયું ક્લાયન્ટ કે સેવા તેને ઇન્સ્ટોલ કરે છે તે નોંધો અને ત્યાં જ સુવિધા બંધ કરો, દરેક ડિસ્કનેક્ટ પછી ફાયરવોલ સ્તરે તેની સાથે લડવાને બદલે.

એક પિંગ નહીં, વાસ્તવિક ટ્રાફિકથી ચકાસો

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

પુરાવા રાખો: નિકાસ કરેલી BFE કી, અથવા બદલાવ પહેલાં પકડેલું iptables -S આઉટપુટ. તેને સુધારાયેલું કહેતા પહેલાં, તમે કયા સ્તરથી વસ્તુ દૂર કરી તે, તેને ફરી ઇન્સ્ટોલ કરી શકે તેવો માલિક, એક સ્વચ્છ રીબૂટ પછીની સ્થિતિ, અને કોઈ VPN પ્રોસેસ ચાલુ ન હોવા છતાં સામાન્ય બ્રાઉઝિંગ કામ કરે છે તેની ખાતરી કરો. જો ક્લીનઅપ સ્ક્રિપ્ટ કરો તો iptables(8) મેન પેજમાં ચોક્કસ કાઢી નાખવાની અને પોલિસી સિન્ટેક્સ છે.