OpenVPN ક્લાયન્ટને Cloudflare દ્વારા રૂટ કરવા? પહેલાં ભૂમિકા ચકાસો
ડિવાઇસ ક્લાયન્ટ રાઉટર નથી. ખાતરી કરો કે Cloudflare ભૂમિકા અન્ય હોસ્ટના પેકેટ ફોરવર્ડ કરે છે, પછી સર્વરની પોતાની ટનલ તેના જૂના માર્ગ પર રાખો.
તમારી પાસે ચાલતું OpenVPN સર્વર છે અને એક હોસ્ટ છે જે Cloudflare નું ડિવાઇસ સોફ્ટવેર પણ ચલાવે છે, અને આગળનું સ્પષ્ટ પગલું ક્લાયન્ટ ટ્રાફિક ત્યાં મોકલવાનું લાગે છે. એક મશીન પર બે ચાલતા કનેક્શન મળીને ટ્રાન્ઝિટ ગેટવે બનતા નથી. જે ખૂટે છે તે બીજા કોઈના પેકેટ ફોરવર્ડ કરવા માટે દસ્તાવેજીકૃત ભૂમિકા છે, અને એ પેકેટ આવે ત્યારે તેમને વર્ગીકૃત કરતી નીતિ છે.
કોઈપણ નિયમ પહેલાં ચાર પ્રશ્નો આવે છે: કયો ટ્રાફિક અંદર આવે છે, તે પછી ક્યાં જાય છે, જવાબો પાછા ફરવાનો રસ્તો કેવી રીતે શોધે છે, અને એ બીજો રસ્તો નિષ્ફળ જાય ત્યારે ડિઝાઇન શું કરે છે. પહેલા બે ક્ષમતાના પ્રશ્નો છે.
એક હોસ્ટ પર બે સેવાઓ ટ્રાન્ઝિટ માર્ગ નથી
ડિવાઇસ ક્લાયન્ટ એ મશીન પર ઉદ્ભવતા ટ્રાફિકને સંભાળવા માટે બનાવાયેલ છે જ્યાં તે ચાલે છે. તે નામ નિરાકરણ અથવા પસંદ કરેલી એપ્લિકેશન ટ્રાફિકને પકડે છે અને પોતાની ટનલ દ્વારા મોકલે છે, અને તેની નીતિ તે ડિવાઇસના વપરાશકર્તા અને તે ડિવાઇસની પ્રક્રિયાઓ માટે લખાયેલી છે. OpenVPN ક્લાયન્ટમાંથી ફોરવર્ડ થયેલ પેકેટ સ્થાનિક આઉટપુટ નથી, તેથી એ જ નિયમો તેને વર્ગીકૃત કરતા નથી. આ એવી કન્ફિગરેશન વિગત નથી જેને વિશાળ નિયમથી ઢાંકી શકાય, કારણ કે તે નક્કી કરે છે કે સોફ્ટવેર પેકેટને જુએ છે કે નહીં.
તેથી ડિઝાઇન પ્રશ્ન ક્ષમતાનો પ્રશ્ન છે. કાં તો સ્થાપિત ઉત્પાદનમાં અન્ય નેટવર્ક માટે ટ્રાફિક ફોરવર્ડ કરતી દસ્તાવેજીકૃત ભૂમિકા છે, અથવા ટ્રાન્ઝિટ કાર્ય સંપૂર્ણપણે બીજે જ સ્થાને છે.
Cloudflare ની કઈ ભૂમિકાને ફોરવર્ડ કરવાની મંજૂરી છે
Cloudflare નો ડિવાઇસ ક્લાયન્ટ એવા મોડ આપે છે જે અવકાશમાં ભિન્ન છે: ફક્ત નામ નિરાકરણ, ડિવાઇસમાંથી ટ્રાફિક, અને ક્યારેક બંને. એમાંથી કોઈ પણ મોડ હોસ્ટને બીજી ટનલ દ્વારા આવતી ખાનગી શ્રેણી માટે રાઉટર બનાવતું નથી. સમર્પિત રૂટિંગ ભૂમિકા એ અલગ ઉત્પાદન છે જેનું પોતાનું કનેક્ટર, નોંધણી અને નેટવર્ક મોડેલ છે.
| Question | What has to answer it |
|---|---|
| Does the installed product forward packets from other hosts? | A documented routing or connector role, not a device mode |
| Which prefixes does the connector advertise? | Its own configuration and status output |
| Does the server's own transport still take the old path? | ip route get for the endpoint, before and after |
| Do replies return through the same path? | Connection tracking counters on the forward rule |
તેની આસપાસ રૂટ ડિઝાઇન કરતા પહેલાં સ્થાપિત ભૂમિકા ચકાસો. કનેક્ટર કઈ ઇન્ટરફેસ બનાવે છે, તે ચોક્કસ પ્રીફિક્સ કે ડિફોલ્ટ રૂટની જાહેરાત કરે છે કે નહીં, અને સ્થાનિક નીતિ ફોરવર્ડ થયેલા પેકેટને પણ લાગુ પડે છે કે નહીં તે વાંચો. જો ફક્ત સ્થાનિક ટ્રાફિક સંભાળવામાં આવે છે, તો ભાષાંતર નિયમ કેવો પણ લખાયો હોય, OpenVPN સર્વર ટ્રાન્ઝિટ બિંદુ બની શકતું નથી.
અહીં જાહેર એગ્રેસની આવશ્યકતા ચોકસાઈપૂર્વક કહેવી પડે છે. ફોરવર્ડ થયેલા ક્લાયન્ટ ટ્રાફિક માટે Cloudflare દ્વારા આપવામાં આવતું એગ્રેસ એ ચોક્કસ ઉપયોગ-કેસ છે, અને તે તમારી પાસે ખરેખર જે સેવા છે તેની સામે ખાતરી કરવી પડે છે.
બાહ્ય ટનલને નવા રૂટથી સ્વતંત્ર રાખો
જે ક્ષણે તમે નવી ઇન્ટરફેસ તરફ ડિફોલ્ટ રૂટ ઉમેરો છો, તે ક્ષણે સર્વરનો પોતાનો આઉટબાઉન્ડ ટ્રાફિક તેના માટે સ્પર્ધા કરવા લાગે છે, અને તેમાં OpenVPN ક્લાયન્ટને આપવાના જવાબો અને બોક્સ સાથેનું તમારું SSH સેશન પણ સામેલ છે. સામાન્ય લક્ષણ એ ટનલ છે જે સ્થપાય છે અને પછી મરી જાય છે, અથવા એવો એડમિનિસ્ટ્રેટર છે જે બહાર તાળું મરાયેલો રહે છે જ્યારે ફેરફાર કરેલો લાગે છે. એન્ડપોઇન્ટ માટે ip route get ની પહેલાં અને પછી સરખામણી કરો, અને સર્વરના પોતાના ટ્રાન્સપોર્ટને જ્યાં હતો ત્યાં રાખવા માટે પોલિસી રૂટિંગ અથવા હોસ્ટ રૂટ વાપરો. એ સરખામણી બોક્સમાંથી જ ચલાવો, કારણ કે સર્વરનું પોતાના રૂટ વિશેનું દૃશ્ય એ જ મહત્ત્વનું છે.
સર્વરના જાહેર સરનામા માટેનો અપવાદ એકલો પૂરતો નથી, કારણ કે દરેક દૂરસ્થ એડમિનિસ્ટ્રેટરનો પરત માર્ગ અલગ પ્રવાહ છે. એ પ્રવાહોમાંથી કયા ફેરફારમાંથી બચવા જોઈએ તે નક્કી કરો, પછી પહેલો બાકીનાને આવરે છે એમ ધારવાને બદલે દરેકને ચકાસો.
ફોરવર્ડિંગ અને ભાષાંતરને એક પ્રવાહ સુધી મર્યાદિત કરો
પ્રાપ્ત થયેલા પેકેટ ફોરવર્ડિંગ માર્ગને અનુસરે છે, સ્થાનિક આઉટપુટ માર્ગને નહીં, તેથી મહત્ત્વનો નિયમ forward હૂકમાં રહે છે. જ્યાં આગળની ઇન્ટરફેસને ભાષાંતરની જરૂર છે, ત્યાં સ્રોતને ક્લાયન્ટ પૂલ સુધી, ગંતવ્યને મંજૂર વસ્તુ સુધી અને એગ્રેસને એ એક જ ઇન્ટરફેસ સુધી મર્યાદિત કરો. ફક્ત ઇન્ટરફેસ સાથે જોડાયેલો masquerade નિયમ પોતે કોઈ રૂટ પસંદ કરતો નથી અને બીજા કોઈ ફિલ્ટરની પાર ફોરવર્ડિંગની મંજૂરી આપતો નથી.
નિષ્ફળતા પર બંધ થવાનું વર્તન અગાઉથી નક્કી કરો, પછી તેને ચકાસો. આગળનો માર્ગ બંધ કરો અને ખાતરી કરો કે ક્લાયન્ટ ઇચ્છિત એગ્રેસ ગુમાવે છે, ચૂપચાપ સામાન્ય અપલિંક પર પાછા પડે છે એમ નહીં, કારણ કે એ જ પરિણામ છે જે કોઈ ધ્યાનમાં લેતું નથી જ્યાં સુધી ટ્રાફિક ખોટા દરવાજેથી બહાર નીકળવા લાગે. નામ નિરાકરણ અને IPv6 માટે ચકાસણીનું પુનરાવર્તન કરો, કારણ કે ફક્ત v4 માટેનો નિયમસમૂહ v6 માર્ગ ખુલ્લો છોડે છે.
તમે જે ચાર જવાબો પર સ્થિર થયા તે અને દરેકને સાબિત કરતું અવલોકન લખો. તમે જે ટ્રાન્ઝિટ માર્ગનું વર્ણન કરી શકો તે જ આગલી ઘટના સમીક્ષામાં તમે બચાવી શકો તેવો છે.