UID નિયમ સાથે એક Linux ખાતાને OpenVPN દ્વારા રૂટ કરો

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

નીચેનું ઉદાહરણ UID 1500 પર સમર્પિત બ્રાઉઝર ખાતું, 10.80.0.11 સ્થાનિક સરનામું ધરાવતું ટનલ ઉપકરણ tun-office, અને પ્રશ્નમાંના લક્ષ્યોને મંજૂરી આપતું VPN ધારે છે. ડિમન પોતે તે UID ની બહાર ચાલે છે.

ત્રણ શરતો જે મિકેનિઝમ પસંદ કરે છે

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

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

કોષ્ટક, નિયમ અને રક્ષક

હાલના નિયમો ચકાસીને વણવપરાયેલા કોષ્ટક અને પ્રાયોરિટી નંબર પસંદ કર્યા પછી ગોઠવણ ટૂંકી છે: ટનલનું સ્રોત સરનામું ધરાવતા સમર્પિત કોષ્ટકમાં ડિફોલ્ટ રૂટ, ખાતાની લુકઅપ તે કોષ્ટકમાં મોકલતો નિયમ, અને ફોલબેક અટકાવતો અંતિમ નિયમ. લખિત રૂપે તે idempotent રૂટ રિપ્લેસમેન્ટ છે, ip -4 route replace default dev tun-office src 10.80.0.11 table 51820, અને પછી ip -4 rule add priority 12100 uidrange 1500-1500 lookup 51820.

રક્ષક ip -4 rule add priority 12101 uidrange 1500-1500 unreachable છે, અને તેની લંબાઈ સૂચવે તેનાથી વધુ મહત્વનો છે. તેના વિના કોષ્ટક 51820 માં ખૂટતો રૂટ સામાન્ય અપલિંકમાં પડી જાય છે અને ખાતું ચૂપચાપ એ ટ્રાફિક લીક કરે છે જે નીતિ પકડવાની હતી. તેની સાથે એ જ નિષ્ફળતા ટાઇમઆઉટ બને છે, એટલે કે ફોલબેક નહીં પણ બ્લોકિંગ.

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

UID રાઉટિંગ શું છોડી દે છે: DNS

રિઝોલ્વર ડિમન તેના અપસ્ટ્રીમ સોકેટ પોતાના UID હેઠળ ખોલે છે, તેથી 1500 પસંદ કરવાથી એ ક્વેરીઓ કોષ્ટક 51820 માં જતી નથી. DNS એકીકરણ અલગ નિર્ણય છે: ખાતાને ટનલ દ્વારા પહોંચી શકાય તેવા રિઝોલ્વર તરફ નિર્દેશ કરો, અથવા સ્વીકારો કે નામ-ઉકેલ હોસ્ટના માર્ગને અનુસરે છે જ્યારે ટ્રાફિક નહીં.

સ્થાનિક stub તરફની loopback ક્વેરી એ પુરાવો નથી કે અપસ્ટ્રીમ ક્વેરીએ બ્રાઉઝરનો માર્ગ વાપર્યો, અને કેશમાંથી સફળ પૃષ્ઠ લોડ પણ નથી.

IPv6 ને ડિઝાઇનમાં પોતાનું વાક્ય જોઈએ

ઉપરના નિયમો ફક્ત IPv4 આવરે છે. જો જરૂરિયાત આ ખાતાથી સીધા IPv6 વિનાનું IPv4 ટનલ હોય, તો સમીક્ષિત અંતિમ નિયમ ઉમેરો જેમ કે ip -6 rule add priority 12101 uidrange 1500-1500 unreachable, પછી પહેલાના IPv6 નિયમો અને તમે રાખવા માંગતા loopback અપવાદો ચકાસો.

સીધું IPv6 બ્લોક કરવું ડ્યુઅલ-સ્ટેક ટનલિંગ નથી; તે સીમા છે. તેને ટનલિંગ કહેવાથી નીતિ વાંચનારી આગલી વ્યક્તિ મૂંઝાશે, અને એ મૂંઝવણ તૂટેલી IPv6 સાઇટ વિશેની હેલ્પડેસ્ક ટિકિટ તરીકે બહાર આવશે.

સાચા ખાતા સાથે ચકાસો, પછી જીવનચક્રની જવાબદારી લો

લુકઅપની તુલના કરો: ip -4 route get 198.51.100.25 uid 1500 સામાન્ય UID સાથે એ જ લક્ષ્ય સામે. પછી સમર્પિત ખાતા હેઠળ મંજૂર વિનંતી કરો અને દૂરના છેડે દેખાતું સ્રોત સરનામું ચકાસો. પ્રેફર્ડ સ્રોત સરનામું source NAT નથી, અને તે બીજું કંઈક બાઇન્ડ કરતી એપ્લિકેશનને દૂર કરશે નહીં. જો બંને લુકઅપ એક જ માર્ગ પરત આપે, તો નિયમ તમે ધારો છો તે કરતું નથી.

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