કિલ સ્વિચ કોઈ પણ ટ્રાફિક પસાર થાય તે પહેલાં VPN સર્વરને અવરોધે છે
કિલ સ્વિચ કયા તબક્કાને અવરોધે છે: એન્ડપોઇન્ટ શોધ, બહારનો રૂટ, પરતનો માર્ગ અને જૂના પીઅર અપવાદો — અનુમાનને બદલે કાઉન્ટર સાથે.
કિલ સ્વિચ એવી દિશામાં નિષ્ફળ જાય છે જેની લોકો અપેક્ષા રાખતા નથી: તે ટનલ બંધ હોય ત્યારે ટ્રાફિક અવરોધવા માટે બનાવાયા છે, અને ટનલ બનાવતા પેકેટ પોતે જ ટ્રાફિક છે. આખી ભૂલ આ જ છે. જે નિયમસેટ ટનલમાંથી ન નીકળતું બધું ફેંકી દે છે તે એ હેન્ડશેક પણ ફેંકી દે છે જે તેને ઉપર લાવશે, તેથી ક્લાયન્ટ લૂપમાં ફરી પ્રયાસ કરે છે અને ભૂલ પહેલાં ચકાસાયેલા તબક્કાને આપવામાં આવે છે. ફાયરવૉલ પહોળો કરતાં પહેલાં શોધો કે ત્રણ તબક્કામાંથી કયો નકારાય છે: નામની શોધ, પીઅર તરફનું બહારનું પેકેટ, અથવા પાછું આવતું જવાબ.
ટનલ અને તેનું પોતાનું પરિવહન એકબીજા પર કેવી રીતે આધાર રાખે છે
VPN ક્લાયન્ટને એક જ સોકેટ માર્ગ વહેંચતી બે નેટવર્ક સ્થિતિ તરીકે વાંચો. ટનલ અસ્તિત્વમાં આવે તે પહેલાં ક્લાયન્ટ ભૌતિક એડેપ્ટર પર સોકેટ ખોલે છે અને એન્ક્રિપ્ટેડ ફ્રેમ પીઅરના સરનામા અને પોર્ટ પર મોકલે છે. તે વિનિમય સફળ થયા પછી જ તે ટનલ ઉપકરણ બનાવે છે અને રૂટ સ્થાપિત કરે છે. કિલ સ્વિચ બીજી સ્થિતિ વિશેની નીતિ છે, જે એટલી વિશાળ લખાયેલી છે કે તે બંને પર લાગુ પડે.
ઇન્ટરફેસ-આધારિત નિયમો સામાન્ય સ્વરૂપ છે: જે આમાંથી બહાર નીકળે તે સ્વીકારો tun0 અથવા wg0, બાકીનો આઉટપુટ માર્ગ ફેંકી દો. આ રચના ક્લાયન્ટના પોતાના સર્વર-કનેક્શનને મુક્ત કરી શકતી નથી, તેથી સાચું અમલીકરણ તે અપવાદ સ્પષ્ટ રીતે ઉમેરે છે, અને તમે પણ હાથે નિયમ લખતી વખતે તેમ કરો છો. Windows અને macOS પર દરેક એપ્લિકેશનના નિયમો ઇન્ટરફેસને બદલે પ્રક્રિયા મેળવીને આમાંથી થોડું ટાળે છે, પણ ટનલ બનતા પહેલાં પ્રક્રિયાને પણ બહાર નીકળવું પડે છે.
ત્રણ તબક્કા, જે ક્રમમાં થાય છે તે પ્રમાણે
પહેલો તબક્કો ઉકેલ છે. જ્યારે પ્રોફાઇલ શાબ્દિક સરનામાને બદલે હોસ્ટનામ સંગ્રહે છે, ત્યારે કંઈપણ મોકલતાં પહેલાં ક્લાયન્ટને DNS જવાબની જરૂર પડે છે. જે પ્રોફાઇલ DNSને ટનલ રિઝોલ્વર તરફ મોકલે છે તે ગતિરોધ બનાવે છે: રિઝોલ્વર ફક્ત તે ટનલ દ્વારા જ પહોંચી શકાય છે જે શોધે સક્ષમ કરવાની હોય છે. ટનલની બહાર ઉકેલવું, અથવા એન્ડપોઇન્ટને સરનામા પર પિન કરવું, આ અસ્પષ્ટતા દૂર કરે છે.
બીજો તબક્કો બહારનું પેકેટ છે, જેને આ ક્રમમાં પહેલાં રૂટિંગ અને પછી ફાયરવૉલ પાર કરવો પડે છે. wireguard-tools WireGuard માટે આનો રૂટિંગ અડધો ભાગ સંભાળે છે: પોતાના પેકેટ ચિહ્નિત કરે છે અને નીતિ નિયમ ઉમેરે છે જેથી તે હમણાં જ સ્થાપિત કરેલા ડિફૉલ્ટ રૂટને છોડી દે; wg-quick નું મેન પેજ તે નિયમ અને તે જે કોષ્ટક વાપરે છે તે વર્ણવે છે. આ રૂટિંગ હાથે ફરી બનાવો, અથવા બીજા સાધનને નિયમો ફરી લખવા દો, તો ચિહ્નિત પેકેટ જે ટનલ બનાવવાના છે તેમાં પાછા મોકલાઈ શકે છે.
ત્રીજો તબક્કો પરતનો માર્ગ છે. જવાબ વગરનો હેન્ડશેક બહાર તરફ ફેંકવાનો પુરાવો નથી; તે સર્વરના ઇનબાઉન્ડ નિયમ અથવા મેપિંગ ભૂલી ગયેલા NAT ઉપકરણ સાથે પણ એટલો જ સુસંગત છે. ક્લાયન્ટને સ્પર્શતાં પહેલાં આને અલગ કરો.
| What you see | Stage | Where to look |
|---|---|---|
| The client log repeats a resolve step and no packets appear on the wire | 1, name lookup | Resolver path while the tunnel is down |
| The send counter on the physical adapter stays flat | 2, routing | Peer route and policy rules |
| The send counter rises and a firewall drop counter rises | 2, firewall | Rule order, mark, and interface match |
| Packets leave and nothing comes back | 3, return path | Server input rules, NAT, listening port |
ક્લાયન્ટ જે લક્ષણ પકડે છે તે લોગ કરે છે, નિષ્ફળ ગયેલો તબક્કો નહીં, તેથી કોષ્ટક સામાન્ય રીતે લોગ કરતાં ઝડપી હોય છે.
કાઉન્ટર લોગ કરતાં ઝડપી નિર્ણય આપે છે
Linux પર, nft list ruleset અથવા iptables -vnL OUTPUT દરેક નિયમ માટે પેકેટ કાઉન્ટર છાપે છે. એક વાર કનેક્ટ કરો, નિષ્ફળ થવા દો, પછી કાઉન્ટર ફરી વાંચો. જે નિયમનું કાઉન્ટર ખસ્યું તે નિયમ છે જેને હેન્ડશેક અડ્યો; જો ક્યાંય કંઈ ખસ્યું ન હોય, તો પેકેટ કદી ફાયરવૉલ સુધી પહોંચ્યું નથી. મેં એક નિયમસેટને પોતાનો હેન્ડશેક ફેંકી દેતો જોયો છે, અને ફક્ત કાઉન્ટરે જ તે કહ્યું.
ફાયરવૉલ સુધી કદી ન પહોંચ્યું અને હોસ્ટ છોડ્યું જ નહીં તેને અલગ કરવા માટે ઇન્ટરફેસ પોતે જુઓ. ip -s link show dev wlan0 મોકલાયેલા પેકેટની જાણ કરે છે, અને tcpdump -ni wlan0 udp port 51820 ફ્રેમ દર્શાવે છે. જ્યારે ક્લાયન્ટ ફરી પ્રયાસ કરે છે ત્યારે તે સપાટ રહે, તો ખામી netfilterની ઉપર છે: ખૂટતો પીઅર રૂટ, હજી અસ્તિત્વમાં ન હોય તેવા ઉપકરણ તરફ જતો નીતિ નિયમ, અથવા ક્લાયન્ટ ગળી જતી સોકેટ ભૂલ.
દસ્તાવેજી સરનામાં સામે અપવાદ ચકાસો, જેમ કે 203.0.113.10, જેથી ભૂલ બીજાના હોસ્ટની તપાસ ન કરી શકે.
જૂનો એન્ડપોઇન્ટ અપવાદ સર્વર બંધ પડ્યા જેવો વંચાય છે
સૌથી ગૂંચવણભરી આવૃત્તિ પીઅરનું સરનામું બદલાયા પછી દેખાય છે: ગતિશીલ-સરનામા સેવાએ તેને ખસેડ્યું, હોસ્ટ ફરી બાંધવામાં આવ્યું, અથવા તમારા નેટવર્કનું આઉટગોઇંગ સરનામું અલગ છે. અપવાદ હજી જૂનું સરનામું કહે છે, તેથી નવા તરફના પેકેટ ફેંકવાના નિયમમાં આવે છે. એ જ રૂપરેખાંકન ગઈકાલે કામ કરતું હતું, અને તેથી લોકો સર્વરની સમસ્યા શોધવાથી શરૂ કરે છે.
ફાયરવૉલ નિયમની અંદરનું હોસ્ટનામ તમને બચાવતું નથી. nftablesમાં નિયમસેટ લોડ થાય ત્યારે નામ ઉકેલાય છે, તેથી તે તે ક્ષણે હાજર સરનામું પિન કરે છે અને શાબ્દિક સરનામાની જેમ જૂનું થઈ જાય છે. ટકાઉ ઉકેલ એ છે કે એન્ડપોઇન્ટ બદલાય ત્યારે અપવાદ અપડેટ કરો અને તેને સાંકડો રાખો: એક પીઅર સરનામું, એક પરિવહન પોર્ટ. સરનામા ફેરફાર ટકાવી રાખે એટલી પહોળી શ્રેણી અસંબંધિત ટ્રાફિકને પણ બહાર જવા દે એટલી પહોળી છે.
જ્યારે કિલ સ્વિચ સર્વર હોસ્ટ પર ચાલે છે
એ જ આધાર બીજા છેડે પણ છે, અને ત્યાં તેને ચૂકી જવું સરળ છે. જો તમારા VPN સર્વર તરીકેનું મશીન કિલ સ્વિચ સાથેનું ડેસ્કટોપ ક્લાયન્ટ ચલાવે, અથવા લેપટોપમાંથી કૉપિ કરેલી ફાયરવૉલ પ્રોફાઇલ ચલાવે, તો તેના ફેંકવાના નિયમો ટનલ સમાપ્ત કરતી સેવા પર લાગુ પડે છે. ક્લાયન્ટના હેન્ડશેકના જવાબ ફેંકાય છે, તેથી સર્વર સ્વસ્થ દેખાય અને તેનું ટનલ ઇન્ટરફેસ વપરાયા વગર રહે ત્યારે પણ દરેક ક્લાયન્ટ કનેક્ટ થવામાં નિષ્ફળ જાય છે.
તે હોસ્ટને ફેંકતાં પહેલાં ત્રણ સાંકડી સ્વીકૃતિની જરૂર છે: ભૌતિક ઇન્ટરફેસ પર સાંભળવાનો પોર્ટ, ડિક્રિપ્ટ થયેલા ટ્રાફિક માટે ટનલ ઇન્ટરફેસ, અને ટનલમાંથી ક્લાયન્ટ ક્યાં પહોંચવાના છે તે તરફ ફોરવર્ડિંગ. સ્થાપિત સેટ આની સાથે વાંચો: nft list ruleset, iptables -S, અથવા pfctl -sr કંઈપણ બદલતાં પહેલાં, અને યાદ રાખો કે સાચવેલો નિયમસેટ રીબૂટ પછી પણ ટકે છે, તેથી ત્યાંની ભૂલ તેને બનાવનારી પ્રક્રિયા કરતાં વધુ ટકે છે.
મશીન બંધ રાખતો પુનઃપ્રાપ્તિ ક્રમ
પ્રોફાઇલમાંથી બહારની તરફ કામ કરો. ક્લાયન્ટ જે પીઅર સરનામું અને પોર્ટ વાપરે છે તે વાંચો, ટનલ વગર હોસ્ટનામ ઉકેલાય છે તેની ખાતરી કરો, પછી ફક્ત ભૌતિક એડેપ્ટર પર તે સરનામા અને પોર્ટ માટે એક અપવાદ ઉમેરો. ફરી કનેક્ટ કરો અને મોકલવાનું કાઉન્ટર જુઓ; પૂર્ણ થયેલો હેન્ડશેક એ સંકેત છે કે બીજો તબક્કો સુધારાયો છે.
પરીક્ષણ દરમિયાન ફેંકવાની બાકીની નીતિ યથાસ્થાને રાખો. નિર્દોષ તપાસ એ છે કે અસંબંધિત દસ્તાવેજી સરનામા પર કનેક્શનનો પ્રયાસ કરો અને ખાતરી કરો કે તે હજી સમયસીમા પર પૂરો થાય છે, જે દર્શાવે છે કે કિલ સ્વિચ બંધ નહીં પણ કામ કરે છે. ટનલ સ્થિર થાય પછી અપવાદ કડક કરો, અને સુવિધા ખાતર ક્લાયન્ટ પ્રોગ્રામ માટે કાયમી બધું-મંજૂરી રાખશો નહીં.
જો ટનલ ઉપર આવે અને એપ્લિકેશન હજી નિષ્ફળ જાય, તો બાકીના તબક્કા આ નથી: વિભાજિત DNS, MTU અને દરેક એપ્લિકેશન માટેનું રૂટિંગ દરેક જોડાયેલી ટનલ સાથે તૂટેલો ટ્રાફિક આપે છે, અને દરેકની પહેલી તપાસ અલગ છે.