pfSense VPN સર્વર અને ક્લાયન્ટ તરીકે: બે માર્ગ, એક રાઉટર

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

કોઈપણ સેટિંગને અડકતા પહેલાં બંને ભૂમિકાઓને નામ આપો

દરેક ઇન્સ્ટન્સ માટે ચાર તથ્યો લખો: તેનો દૂરનો સાથી, તેની પ્રમાણીકરણ સામગ્રી, તે વહેંચતો સરનામા-સમૂહ, અને તેની પાછળના નેટવર્ક. બંને ઇન્સ્ટન્સ ઉપકરણ પર અલગ ઑબ્જેક્ટ છે અને તમારી નોંધમાં પણ અલગ રહેવા જોઈએ. પછીથી આવતું લગભગ દરેક ગૂંચવણભર્યું લક્ષણ તેમના મૂલ્યો ભેળવવાથી આવે છે, અને એક જ નોંધ-સમૂહ વહેંચતા બે ઇન્સ્ટન્સ એ જ રીત છે જેમાં ખોટો સમૂહ ખોટા ક્ષેત્રમાં પહોંચે છે.

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

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

સર્વરના જવાબો WAN માર્ગ પર જ રાખો

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

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

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

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

બહાર જતા ટનલને તેનું પોતાનું અંતિમ બિંદુ ખાવા ન દો

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

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

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

કયા વપરાશકર્તાઓને એગ્ઝિટ મળશે તે પસંદ કરો

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

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

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

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

એગ્ઝિટ નિષ્ફળ જાય ત્યારે શું થશે તે નક્કી કરો

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

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

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

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