OpenVPN ક્લાયન્ટ સર્વર સુધી પહોંચે છે પણ LAN હોસ્ટ સુધી નહીં: ચેકલિસ્ટ

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

પહેલું પગલું: ક્લાયન્ટના રૂટિંગ નિર્ણયને જુઓ

સર્વરને સ્પર્શ કરતા પહેલા સાબિત કરો કે ક્લાયન્ટ પેકેટને ટનલમાં મોકલે છે. આખું ટેબલ વાંચવાને બદલે કર્નલને પૂછો કે એક ચોક્કસ LAN હોસ્ટ માટે તે કઈ ઇન્ટરફેસ વાપરશે:

ip route get 192.168.50.10

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

Windows પર એ જ પ્રશ્નનો બીજો આદેશ છે. Find-NetRoute -RemoteIPAddress 192.168.50.10 તે ઇન્ટરફેસ અને આગળનો હોપ છાપે છે જે સ્ટેક પસંદ કરશે, અને route print -4 બતાવે છે કે ધકેલાયેલો પ્રીફિક્સ બિલકુલ અસ્તિત્વમાં છે કે નહીં.

બીજું પગલું: ખાતરી કરો કે સર્વર પેકેટ ફોરવર્ડ કરશે

જો ક્લાયન્ટ રૂટ સાચો હોય, તો પેકેટ સર્વર સુધી પહોંચે છે અને સર્વરે તેને ફોરવર્ડ કરવા સંમત થવું પડે. કર્નલ સ્વિચ પહેલો દરવાજો છે, અને sysctl net.ipv4.ip_forward એ 1 પરત આપવો પડે. echo 1 > /proc/sys/net/ipv4/ip_forward થી તેને સેટ કરવું આગલા રીબૂટ સુધી કામ કરે છે, અને એટ જ કારણે એ જ ફરિયાદ અઠવાડિયા પછી પાછી આવે છે.

તેને એવી જગ્યાએ લખો જે રીસ્ટાર્ટ પછી ટકી રહે:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

બીજો દરવાજો ફિલ્ટર ટેબલ છે. Docker ઇન્સ્ટોલ કરેલા હોસ્ટ પર ઘણી વાર FORWARD નીતિ DROP હોય છે, અને ટનલ તે નિર્ણય વારસામાં લે છે. iptables -L FORWARD -v -n નીતિ અને પેકેટ કાઉન્ટર બંને બતાવે છે; જો નીતિ DROP હોય, તો ફોરવર્ડિંગને ટનલથી LAN દિશા માટે એક સ્પષ્ટ મંજૂરી અને જવાબ માટે બીજી જોઈએ.

ત્રીજું પગલું: પેકેટને LAN સુધી અનુસરો અને જવાબ શોધો

સર્વરની બંને બાજુ એક સાથે જુઓ. ટનલ પર અને LAN ઇન્ટરફેસ પર કેપ્ચર કરો, એક ક્લાયન્ટ અને એક હોસ્ટ પર ફિલ્ટર કરીને જેથી આઉટપુટ વાંચવા યોગ્ય રહે:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

જે વિનંતીઓ tun0 પર અને ફરી eth0 પર 10.8.0.x સ્રોત સાથે દેખાય છે, પછી શાંતિ આવે છે, તેનો અર્થ છે કે પેકેટ આવી ગયું અને જવાબ બીજે ક્યાંક ગયો. LAN હોસ્ટ તેના ડિફોલ્ટ ગેટવેને જવાબ આપે છે, તે ગેટવે પાસે VPN પૂલ માટે કોઈ રૂટ નથી, અને જવાબ LAN રાઉટર પર મરી જાય છે. સર્વરથી LAN હોસ્ટને ping કરવાથી આ માર્ગ વિશે કંઈ સાબિત થતું નથી, કારણ કે તે ટ્રાફિક ક્યારેય ટનલ પાર કરતું નથી.

ચોથું પગલું: અનુવાદ અને પરત રૂટ વચ્ચે પસંદ કરો

બે સમારકામ છિદ્ર બંધ કરે છે, અને ping કામ કરે છે કે નહીં તેનાથી આગળ પણ આ પસંદગીની અસરો છે. સ્રોત અનુવાદ સર્વરને દેખીતો પ્રેષક બનાવે છે:

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

નિયમને પૂલ અને LAN ઇન્ટરફેસ સુધી મર્યાદિત કરો, પછી તેને કાયમી બનાવો, નહીંતર આગલું ફાયરવૉલ રીલોડ તમારું સુધારણા ચૂપચાપ દૂર કરી દેશે. કિંમત ઓળખ છે: દરેક ક્લાયન્ટ LAN લોગ અને ઍક્સેસ નિયમોમાં VPN સર્વર જેવો દેખાય છે, અને per-client policy becomes guesswork.

LAN રાઉટર પર VPN સર્વર તરફ નિર્દેશ કરતો 10.8.0.0/24 માટેનો સ્ટેટિક રૂટ ક્લાયન્ટ સરનામાં દૃશ્યમાન રાખે છે અને જ્યારે તે રાઉટર તમારું હોય ત્યારે લાંબા ગાળાનો સારો જવાબ છે. ઘણી સાઇટો થોડા સમય માટે બંને ચલાવે છે, તાત્કાલિક સમારકામ માટે NAT અને ફાયરવૉલ નીતિ લખાઈ જાય પછી રૂટ. જો સર્વર પૂલને બદલે સાઇટ-ટુ-સાઇટ પીઅર હોય, તો સર્વર બાજુને દૂરના સબનેટ માટે iroute પણ જોઈએ, નહીંતર પીઅર રૂટ અસ્તિત્વમાં છે પણ ક્લાયન્ટ ટ્રાફિક તેની સાથે ક્યારેય જોડાતું નથી.

પાંચમું પગલું: ક્લાયન્ટથી ચકાસો અને શું બદલાયું તે નોંધો

લૂપ ક્લાયન્ટથી બંધ કરો, સર્વરથી નહીં. LAN હોસ્ટ પરની વાસ્તવિક સેવા સાથે જોડાઓ, પછી ખાતરી કરો કે અનુવાદ કાઉન્ટર iptables -t nat -L POSTROUTING -v -n સાથે ખસ્યા છે, કારણ કે શૂન્ય પેકેટવાળો નિયમ એ નિયમ છે જે ક્યારેય મળ્યો નથી. જ્યારે તમને સાબિતી જોઈએ કે પરત દિશા ટ્રૅક થાય છે ત્યારે conntrack -L -s 10.8.0.5 પ્રવાહ અને તેની સ્થિતિ બતાવે છે.

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