રાઉટર VPN દ્વારા એક ઉપકરણને ત્રણ નિયમો જોઈએ, સ્વિચ નહીં

રાઉટર VPN દ્વારા એક ઉપકરણ એ નીતિ-માર્ગીકરણ છે, ચેકબોક્સ નહીં: એક ચિહ્નિત કોષ્ટક, મર્યાદિત NAT નિયમ, ઉપરાંત DNS, IPv6 અને LAN માર્ગો જે માર્ગદર્શિકાઓ છોડી દે છે.

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

દંતકથા: ટનલ એ ક્લાયન્ટ સેટિંગ છે

રાઉટર બાજુનો VPN ક્લાયન્ટ એક જાડું કામ સારી રીતે કરે છે: તે 0.0.0.0/0 મુખ્ય રૂટિંગ કોષ્ટકમાં મૂકે છે અને તેને ટનલ તરફ નિર્દેશ કરે છે. WireGuard આ AllowedIPs માંથી લે છે, OpenVPN ધકેલાયેલા redirect-gateway માંથી, અને બંને રાઉટર પાછળના દરેક હોસ્ટ માટે માર્ગ બદલે છે. AllowedIPs સાંકડું કરવું અથવા route-nopull ઉમેરવું એ બદલે છે જે ક્લાયન્ટ સ્થાપિત કરે છે. તે એ બદલતું નથી કે સ્થાપન કોને લાગુ પડે છે, કારણ કે ક્લાયન્ટ ક્યારેય ઉપકરણો જોતો નથી. તે ફક્ત પેકેટ જુએ છે.

સ્રોત કે લક્ષ્ય દ્વારા પસંદગી એ રૂટિંગ નિર્ણય છે, તેથી તે રાઉટરના નીતિ સ્તરનું કામ છે: RouterOS પર એક mangle નિયમ અને બીજું કોષ્ટક, OpenWrt કે DD-WRT પર MARK અને ip rule, અથવા pfSense પર એવો ફાયરવોલ નિયમ જેનું ગેટવે ટનલ છે. Netgate ની WireGuard ક્લાયન્ટ રેસિપી એ છે જે અનુમાન કરતાં પહેલાં વાંચવી જોઈએ, કારણ કે તે પ્લેટફોર્મ પર નિયમનું ગેટવે, ઇન્ટરફેસ ફાળવણી અને આઉટબાઉન્ડ NAT એન્ટ્રી બધું સહમત થવું પડે તે પહેલાં કે એક પણ ક્લાયન્ટ ટનલ વાપરે.

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

પ્રથમ ભાગ: ટનલ જે ડિફોલ્ટ માર્ગ નથી

RouterOS પર, ક્લાયન્ટને ડિફોલ્ટ માર્ગ વિના ઉમેરો અને ટનલને તેનું પોતાનું કોષ્ટક આપો. પ્રથમ માર્ગ ચિહ્નિત ડિફોલ્ટ છે; બીજો નિષ્ફળતાનો અર્ધો ભાગ છે.

/ip route add dst-address=0.0.0.0/0 gateway=VPN_GATEWAY_IP routing-mark=vpn distance=1
/ip route add dst-address=0.0.0.0/0 type=unreachable routing-mark=vpn distance=2

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

RouterOS 7 એ અલગ કરે છે જે 6.x એકસાથે રાખતું હતું: તમે /routing table add name=vpn fib વડે કોષ્ટક જાહેર કરો છો, પછી માર્ગમાં અને mangle નિયમમાં નામથી તેનો સંદર્ભ લો છો. 6.x નો સ્નિપેટ જે કોષ્ટક વ્યાખ્યાયિત કર્યા વિના routing-mark ઇનલાઇન મૂકે છે તે સ્વચ્છ રીતે લોડ થાય છે અને કંઈપણ સાથે મેળ ખાતું નથી. બીજો ક્લાસિક કિસ્સો બે 0.0.0.0/1 અર્ધા ભાગ છે, અથવા એક કોષ્ટકમાં સમાન અંતરે બે ડિફોલ્ટ: કર્નલ એક પસંદ કરે છે, અને રીબૂટ પછી વર્તન બદલાઈ શકે છે.

બીજો ભાગ: માર્ગ શોધ પહેલાં ચિહ્નિત કરો

સિલેક્ટર નક્કી કરે છે કયા પેકેટ તે કોષ્ટકમાં પ્રવેશે. RouterOS સામાન્ય રીતે લક્ષ્ય નીતિ માટે સરનામાં યાદી સાથે, અથવા ઉપકરણ નીતિ માટે સ્રોત સરનામા સાથે શરૂ કરે છે:

