મલ્ટી-રાઉટર Pi VPN: દરેક રૂટને તે ઉપકરણ પર મૂકો જે નિર્ણય લે છે
ડાઉનસ્ટ્રીમ રાઉટર બીજું ક્લાયન્ટ સબનેટ ઉમેરે છે, અને ચાર ઉપકરણોમાંથી દરેક એક નિર્ણય ધરાવે છે. રૂટ મૂકો, સ્રોત તપાસો, પછી વાસ્તવિક ક્લાયન્ટથી પરીક્ષણ કરો.
Piની પાછળ Wi-Fi બોક્સ મૂકવાથી એક રાઉટિંગ નિર્ણય ચાર બની જાય છે, અને જ્યારે ચારેય એક જ ઉપકરણ પર લેવાય ત્યારે યોજના તૂટી પડે છે. પ્રથમ પ્રશ્ન એ નથી કે કયો રૂટ ઉમેરવો. પ્રશ્ન એ છે કે નવું બોક્સ બ્રિજ કરે છે કે રાઉટ કરે છે, કારણ કે એ જવાબ નક્કી કરે છે કે કેટલા સબનેટ અસ્તિત્વમાં છે અને કયા ઉપકરણોએ તેમના વિશે જાણવું પડશે. પહેલા જોડાણ મોડેલ પસંદ કરો; દરેક રૂટ તેમાંથી અનુસરે છે.
બ્રિજ કે રાઉટ: જે પસંદગી સંખ્યા નક્કી કરે છે
બ્રિજ નવા ક્લાયન્ટને એ જ સબનેટ પર મૂકે છે જે Pi પહેલેથી સેવા આપે છે. એક સબનેટ, એક DHCP સત્તા, અને રાઉટ કરવા માટે કોઈ હેન્ડઓફ નહીં. આ સરળ ગોઠવણી છે અને જ્યારે અલગ ક્લાયન્ટ નેટવર્ક ક્યારેય જરૂરી ન હતું ત્યારે યોગ્ય છે. રાઉટેડ લિંક અલગ રચના છે: બોક્સ પોતાનું સબનેટ રાખે છે, અને એ પ્રીફિક્સ ટ્રાફિક જ્યાં જાય ત્યાં બધે લઈ જવું પડે છે.
આ યોજનાનો બાકીનો ભાગ ડાઉનસ્ટ્રીમ રાઉટર રાખે છે અને ક્લાયન્ટ સ્રોત સરનામાં સાચવે છે. લક્ષ્ય એક ખાનગી VPN નેટવર્ક છે, સંપૂર્ણ ઇન્ટરનેટ એક્ઝિટ નહીં. સરનામાં પહેલાં મોડેલ લખો, કારણ કે નીચેની યાદી ફક્ત રાઉટેડ જોડાણનું ઉદાહરણ છે.
client subnet 10.41.0.0/24
client gateway 10.41.0.1
router-to-Pi link 192.168.71.2
Pi on that link 192.168.71.1
private target 10.72.9.0/24કોણ શું નક્કી કરે છે
| Decision owner | Entry that encodes the decision | Failure when the entry is missing |
|---|---|---|
| Pi VPN host | Return route for 10.41.0.0/24 via 192.168.71.2, and a tunnel route for 10.72.9.0/24 | Replies to downstream clients die at the Pi |
| Owner of the remote network | A path for 10.41.0.0/24 over the permitted tunnel | Replies stop at the first unaware hop |
| LAN router behind the Pi | Specific route for 10.72.9.0/24 via 192.168.71.1, or a suitable default | Clients never send private traffic to the Pi |
| Client machine | Default via 10.41.0.1, or a specific entry for 10.72.9.0/24 | The private network is unreachable from the client |
દરેક ઉપકરણ એક નિર્ણય લે છે, અને કોઈ પણ બીજાનો નિર્ણય તેના વતી લઈ શકતું નથી. Piને એક નહીં, બે એન્ટ્રીની જરૂર છે, અને પાછા ફરવાનો માર્ગ એ છે જે લોકો ભૂલી જાય છે. ફોરવર્ડ કરેલ ટ્રાફિક ખાનગી નેટવર્ક સુધી યોગ્ય રીતે પહોંચે છે અને પછી પાછા ફરતા માર્ગે મરી જાય છે, કારણ કે 10.41.0.0/24 ક્યાં રહે છે તે Pi જાણતું નથી. તે ફાયરવોલ સમસ્યા જેવું લાગે છે અને વાસ્તવમાં ખૂટતો રૂટ છે.
દૂરની બાજુને પણ પોતાનો રૂટ જોઈએ. જો દૂરના છેડેની સેવાને ખબર ન હોય કે 10.41.0.0/24 તમારા ટનલ દ્વારા પહોંચી શકાય છે, તો જવાબો પહેલા જ હોપ પર અટકી જાય છે જેની પાસે જવાબ નથી. પેકેટ ફિલ્ટર વાંચતા પહેલાં બંને દિશાઓ ઉમેરો.
આગળના હોપ જોડાણમાંથી આવે છે
આગળનો હોપ એવા નેટવર્ક પરનું સરનામું હોવું જોઈએ જ્યાં ઉપકરણ ખરેખર પહોંચી શકે. VPN પીઅરનું જાહેર સરનામું ખાનગી સબનેટ માટે આગળનો હોપ નથી, અને દૂરનું સેવા નેટવર્ક કોઈ પણ રીતે આગળનો હોપ નથી. અપહોંચ ગેટવે તરફનો રૂટ યાદીમાં સાચો દેખાય છે અને દરેક પેકેટ ફેંકી દે છે. ગંતવ્યને દોષ આપતા પહેલાં ગેટવે જવાબ આપે છે તે તપાસો.
Piની બહારની VPN પીઅરને તેના પોતાના અંડરલે રૂટ દ્વારા પહોંચી શકાય તેમ રાખો. તે એન્ટ્રી પેલોડ રૂટથી અલગ છે, અને તેમને ભેળવવાથી એવું ટનલ મળે છે જે માર્ગ બદલાયા પછી ફરી સ્થપાઈ શકતું નથી.
સ્ટેટિક રૂટનું દસ્તાવેજીકરણ ગંતવ્ય અને ગેટવે વચ્ચેનો તફાવત સ્પષ્ટ કરે છે, જોકે દરેક પ્લેટફોર્મ તેના મેનૂને અલગ રીતે નામ આપે છે. અન્ય વિક્રેતાની સ્ક્રીન કોપી કરવાને બદલે તમારી સામેના ઉપકરણનું દસ્તાવેજીકરણ વાંચો. નીચેની આદેશો Linux પર એન્ટ્રીનો આકાર બતાવે છે.
# on the Pi
ip route add 10.41.0.0/24 via 192.168.71.2
ip route add 10.72.9.0/24 dev tun0
# on the downstream router
ip route add 10.72.9.0/24 via 192.168.71.1અનુવાદ સ્રોત સાથે શું કરે છે
જો ડાઉનસ્ટ્રીમ રાઉટર પહેલેથી તેના ક્લાયન્ટને ટ્રાન્ઝિટ સરનામાંમાં અનુવાદિત કરે છે, તો Pi દરેક ક્લાયન્ટના પોતાના સરનામાને બદલે એક અનુવાદિત સ્રોત જુએ છે. આ ઉપરના સ્રોત-સાચવતી રચનાથી અલગ છે. તે સ્રોત-આધારિત નીતિ, લોગિંગ અને કઈ બાજુ જોડાણો શરૂ કરી શકે તે બદલે છે. બંને રચનાઓ કામ કરે છે; તે અલગ પ્રશ્નોના જવાબ આપે છે.
જ્યારે અપસ્ટ્રીમ VPN સેવા ક્લાયન્ટ પ્રીફિક્સને પાછું રાઉટ કરવાનો ઇનકાર કરે છે, ત્યારે Piના ટનલ ઇગ્રેસ પર સાંકડો અનુવાદ કાયદેસર ઉપાય હોઈ શકે છે. તે એ સાબિતી નથી કે ખૂટતો રૂટ બિનજરૂરી હતો. રેકોર્ડ કરો કે દૂરનું નેટવર્ક ખરેખર કયું સરનામું જુએ છે અને કયો પરત માર્ગ પરિણમે છે.
રૂટ પસંદગી, ફોરવર્ડિંગ પરવાનગી અને સ્રોત અનુવાદ ત્રણ અલગ કામ રહે છે. એક વાયર્ડ ક્લાયન્ટ કામ કરે છે માટે વહેંચાયેલ NAT ચેઇન ફ્લશ કરવી અથવા દરેક ઇન્ટરફેસને મંજૂરી આપવી એ જ રીતે કામ કરતું પરીક્ષણ ખુલ્લું ફોરવર્ડર બને છે.
ક્લાયન્ટ મશીનથી સાબિત કરો
ડાઉનસ્ટ્રીમ LAN પરની મશીનથી વિનંતી મોકલો, પછી તેના સ્રોતને બહાર અને પાછા અનુસરો. Pi દ્વારા મોકલાયેલ ping ક્યારેય ડાઉનસ્ટ્રીમ પરત માર્ગનો ઉપયોગ કરતું નથી, તેથી સફળ ping દેખાય તેના કરતાં ઓછું સાબિત કરે છે. Piના પોતાના LAN પરના વાયર્ડ ક્લાયન્ટથી બીજું પરીક્ષણ ઉમેરો જેથી બે માર્ગોની સરખામણી થઈ શકે. કોઈપણ ઉપકરણ રીબૂટ કર્યા પછી બંનેનું પુનરાવર્તન કરો.
હાથે ઉમેરાયેલા રૂટ અને ક્યારેય સાચવ્યા ન હોય તેવા અનુવાદ સાથે અદૃશ્ય થાય છે. પછી જોડી અધૂરા કામને બદલે નવી ખામી જેવી દેખાય છે.
જોડાણ મોડેલને રૂટ, મંજૂર ખાનગી સેવા અને કોઈપણ અનુવાદ સાથે એક નોંધમાં સાચવો. તે નોંધ જ આગળની વ્યક્તિને વાયરલેસ સ્થાનને રાઉટિંગ નીતિના પ્રશ્ન તરીકે ગણવાથી રોકે છે.