Raspberry Pi પર VPN ગેટવે: એક નેટવર્ક પોર્ટ કે અલગ ક્લાયન્ટ પોર્ટ
એક Pi પોર્ટ પસંદ કરેલા ક્લાયન્ટની સેવા કરી શકે, અથવા બીજો પોર્ટ ઉપકરણોને અંદર પૂરી શકે. અલગીકરણ, ફોલબેક નીતિ અને DNS કોનું છે તેના આધારે લેઆઉટ પસંદ કરો.
તમારી પાસે એક Pi, એક કામ કરતું બહાર જતું VPN પ્રોફાઇલ અને બે ઉપકરણો છે જે તેના દ્વારા ઇન્ટરનેટ સુધી પહોંચવા જોઈએ. આખું બાંધકામ નક્કી કરતો પ્રશ્ન એ નથી કે કઈ માર્ગદર્શિકા અનુસરવી, પણ એ છે કે તમને કેટલું અલગીકરણ જોઈએ. એક પોર્ટ Pi ને તે ઉપકરણોની બાજુમાં રાઉટરના LAN પર બેસવા અને વધારાના ગેટવે તરીકે કામ કરવા દે છે; બીજો પોર્ટ તમને તેમને એવા સેગમેન્ટમાં મૂકવા દે છે જ્યાં Pi એકમાત્ર બહાર નીકળવાનો રસ્તો છે. આ પસંદગી પછીનું બધું — DHCP, ફાયરવોલનો વ્યાપ, DNS, વિક્ષેપનો કિસ્સો — તેમાંથી જ નીકળે છે.
બે લેઆઉટ ખરેખર શેમાં અલગ પડે છે
બંને ડિઝાઇન રૂટ કરે છે. ફરક એ છે કે બીજું કોણ વાયર પર ઊભું છે અને જ્યારે તમારી નીતિ ખોટી હોય ત્યારે શું થાય છે.
| Layout A: Pi on the ISP LAN | Layout B: dedicated client port | |
|---|---|---|
| Cabling | One Ethernet port, existing switch port | Two interfaces: uplink plus a separate LAN port |
| Can a client bypass the Pi? | Yes, by using the ISP router as its gateway | No, unless the device has another radio or link |
| Who hands out addresses | The ISP router, with a per-client setting or a DHCP option | The Pi, on its own LAN interface only |
| Blast radius of a mistake | Any LAN host, if a rule is too broad | The attached segment |
| Good fit for | One laptop, a console, a temporary test client | Appliances, always-on boxes, untrusted devices |
અલગીકરણ એ ખરેખર ધરી છે. લેઆઉટ A સલાહકારક છે: DHCP દ્વારા આપવામાં આવેલા ગેટવેને અવગણીને રાઉટર પસંદ કરતું ઉપકરણ હજી પણ કામ કરે છે, પણ એન્ક્રિપ્શન વગર. લેઆઉટ B ટોપોલોજી દ્વારા લાગુ થાય છે, કારણ કે પસંદ કરવા માટે બીજું કોઈ આગલું પગલું નથી.
લેઆઉટ A: હાલના LAN પર Pi વધારાના ગેટવે તરીકે
ધારો કે ISP રાઉટર 192.168.50.1 છે, Pi 192.168.50.2 છે, અને પસંદ કરેલા ક્લાયન્ટ Pi તરફ નિર્દેશ કરે છે. મહત્વનું એ છે કે બે અલગ પેકેટ પ્રવાહ એક જ કેબલ વહેંચે છે. ક્લાયન્ટનું આંતરિક પેકેટ Pi પર પહોંચે છે અને ટનલ દ્વારા બહાર જવું જોઈએ; Pi નું પોતાનું એન્ક્રિપ્ટેડ પેકેટ VPN સાથી તરફ એ જ કેબલ દ્વારા રાઉટર તરફ જવું જોઈએ. તેઓ એક જ ઇન્ટરફેસ પર વિરુદ્ધ દિશામાં મુસાફરી કરે છે અને અલગ સારવારની જરૂર છે.
Pi ને તેનું સરનામું સ્થાપિત નેટવર્ક મેનેજર દ્વારા આપો, જૂની ઇન્ટરફેસ-ફાઇલ રેસીપી દ્વારા નહીં જે ઉપકરણ માટે તેની સાથે ઝઘડે છે. પછી ક્લાયન્ટ સેટ કરો: એક ઉપકરણ પર સ્થિર ગેટવે, અથવા DHCP રિઝર્વેશન જે 192.168.50.2 ને રાઉટર તરીકે આપે છે. બે ઉપકરણો માટે રાઉટરનું આખું DHCP ક્ષેત્ર બદલશો નહીં, અને એ ન માનો કે ક્લાયન્ટ આ વિકલ્પનું પાલન કરે છે — તેને ચકાસો.
નબળાઈ માળખાકીય છે, સુધારી શકાય તેવી નથી. તે સેગમેન્ટનો કોઈપણ ક્લાયન્ટ 192.168.50.1 તરફ નિર્દેશ કરીને સ્પષ્ટ રીતે બહાર જઈ શકે છે, અને બીજું ઇન્ટરફેસ કે સેલ્યુલર રેડિયો ધરાવતું ઉપકરણ તમારો અમલીકરણ માર્ગ સંપૂર્ણપણે છોડી દે છે. જો તે વાક્ય સંબંધિત ઉપકરણ માટે અસ્વીકાર્ય હોય, તો તમારી પાસે જવાબ પહેલેથી છે: લેઆઉટ B વાપરો.
લેઆઉટ B: અલગ પોર્ટ ઉપકરણોને અંદર પૂરી રાખે છે
અહીં Pi અપલિંક પર ગેટવે 192.168.50.1 સાથે 192.168.50.2 રાખે છે, અને જોડાયેલા ઉપકરણો માટે બીજા ઇન્ટરફેસ પર 10.20.0.1/24 લે છે. હવે Pi બે નેટવર્ક ધરાવતું રાઉટર છે, અને જોડાયેલા સેગમેન્ટમાં બરાબર એક જ બહાર નીકળવાનો રસ્તો છે.
પ્રતિબદ્ધ થવા પહેલાં શ્રેણીને બીજા બધા સામે ચકાસો: ટનલનું પોતાનું સબનેટ, બીજા સાઇટ-થી-સાઇટ પ્રીફિક્સ, અને VPN દ્વારા પહોંચી શકાય તેવું બધું. દૂરના LAN સાથે અથડાતું 10.20.0.0/24 એ અડધું ચાલતું પરિણામ આપે છે જેનું નિદાન એક સાંજ લે છે. જો બીજો પોર્ટ USB એડેપ્ટર હોય, તો ખાતરી કરો કે તે સમર્થિત છે અને નેટવર્ક મેનેજરમાં તેનું નામ પિન કરો જેથી રીબૂટ પછીની ફેરગોઠવણ તમારું LAN સરનામું ખસેડે નહીં.
DHCP સાંભળનારને ફક્ત તે જ ઇન્ટરફેસ પર ચલાવો. અપલિંક પર જવાબ આપતું સર્વર ISP રાઉટર સાથે સ્પર્ધા કરે છે અને તમારા સેગમેન્ટનાં સરનામાં બાકીના ઘરને આપે છે. તેને LAN ઇન્ટરફેસ સાથે બાંધો, જાહેર કરેલી શ્રેણી સુધી મર્યાદિત કરો, અને Pi નું પોતાનું સરનામું પૂલની બહાર રાખો.
ફોરવર્ડિંગ, અનુવાદ અને નિષ્ફળતા પર બંધ થવાનો નિયમ
ચાર વસ્તુઓને ઘણી વાર એક તરીકે વર્ણવવામાં આવે છે અને તે એક નથી. ફોરવર્ડિંગ ચાલુ કરવું (net.ipv4.ip_forward=1) કર્નલને ફક્ત એ કહે છે કે તે ઇન્ટરફેસ વચ્ચે પેકેટ ખસેડી શકે છે; તે પોતે કંઈ પણ પરવાનગી આપતું નથી અને કોઈ માર્ગની બાંયધરી આપતું નથી. એગ્રેસ પસંદ કરવો એ રૂટિંગ નિર્ણય છે. પેકેટને પરવાનગી આપવી એ forward શૃંખલામાં નીતિ નિર્ણય છે. તેનું સ્રોત ફરીથી લખવું એ postrouting નિર્ણય છે. ફક્ત પહેલું કરતું બાંધકામ એવું Pi આપે છે જે ક્લાયન્ટ ટ્રાફિકને આનંદથી અપલિંક દ્વારા બહાર ફોરવર્ડ કરે છે.
પરવાનગીને તમે ધારેલા સ્રોતો અને ટ્રાફિક જે ઇન્ટરફેસ વાપરવો જોઈએ તે સુધી મર્યાદિત કરો, અને પરત માર્ગ તથા Pi ને જરૂરી ગંતવ્યોનો સમાવેશ કરો. પછી જો પ્રદાતા તમારું LAN પ્રીફિક્સ તમારી તરફ પાછું રૂટ ન કરે તો ટનલ એગ્રેસ પર અનુવાદ કરો. nftables મેન્યુઅલ ફોરવર્ડિંગ, સ્થાનિક આઉટપુટ અને સ્રોત-અનુવાદને અલગ ક્રિયાઓ તરીકે ગણે છે, જે અહીં યોગ્ય વિચાર-મોડેલ છે.
સામાન્ય નિષ્ફળતા ભૌતિક ઇન્ટરફેસ પર વિશાળ masquerade નિયમ છે. પછી ટ્રાફિક ISP માર્ગ દ્વારા ઇન્ટરનેટ સુધી પહોંચે છે, જ્યારે ક્લાયન્ટની બાજુથી તે કામ કરતા VPN જેવું બરાબર દેખાય છે. તે કંઈ પણ સાબિત કરતું નથી. અનુવાદને જાહેર કરેલા એગ્રેસ સાથે બંધાયેલો રાખો, અને તમારા નિયમો હોસ્ટ પહેલેથી વાપરતા ફાયરવોલમાં જ રાખો, વિભાજિત postrouting શૃંખલાને ખાલી કરતો સ્પર્ધાત્મક નિયમસેટ ઉમેરવાને બદલે.
પછી ટનલની ગેરહાજરી સંભાળો. વિશાળ ડિફોલ્ટ રૂટ સ્થાપિત કરતી ક્લાયન્ટ પ્રોફાઇલનો અર્થ એ પણ છે કે જ્યારે ટનલ પડે ત્યારે સામાન્ય ડિફોલ્ટ પાછો આવી શકે છે અને ક્લાયન્ટ ટ્રાફિક શાંતિથી અપલિંક તરફ પાછો ફરે છે. જ્યાં સ્પષ્ટ ટેક્સ્ટ તરફ પાછા જવું સ્વીકાર્ય નથી, ત્યાં forward નીતિએ ક્લાયન્ટ-થી-અપલિંક ટ્રાફિકને સ્પષ્ટપણે નકારવો જોઈએ, તે સ્થિતિમાં જ્યારે VPN રૂટ ગયો હોય. તેને નકાર નિયમ તરીકે લખો, ધારણા તરીકે નહીં. Pi નું પોતાનું એન્ક્રિપ્ટેડ પરિવહન VPN સાથી તરફ અલગ local-output પ્રવાહ છે અને પરવાનગી મળેલી રહેવું જોઈએ, નહીં તો ટનલ ક્યારેય પાછી આવી શકશે નહીં.
DNS અને IPv6 ને તેમનો પોતાનો જવાબ જોઈએ
જો ક્લાયન્ટ Pi ને રિઝોલ્વર તરીકે વાપરે, તો તેઓ સ્થાનિક સાંભળનાર સુધી પહોંચે છે અને Pi નવી ક્વેરી શરૂ કરે છે. તે ઉપરની ક્વેરી Pi ના પોતાના માર્ગને અનુસરે છે, તમે ક્લાયન્ટ માટે લખેલા forward નિયમને નહીં, તેથી ફક્ત ટનલ દ્વારા જતો ક્લાયન્ટ માર્ગ અને સીધું બહાર જતું રિઝોલ્વર — તે કોઈ પણ ભૂલ સંદેશ વગરનું લીક છે. જાણી જોઈને નક્કી કરો: ટનલ દ્વારા પહોંચાય તેવું રિઝોલ્વર, અથવા સ્થાનિક જેને તમે સીધું સ્વીકારો છો, અને Pi ની પોતાની આઉટપુટ નીતિને તે નિર્ણય સાથે મેળવો.
IPv6 ફરીથી અલગ કિસ્સો છે. IPv4 માટેનો forward નિયમ IPv6 વિશે કંઈ પણ મર્યાદિત કરતો નથી, અને અપલિંક પરના રાઉટર જાહેરાતો Pi ને, અને તેના દ્વારા જોડાયેલા સેગમેન્ટને, તમારી નીતિને ટાળતું બીજું ડિફોલ્ટ આપી શકે છે. કાં તો તે જ સિદ્ધાંત પર IPv6 ને તેનો પોતાનો સુરક્ષિત માર્ગ આપો, અથવા ક્લાયન્ટ સેગમેન્ટ પર તેને સ્પષ્ટપણે મર્યાદિત કરો અને એમ કહો.
વિશ્વાસ કરવા પહેલાં સીમા ચકાસો
ડિઝાઇનને ફક્ત ચાર અલગ તપાસ પછી સ્વીકારો, કારણ કે લલચાવતી એકમાત્ર કસોટી — એક ક્લાયન્ટ પર બ્રાઉઝર ખોલવું — ઘણી તૂટેલી સ્થિતિઓમાં પાસ થાય છે.
ખાતરી કરો કે એક વાસ્તવિક ક્લાયન્ટ ટનલ દ્વારા ઇન્ટરનેટ સુધી પહોંચે છે, પછી ખાતરી કરો કે એ જ ક્લાયન્ટ ટનલ બંધ હોય ત્યારે ઇન્ટરનેટ સુધી પહોંચી શકતું નથી. ખાતરી કરો કે DNS રિઝોલ્યુશન કામ કરે છે અને ક્વેરી તમે ધાર્યું ત્યાંથી બહાર જાય છે. ખાતરી કરો કે ટનલ રીસ્ટાર્ટ પછી પણ Pi નું પોતાનું પરિવહન કામ કરે છે, અને પુનઃપ્રાપ્તિ માટે મશીન રીબૂટની જરૂર નથી. અંતે, તમે પસંદ ન કરેલું ઉપકરણ ચકાસો: લેઆઉટ A હેઠળ તે સામાન્ય રીતે કામ ચાલુ રાખવું જોઈએ, અને લેઆઉટ B હેઠળ તે તે સેગમેન્ટમાં જ હોવું જ ન જોઈએ.
- બે પોર્ટ અને નકાર નિયમ અમલ આપે છે; એક પોર્ટ અને DHCP વિકલ્પ સલાહ આપે છે.
- ખોટા ઇન્ટરફેસ પર અનુવાદ સફળતા જેવું લાગે છે અને તે સફળતા નથી.
- Pi નો પોતાનો ટ્રાફિક, DNS અને IPv6, દરેકને નિર્ણય જોઈએ, અનુમાન નહીં.