બ્રિજ થયેલા OpenVPN ક્લાયંટને ઇન્ટરનેટ નથી? NAT નિયમ તપાસો

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

પુરાવો કાઉન્ટર છે, ટેબલની લાઇન નહીં

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

iptables -t nat -L POSTROUTING -v -n

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

કર્નલ ખરેખર જે નામ નોંધે છે તે શોધો

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

ip -brief link

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

ટનલ ઉપકરણ માટે નિયમ ફરીથી લખો

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tap0 -j MASQUERADE

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

કાઉન્ટર સાથે forward ચેઇન વાંચવામાં એક આદેશ જ લાગે છે અને બીજા નિયમને અડવા પહેલાં બાકીની અડધી શક્યતાઓ બાકાત કરી દે છે.

ભૌતિક કાર્ડ કેમ ક્યારેય મેળ ખાતું નથી

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

લોકોને આગળ જે સમસ્યા મળે છે તે એ જ માળખામાંથી આવે છે: બ્રિજ પર ફ્રેમ ફિલ્ટરિંગ IP ફિલ્ટરિંગથી અલગ સુવિધા છે. જો જરૂરિયાત ફ્રેમ-સ્તરની મર્યાદા હોય, તો તે બ્રિજ ફિલ્ટરિંગની છે, IP ટેબલના નિયમની નહીં.

શરૂઆતથી અંત સુધી સાબિત કરો, પછી તેને કાયમી બનાવો

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

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

ફરીથી લખ્યા પછી પણ કાઉન્ટર ન ખસે તો નિયમમાંની સ્રોત શ્રેણીને ક્લાયંટને ખરેખર મળેલા સરનામા સાથે સરખાવો, કારણ કે બ્રિજ થયેલો સર્વર તમે ધાર્યું ન હોય તેવી શ્રેણીમાંથી સરનામાં આપી શકે છે.