pfSense OpenVPN: બીજા રાઉટર પાછળના નેટવર્ક સુધી પહોંચવું

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

નિયમ બદલતા પહેલાં એક પેકેટને એ ત્રણ નિર્ણયોમાંથી પસાર કરો, કારણ કે દરેક માલિક પાસે અલગ નિયંત્રણ અને અલગ નિષ્ફળતા મોડ હોય છે.

એક પેકેટ, ત્રણ રૂટિંગ નિર્ણય

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

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

ક્લાયન્ટને પ્રીફિક્સ આપો, અનુમાન નહીં

IPv4 ટનલ નેટવર્ક /30 કરતાં મોટું હોય તેવા pfSense SSL/TLS સર્વર પર, IPv4 Local network(s) ફીલ્ડ જોડાતી વખતે ક્લાયન્ટને રૂટ વિતરિત કરે છે. ક્લાયન્ટ પોતે એક બનાવશે તેવી આશા રાખવાને બદલે નીચેનું પ્રીફિક્સ ત્યાં ઉમેરો. પછી જોડાયા પછી ક્લાયન્ટનું વાસ્તવિક ટેબલ વાંચો, કારણ કે route-nopull ધરાવતી પ્રોફાઇલ અથવા રૂટ ફિલ્ટર સર્વરે મોકલેલું અવગણી શકે છે. સર્વર સંપૂર્ણ સાચું હોઈ શકે જ્યારે ક્લાયન્ટ કંઈ જ ઇન્સ્ટોલ ન કરે.

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

pfSense ને આંતરિક રાઉટર તરફ નિર્દેશ કરો

pfSense માં સ્થિર રૂટને વ્યાખ્યાયિત અને પહોંચી શકાય તેવા ગેટવેની જરૂર હોય છે, અને તે ગેટવે માટે પસંદ કરેલો ઇન્ટરફેસ એ જ હોવો જોઈએ જે ખરેખર ત્યાં પહોંચે છે, જેમ Netgate ની સ્થિર-રૂટ માર્ગદર્શિકા વર્ણવે છે. ઉદાહરણરૂપ ગોઠવણીમાં ટ્રાન્ઝિટ લિંક ફાયરવોલ પર 192.168.77.1 અને આંતરિક રાઉટર પર 192.168.77.2 છે, અને સેવા નેટવર્ક તેની પાછળ 172.16.30.0/25 પર છે. પછી રૂટ પ્રીફિક્સ અને આગળના હોપનું નામ આપે છે, સેવાના સરનામાનું નહીં. દૂરના નેટવર્કનું સરનામું ગેટવે તરીકે વાપરવું એ એવો રૂટ બનાવવાની સામાન્ય રીત છે જે સાચો દેખાય અને ક્યાંય ફોરવર્ડ ન કરે.

ઇન્ટરફેસને નામ આપવાથી તેની પાછળના નેટવર્કનું વર્ણન થતું નથી. સ્થિર રૂટ એ વર્ણન છે.

દૂરના પક્ષે પૂલ જાણવો જોઈએ

નીચેના રાઉટરને પૂલ માટે પરત રૂટની જરૂર છે, આ ઉદાહરણમાં 192.168.77.1 દ્વારા 10.55.0.0/24, સિવાય કે ડિફોલ્ટ રૂટ અથવા ગતિશીલ પ્રોટોકોલ પહેલેથી જ એક પૂરો પાડે. સેવા હોસ્ટનો પોતાનો ગેટવે તે રાઉટર તરફ દોરી જવો જોઈએ, જે સામાન્ય રીતે સાચું હોય છે જ્યારે રાઉટર તેનો ડિફોલ્ટ ગેટવે હોય અને ખોટું હોય જ્યારે હોસ્ટ જાતે ગોઠવાયેલો હોય. ફાયરવોલ પરનું નીતિ-આધારિત રૂટિંગ ચોક્કસ ટ્રાફિક માટે ટેબલને ઓવરરાઇડ પણ કરી શકે છે, તેથી રૂટ ખોટો છે તેવું તારણ કાઢતા પહેલાં તપાસો કે કોઈ નિયમ બીજો ગેટવે પસંદ કરે છે કે નહીં.

આ ડિઝાઇન માટે કોઈ અનુવાદની જરૂર નથી, અને ક્લાયન્ટનું સ્રોત સરનામું દૃશ્યમાન રાખવાથી નીચેના નેટવર્કને તેની પોતાની નીતિ લાગુ કરવાની મંજૂરી મળે છે.

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

ત્રણ માલિકોની યોજના મંજૂર કરેલી એપ્લિકેશનની સાથે સાચવો, જેથી આગલો પ્રશાસક રસ્તો ફરીથી શોધવાને બદલે તેને પુનઃનિર્માણ કરી શકે.