OpenVPN દ્વારા જાહેર પ્રીફિક્સ: પરતનો રસ્તો સુધારો

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

પ્રીફિક્સ પહેલા તમારા તરફ રાઉટ થવું જોઈએ

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

જો પ્રોવાઈડર 198.51.100.64/28 તમારા પ્રવેશ સર્વર તરફ રાઉટ કરે છે, તો તે શ્રેણીના પેકેટ સર્વર પર આવે છે અને તમે તેમને ફોરવર્ડ ન કરો ત્યાં સુધી ત્યાં જ અટકી જાય છે. જો પ્રોવાઈડર તેના બદલે શ્રેણીને તમારા અપલિંક પર બ્રિજ કરે છે, તો સર્વરે તેના માટે ARP નો જવાબ આપવો પડે છે, જે બીજી સમસ્યા છે.

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

બે રાઉટિંગ સ્તરો: કર્નલ રૂટ અને iroute

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

સર્વર-બાજુનો રૂટ આવો દેખાય છે, જેમાં પ્રીફિક્સ અને માસ્ક ફાળવણી સાથે મેળ ખાવા જોઈએ:

ip route add 198.51.100.64/28 dev tun0

ક્લાયન્ટ-વિશિષ્ટ કન્ફિગરેશન માલિકી સોંપે છે. તેને ક્લાયન્ટ સર્ટિફિકેટના સામાન્ય નામ પરથી નામ આપેલી CCD ફાઈલમાં મૂકો, અને ખાતરી કરો કે તે ડિરેક્ટરી જ સર્વર ખરેખર વાંચે છે:

iroute 198.51.100.64 255.255.255.240

OpenVPN ના રાઉટ કરેલા નેટવર્ક્સ પરનું દસ્તાવેજીકરણ બંને સ્તરોનું અને તે કેમ અલગ છે તેનું વર્ણન કરે છે. iroute વગરનો કર્નલ રૂટ માલિક વગરના પેકેટ ટનલમાં મોકલે છે, અને OpenVPN તેમને કાઢી નાખે છે. કર્નલ રૂટ વગરનો iroute પેકેટને સર્વરના ડિફોલ્ટ માર્ગ પર છોડી દે છે. બંને ભૂલો ક્લાયન્ટની બાજુથી તૂટેલી ટનલ જેવી લાગે છે.

સેવા સરનામું ક્યાં રહે છે

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

જે Linux ક્લાયન્ટ સેવાને સ્થાનિક રીતે સમાપ્ત કરે છે, તેના પર એક હોસ્ટ સરનામું પૂરતું છે:

ip address add 198.51.100.70/32 dev lo

જો પ્રીફિક્સ આગળ VM હોસ્ટ કે બીજા LAN તરફ રાઉટ થાય છે, તો તેના બદલે તે ડાઉનસ્ટ્રીમ માર્ગ અને તેનો પરત રૂટ ગોઠવો. બ્લોકનું દરેક સરનામું VPN ક્લાયન્ટને સોંપવાની જરૂર નથી અને તે પછીથી વિરોધાભાસ ઊભા કરે છે.

પરતના રસ્તે જાહેર સ્રોત રાખો

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

પ્રવેશ સર્વર પર, પહોળો masquerade નિયમ સામાન્ય ગુનેગાર છે. તે જાહેર સ્રોતને સર્વરના મુખ્ય સરનામામાં ફરી લખે છે, અને ક્લાયન્ટ ક્યારેય સાચું જોતું નથી:

iptables -t nat -S POSTROUTING

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

તેના પર ભરોસો કરતા પહેલા બંને દિશાઓ ચકાસો

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

કર્નલને પૂછો કે ડેલિગેટ કરેલું સરનામું કયો માર્ગ લે છે, અને વિનંતી ચાલુ હોય ત્યારે ટનલ જુઓ:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

રિવર્સ-પાથ ફિલ્ટરિંગ સાચો રૂટ રદ કરી શકે છે. ટનલ પર અને અપલિંક પર અસરકારક સેટિંગ તપાસો, અને યાદ રાખો કે કડક મોડ તે ટ્રાફિકને નકારે છે જેનો સ્રોત જે ઈન્ટરફેસ પરથી આવ્યો છે તેની સાથે મેળ ખાતો નથી:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

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