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

રાઉટરથી શરૂ કરો, લેપટોપથી નહીં

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

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

પેકેટ લઈ શકે તેવા ત્રણ માર્ગોમાંથી પસાર થાઓ

લેપટોપથી ઇન્ટરનેટ તરફની ટ્રાફિક ફોરવર્ડ થાય છે, તેથી તે FORWARD ચેઇનમાંથી પસાર થાય છે. રાઉટર પોતે બનાવે છે તે ટ્રાફિક, જેમ કે DNS ફોરવર્ડિંગ, NTP ક્વેરી, DDNS અપડેટ અને VPNનો કંટ્રોલ ચેનલ, OUTPUTમાંથી પસાર થાય છે. રાઉટરને સંબોધિત મેનેજમેન્ટ ટ્રાફિક INPUTમાંથી આવે છે.

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

Packet pathExampleChain that sees it
LAN client to WAN or tunnelBrowser requestFORWARD
Router-originatedDDNS update, NTPOUTPUT
Addressed to the routerSSH from the LANINPUT

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

નિયમો એવી રીતે ગોઠવો કે ટનલ હજુ ઉપર આવી શકે

કામ કરતો કિલ સ્વિચ એ પરવાનગીઓની એ યાદી છે જે નકાર પર પૂરી થાય છે, અને ક્રમ જ તેને કિલ સ્વિચ બનાવે છે, ઈંટ નહીં. પહેલા loopback, VPN એન્ડપોઇન્ટ, સ્થાપિત ફ્લોના જવાબો અને ટનલ ઇન્ટરફેસને પરવાનગી આપો; બાકીનાને અંતે નકારો.

iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 51820 -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o wg0 -j ACCEPT
iptables -A OUTPUT -o eth0 -j REJECT

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

ક્લાયન્ટ ટ્રાફિક માટે એ જ આકાર FORWARDમાં પુનરાવર્તિત કરો, અને નકારની ઉપર સ્પષ્ટ મેનેજમેન્ટ નિયમ મૂકો. એ મેનેજમેન્ટ નિયમને સાંકડો પણ પહોંચી શકાય તેવો રાખો, અને પહેલું SSH સત્ર બંધ કરતા પહેલા બીજું સત્ર ખોલીને તેની ખાતરી કરો. કિલ સ્વિચ બદલતી વખતે પોતાને બહાર તાળું મારવું એટલું સામાન્ય છે કે તેનું આયોજન કરવું જોઈએ. WireGuard ચલાવતા રાઉટર પર પીઅરના allowed-ips નક્કી કરે છે કે ટનલમાં શું જાય છે, જ્યારે આ નિયમો નક્કી કરે છે કે તેના વિના શું બહાર જઈ શકે છે.

IPv6ને પોતાનું દરવાજું જોઈએ

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

ip6tables -A FORWARD -i br-lan -j REJECT
ip6tables -A OUTPUT -o eth0 -j REJECT
ip6tables -A OUTPUT -o lo -j ACCEPT

અહીં પણ ક્રમ મહત્ત્વનો છે: loopbackની પરવાનગી WANના નકાર પહેલા આવવી જોઈએ, નહીં તો રાઉટર પરની સ્થાનિક સેવાઓ વિચિત્ર રીતે નિષ્ફળ થવા લાગે છે. જો નેટવર્ક IPv6 બિલકુલ વાપરતું ન હોય, તો તેને WAN અને LAN પર બંધ કરવું સરળ છે અને ભૂલવા જેવું કંઈ રહેતું નથી.

કેટલાક VPN ક્લાયન્ટ ફક્ત IPv4 માટે ડિફોલ્ટ રૂટ ઇન્સ્ટોલ કરે છે અને હાલનો IPv6 ડિફોલ્ટ રૂટ અડ્યો ન રહેવા દે છે. ટનલ જોડાયા પછી રૂટિંગ કોષ્ટક ચકાસો, ક્લાયન્ટે સંભાળી લીધું છે એમ માની લેવાને બદલે.

ટનલ બંધ હોય ત્યારે આ સાબિત કરો

ટનલ રાઉટરથી થોભાવો અને ત્રણ જગ્યાઓથી આ ક્રમમાં ચકાસો:

# systemctl stop wg-quick@wg0
# ip route get 203.0.113.1
# curl -m 5 -sS http://example.com || echo blocked
# iptables -vnL OUTPUT | head
# ip6tables -vnL OUTPUT | head

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

નિષ્ફળતાની રીત જરૂર પડે તે પહેલા નક્કી કરો. fail-closed ક્લાયન્ટોને ટનલ પાછી ન આવે ત્યાં સુધી ઑફલાઇન રાખે છે; fail-open સામાન્ય WAN પ્રવેશ પુનઃસ્થાપિત કરે છે અને તમને મહત્ત્વની હતી તે ટ્રાફિકનો હેતુ નિષ્ફળ કરે છે. ઊંચા મેટ્રિક સાથે VPN પૂલ તરફનો blackhole માર્ગ fail-closed રચનાઓ માટે ઉપયોગી બીજો સ્તર છે, કારણ કે ટનલ માર્ગ અદૃશ્ય થાય ત્યારે તે ડિફોલ્ટ પર પડવાને બદલે ટકી રહે છે.

LAN ક્લાયન્ટ, રાઉટરે બનાવેલી વિનંતી અને IPv6 વિનંતી ત્રણેય ટનલ બંધ હોય ત્યારે નિષ્ફળ થાય, અને ટનલ ઉપર આવે ત્યારે ત્રણેય ફરી કામ કરે ત્યારે જ સેટઅપ સ્વીકારો.

સંબંધિત લેખો