શું રોમિંગ VPN ક્લાયન્ટ ઓફિસ માટે સેવા હોસ્ટ કરી શકે?

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

ડાયલ-ઇન દિશા સેવાની દિશા વિશે કંઈ કહેતી નથી

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

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

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

પોર્ટ ખોલતા પહેલાં પ્રતિસાદ માર્ગ અનુસરો

માર્ગના ત્રણ ભાગ છે: ગેટવે પરનો રૂટ જે ક્લાયન્ટના આંતરિક સરનામા તરફ નિર્દેશ કરે છે, ચોક્કસ કૉલરને પરવાનગી આપતી નીતિ, અને લક્ષ્ય પર સાંભળતી સેવા. દરેક ભાગ અલગ રીતે નિષ્ફળ જાય છે, તેથી «VPN ચાલુ છે» લગભગ કંઈ કહેતું નથી.

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

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

નામ અને સરનામાં ડિઝાઇનના નિર્ણયો છે

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

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

VPN ઓળખનો માલિક જે હોય તેની સાથે નામ પર સંમત થાઓ, જેથી રેકોર્ડ, સરનામા ફાળવણી અને ઍક્સેસ નીતિ ત્રણ અલગ ટિકિટમાં નહીં પણ સાથે બદલાય.

સભ્યપદ નહીં, સેવાનું પરીક્ષણ કરો

લક્ષ્યથી ખાતરી કરો કે શું સાંભળે છે અને કયા સરનામા પર, પછી પરત માર્ગ વિશે ગેટવેનું દૃશ્ય ખાતરી કરો:

$ ss -ltnp | grep 8080
LISTEN 0 128 10.80.0.23:8080 0.0.0.0:*
$ ip -4 addr show tun0 | grep inet
inet 10.80.0.23/24 scope global tun0
$ ip route get 10.80.0.1
10.80.0.1 dev tun0 src 10.80.0.23

હવે ઓફિસની બાજુથી પડઘાને બદલે વાસ્તવિક વિનંતી સાથે પરીક્ષણ કરો. સેવા સામે સફળ curl એકસાથે માર્ગ, નીતિ અને શ્રોતાને સાબિત કરે છે, જ્યારે સફળ પિંગ ફક્ત એ સાબિત કરે છે કે ICMP ને પરવાનગી છે. જો વિનંતી નિષ્ફળ જાય, તો ફાયરવોલ પહોળું કરીને આશા રાખવાને બદલે ત્રણ ભાગમાંથી પાછળ જાઓ.

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

સંસાધનને જાણી જોઈને પ્રકાશિત કરો, નામ, માન્ય કૉલરની યાદી અને એક માલિક સાથે, અને દૂરનું ઉપકરણ આકસ્મિક સર્વરને બદલે સમર્થિત સેવા બને છે.