VPN દ્વારા માત્ર એક ખાનગી સબનેટ કેવી રીતે મોકલવું

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

ડિઝાઇન નક્કી કરતી ત્રણ શરતો

પ્રથમ, તમને નેટવર્કના માલિક પાસેથી ચોક્કસ પ્રીફિક્સ અને માસ્ક જોઈએ. 10.x નેટવર્ક પ્રીફિક્સ નથી; 10.20.0.0/16 પ્રીફિક્સ છે. ખાતરી કરો કે તે તમારા ઘરના LAN, Docker બ્રિજ કે તમે ચલાવો છો તેવા બીજા VPN સાથે ઓવરલેપ થતું નથી, કારણ કે ઓવરલેપ રૂટને અસ્પષ્ટ બનાવે છે અને કર્નલ તમે ન ઇચ્છેલી એન્ટ્રી પસંદ કરે છે.

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

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

WireGuard: AllowedIPs એ રૂટ ટેબલ છે

ક્લાયન્ટ પર, AllowedIPs એ ગંતવ્યોની યાદી આપે છે જે ટનલમાં પ્રવેશી શકે છે, અને wg-quick દરેક એન્ટ્રીને સામાન્ય રૂટ બનાવે છે. તેથી આ કાર્યનો ક્લાયન્ટ અડધો ભાગ એક લીટી છે.

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16

હવે તે જ ક્લાયન્ટ માટે સર્વરની એન્ટ્રીની સરખામણી કરો. તે વર્ણવે છે કે સર્વર ક્લાયન્ટને શું મોકલશે, જે સામાન્ય રીતે ક્લાયન્ટનું ટનલ સરનામું હોય છે, ખાનગી સબનેટ નહીં.

[Peer]
PublicKey = ...
AllowedIPs = 10.99.0.2/32

આ બેને અદલાબદલી કરવી એ સૌથી વધુ જોવા મળતી ભૂલ છે. સર્વરના peer વિભાગ હેઠળ 10.20.0.0/16 મૂકવું એમ કહે છે કે આખું સબનેટ તે ક્લાયન્ટ પાછળ રહે છે, જે સાઇટ-થી-સાઇટ દાવો છે, પરવાનગી નહીં. કોઈ પણ peer ના AllowedIPs સાથે ન મળતા પેકેટ શાંતિથી ફેંકાય છે, તેથી ખોટી એન્ટ્રી બરાબર ફાયરવોલ સમસ્યા જેવી લાગે છે.

જો તમે રૂટ જાતે સંભાળો છો, તો [Interface] હેઠળ Table = off સેટ કરો અને ઇચ્છિત રૂટ ઉમેરો. પછી આપમેળે કંઈ ઉમેરાતું નથી, તેથી રૂટ તે વસ્તુમાં રહેવો જોઈએ જે ઇન્ટરફેસ ઉપર લાવે છે.

OpenVPN: રૂટ ધકેલો, પછી ખાતરી કરો કે તે પહોંચે છે

સામાન્ય સર્વર પર ફેરફાર સર્વર કન્ફિગમાં ક્લાયન્ટ પૂલની બાજુમાં એક નિર્દેશ છે.

push "route 10.20.0.0 255.255.0.0"

ક્લાયન્ટ કનેક્ટ થતાં તે ઉમેરે છે. નિષ્ફળતાની સ્થિતિ ત્યારે દેખાય છે જ્યારે એ જ પ્રોફાઇલ redirect-gateway પણ ધકેલે, અથવા કોઈએ પહેલેથી route-nopull ઉમેર્યું હોય: પહેલું સત્રને પૂર્ણ ટનલ બનાવે છે અને બીજું તમારા સહિત દરેક ધકેલાયેલા રૂટને ફેંકી દે છે.

પૂર્ણ-ટનલ સર્વર સામે સાંકડું વર્તન જોઈતું હોય તેવા ક્લાયન્ટે ફક્ત એ ભાગો અવગણવા જોઈએ જે તેને નથી જોઈતા. OpenVPN 2.4 અને પછીના સંસ્કરણોમાં, pull-filter બરાબર એના માટે જ છે.