/ip firewall mangle add chain=prerouting src-address=192.168.88.50 action=mark-routing new-routing-mark=vpn
/ip firewall mangle add chain=prerouting dst-address-list=via-vpn action=mark-routing new-routing-mark=vpn
/ip firewall address-list add list=via-vpn address=203.0.113.10

Linux ફર્મવેર એ જ કામ netfilter ચિહ્ન અને એવા નિયમ વડે કરે છે જે ચિહ્નિત પેકેટોને તમે ભરેલા કોષ્ટકમાં મોકલે છે:

iptables -t mangle -A PREROUTING -p tcp --dport 27000:27050 -j MARK --set-mark 0x200
ip route add default dev tun0 table 100
ip rule add fwmark 0x200 table 100

ચેઇન એ શૈલીની પસંદગી નથી. જ્યારે પેકેટ FORWARD સુધી પહોંચે ત્યારે માર્ગ શોધ પહેલેથી થઈ ગયેલી હોય છે, તેથી ત્યાં MARK કે DROP ફક્ત ફરીથી લખી કે કાઢી શકે. ચિહ્ન PREROUTING માં ફોરવર્ડ થતા ટ્રાફિક માટે અને OUTPUT માં રાઉટર પોતે બનાવતા ટ્રાફિક માટે પડવું જોઈએ, કારણ કે રાઉટરનું DNS, NTP અને અપડેટ ચકાસણીઓ ત્યાં જ રહે છે. એ જ આઉટપુટ માર્ગ સામાન્ય કારણ છે કે સંપૂર્ણ ટનલ કરેલું સેટઅપ લીક ટેસ્ટમાં હજી ISP રિઝોલ્વરથી જવાબ આપે છે.

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

ત્રીજો ભાગ: NAT, DNS અને LAN અપવાદ

ટનલમાંથી બહાર જતા ટ્રાફિકને એવું સ્રોત સરનામું જોઈએ જેને દૂરની બાજુ જવાબ આપે. અનુવાદને ટનલ ઇન્ટરફેસ સુધી મર્યાદિત કરો: RouterOS પર out-interface=VPN_NAME, Linux પર -o tun0, pfSense પર મેળ ખાતી આઉટબાઉન્ડ NAT એન્ટ્રી. આ મર્યાદા વિનાનો masquerade નિયમ એ ટ્રાફિક ફરીથી લખે છે જેને તમે અકબંધ રાખવા માંગતા હતા, અને લક્ષણ એ છે કે ટનલ ન કરેલું ઉપકરણ તેનું જાહેર સરનામું ગુમાવે છે.

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

DNS અલગ માર્ગ લે છે. રાઉટર ફોરવર્ડ કરે તે ક્વેરીઓ રાઉટરમાંથી ઉદભવે છે અને OUTPUT ને અનુસરે છે, ફોરવર્ડ ચિહ્નને નહીં, તેથી સંપૂર્ણ ટનલ કરેલું લેપટોપ હજી ISP દ્વારા રિઝોલ્વ કરી શકે છે. ક્લાયન્ટને ટનલ દ્વારા પહોંચી શકાય તેવા રિઝોલ્વર તરફ દોરો, અથવા રાઉટરના પોતાના પોર્ટ 53 ટ્રાફિકને ચિહ્નિત કરો, પછી જવાબ વેબ વિનંતી સાથે ગયો હોવાનું ધારવાને બદલે રિઝોલ્વ થયેલું સરનામું તપાસો.

જ્યારે નિયમ મેળ ખાય પણ એપ હજી WAN વાપરે

લક્ષ્ય યાદીઓ ખરાબ રીતે જૂની થાય છે. નામ એવા સરનામા પર રિઝોલ્વ થાય છે જે યાદીમાં નથી, તેથી વિનંતી WAN લે છે જ્યારે યાદીમાંના સરનામા સામેની તમારી દરેક કસોટી કામ કરતી હતી. ક્લાયન્ટ વાપરે તે જ રિઝોલ્વરથી યાદી તાજી કરો, અને જ્યારે ખરેખર એક ઉપકરણનો બધો ટ્રાફિક જોઈએ ત્યારે સ્રોત-આધારિત સિલેક્ટરને પ્રાધાન્ય આપો.

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

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

બે ઉપકરણ અને રીબૂટ સાથે ચકાસો

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

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

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

સંબંધિત લેખો