pull-filter ignore "redirect-gateway"
route 10.20.0.0 255.255.0.0

સરનામાં કુટુંબો અલગ રાખો: ધકેલાયેલો IPv4 રૂટ IPv6 માં રિઝોલ્વ થતી આંતરિક સેવા માટે કંઈ કરતો નથી, અને તે સેવા ટનલ પર નિષ્ફળ જાય છે જ્યારે બાકીનું બધું ઠીક લાગે છે.

જ્યારે ખાનગી સબનેટ VPN સર્વર પર ન હોય પણ બીજા ક્લાયન્ટ પાછળ હોય, ત્યારે સર્વરને જણાવવું પડે. client-config-dir દ્વારા દરેક ક્લાયન્ટ માટે iroute 10.20.0.0 255.255.0.0 ધરાવતી ફાઇલ ઉમેરો, સાથે મેળ ખાતો route જેથી બીજા ક્લાયન્ટ માર્ગ શીખે. iroute વિના તે ચોક્કસ ટનલ દ્વારા તે પ્રીફિક્સ મોકલવાનું સર્વર પાસે કોઈ કારણ નથી.

IPsec: ટ્રાફિક સિલેક્ટરોએ સંમત થવું પડે

IPsec સાથે ધકેલવા માટે કોઈ રૂટ નથી. બંને છેડા વાટાઘાટ કરે છે કે કયા સરનામાં ટનલની અંદર રહે છે, અને સંમત સિલેક્ટરની બહારનો ટ્રાફિક ન તો એન્ક્રિપ્ટ થાય છે ન તેમાંથી મોકલાય છે. strongSwan ક્લાયન્ટ પર સિલેક્ટર સ્પષ્ટ હોય છે.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

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

Windows પર બિલ્ટ-ઇન ક્લાયન્ટ એ જ નિર્ણયને બે સેટિંગ્સ પાછળ છુપાવે છે. ટનલ વિભાજન ચાલુ હોવું જોઈએ, અને પ્રીફિક્સ પ્રોફાઇલ સાથે નોંધાયેલું હોવું જોઈએ.

Set-VpnConnection -Name Office -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.20.0.0/16

પ્રીફિક્સની નોંધણી જ તેને ફરી કનેક્ટ થવા પર ટકી રહેવા દે છે, જે હાથે ઉમેરેલો રૂટ કરતો નથી.

એન્ડપોઇન્ટ અને DNS ને નિર્ણયની બહાર રાખો

VPN એન્ડપોઇન્ટ ટનલ વિના પહોંચી શકાય તેવું રહેવું જોઈએ, નહીં તો ટનલ પોતાનામાં જ ધરાશાયી થાય છે. જ્યારે ફક્ત 10.20.0.0/16 રૂટ થાય છે ત્યારે તે આપોઆપ થાય છે, કારણ કે એન્ડપોઇન્ટ જાહેર સરનામું છે. પૂર્ણ-ટનલ પ્રોફાઇલમાં એમ નથી, અને ટનલ ઉપર આવતાં પહેલાં ક્લાયન્ટને એન્ડપોઇન્ટ તરફ સ્પષ્ટ હોસ્ટ રૂટની જરૂર છે.

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

ચકાસો, પછી રીબૂટ કરો અને ફરી ચકાસો

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

ip route get 10.20.5.7
curl -sS http://10.20.5.7/health
curl -sS https://ifconfig.me

પહેલી લીટી ઇન્ટરફેસનું નામ આપે છે. જો તે તમારા ભૌતિક ઇન્ટરફેસનું નામ આપે, તો રૂટ ક્યારેય પહોંચ્યો જ નહીં. Windows પર Find-NetRoute -RemoteIPAddress 10.20.5.7 એ જ પ્રશ્નનો જવાબ આપે છે, અને છેલ્લું પરીક્ષણ હજી તમારું સામાન્ય સરનામું બતાવવું જોઈએ, VPN સર્વરનું નહીં.

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

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