દૂરસ્થ વપરાશકર્તાઓ VPN હબ દ્વારા બીજી સાઇટ સુધી પહોંચી શકતા નથી

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

ટ્રાન્ઝિટને ત્રણ લુકઅપની જરૂર છે, એક ટનલની નહીં

દરેક ઉપકરણ પોતાનું સૌથી લાંબા પ્રીફિક્સનું મેળ બનાવે છે અને તેને ભૂલી જાય છે. લેપટોપે 10.20.0.50 ને તેના સ્થાનિક રાઉટરને બદલે ટનલમાં મોકલવું જોઈએ. હબે રિમોટ-એક્સેસ ઇન્ટરફેસ પર આવેલું પેકેટ લઈને તેને સાઇટ-ટુ-સાઇટ ઇન્ટરફેસને સોંપવું જોઈએ. મુખ્ય કાર્યાલયે વપરાશકર્તાના સરનામા માટેનો જવાબ ટનલ દ્વારા પાછો મોકલવો જોઈએ. ત્રણમાંથી કોઈપણ એક નિષ્ફળતા બ્રાઉઝરમાં એકસરખી દેખાય છે: મૌન.

તેથી જ દરેક ટનલને એકલી તપાસવી બહુ ઓછું સાબિત કરે છે. હબના LAN સરનામાને પિંગ કરવું પ્રથમ નિર્ણયનો ઉપયોગ કરે છે, અને મુખ્ય કાર્યાલયથી હબને પિંગ કરવું ત્રીજાનો ઉપયોગ કરે છે. જે પેકેટ નિષ્ફળ જાય છે તેનું સ્રોત વપરાશકર્તા પૂલ અને લક્ષ્ય બીજી સાઇટ છે, તેથી પહેલા એ પ્રીફિક્સ લખી લો. અહીં પૂલ 10.80.0.0/24 છે, હબનું LAN 10.10.0.0/24 છે અને મુખ્ય કાર્યાલય 10.20.0.0/24 છે.

દૂરના પ્રીફિક્સને દૂરસ્થ ક્લાયન્ટ પર ધકેલો

એક OpenVPN રિમોટ-એક્સેસ સર્વર પર ક્લાયન્ટ જોડાણ સમયે રૂટ શીખે છે. પુશ વિના, સ્પ્લિટ-ટનલ ક્લાયન્ટ 10.20.0.50 પોતાના ગેટવેને મોકલે છે અને પેકેટ ક્યારેય ટનલમાં પ્રવેશતું નથી.

push "route 10.20.0.0 255.255.255.0"

ધકેલાયેલો રૂટ ક્લાયન્ટ જોડાય ત્યારે અમલમાં આવે છે, તેથી ઓનલાઇન રહેતો વપરાશકર્તા ફરી જોડાય ત્યાં સુધી કંઈ જોતો નથી. ક્લાયન્ટ પર ચકાસો: Linux પર ip route get 10.20.0.50, Windows પર route print. આઉટપુટે ટનલ ઇન્ટરફેસનું નામ આપવું જોઈએ.

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

હબને વાસ્તવિક ઇગ્રેસ રૂટ આપો

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

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

જ્યાં સાઇટ-ટુ-સાઇટ પગ પોતે OpenVPN છે, ત્યાં રૂટ સાથીના ટનલ સરનામાને ગેટવે તરીકે લઈને તે જ રૂપરેખાંકનમાં રહી શકે છે: route 10.20.0.0 255.255.255.0 172.30.0.2. ગેટવે વૈકલ્પિક નથી. તેને છોડી દો તો આગળનો હોપ અમલીકરણના ડિફોલ્ટ પર આવી જાય છે, જે એકલ-દૂરસ્થ ક્લાયન્ટ અને બહુ-સાથી હબ વચ્ચે અલગ પડે છે.

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

દૂરની બાજુને વપરાશકર્તા પૂલ સુધી લંબાવો

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

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

એક ઉપકરણનું local_ts બીજાનું remote_ts છે. હબનો બ્લોક મુખ્ય કાર્યાલય પર કોપી કરો અને જોડી ઊલટાઈ જાય છે, તેથી ચાઇલ્ડ SA ક્યારેય ઉપર આવતું નથી.

જૂની ipsec.conf સિન્ટેક્સ અલ્પવિરામથી અલગ કરેલ leftsubnet વાપરે છે. ચાલુ સિક્યોરિટી એસોસિએશન જે સિલેક્ટર વાટાઘાટ કર્યા તે રાખે છે, તેથી સંપાદન પછી ટનલ ફરી સ્થાપિત કરો. 10:00 વાગ્યે બદલાયેલો સિલેક્ટર 09:40 વાગ્યે ઉપર આવેલા SA સામે પરીક્ષણ કરવામાં આવે તો પણ નિષ્ફળ જાય છે, જ્યારે કન્ફિગ ફાઇલ આખા સમય દરમિયાન સાચી દેખાય છે.

પછી છેલ્લો હોપ તપાસો. દૂરના એન્ડપોઇન્ટ પર ip route get 10.80.0.25 ટનલ તરફ નિર્દેશ કરવો જોઈએ. જો સેવા LAN રાઉટરને તેના ડિફોલ્ટ ગેટવે તરીકે વાપરે છે, તો તે રાઉટરને પણ રિટર્ન રૂટની જરૂર છે, નહીં તો જવાબ ત્યાં જ મરી જાય છે. તે સેગમેન્ટ પર tcpdump -ni eth1 host 10.80.0.25 ચલાવવું દર્શાવે છે કે જવાબ એન્ડપોઇન્ટમાંથી બહાર નીકળ્યો હતો કે નહીં.

હબ પર ફ્લોને મંજૂરી આપો

ફોરવર્ડિંગ સક્ષમ હોવું જોઈએ અને માર્ગને મંજૂરી હોવી જોઈએ. ઇન્ટરફેસ વચ્ચે બધું સ્વીકારવાને બદલે નિયમોને બે પ્રીફિક્સ સુધી મર્યાદિત કરો.

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

રિવર્સ-પાથ ફિલ્ટરિંગ તેની બાજુની શાંત નિષ્ફળતા છે: બે પગ અલગ ઇન્ટરફેસ પર હોય ત્યારે rp_filter=1 જવાબ છોડી શકે છે જ્યારે સ્વીકાર નિયમનું કાઉન્ટર ક્યારેય ખસતું નથી. એક પ્રયાસ પહેલાં અને પછી iptables -vnL FORWARD સરખાવો. જે નિયમ ક્યારેય વધતો નથી ત્યાં પહોંચાયું જ નથી, તેથી તેને ફરી લખવાને બદલે એક સ્તર નીચે જુઓ.

જો ફક્ત એક જૂથને ટ્રાન્ઝિટની જરૂર હોય, તો વૈશ્વિક પુશ પહોળું કરવાને બદલે client-config-dir હેઠળ પ્રતિ-ક્લાયન્ટ ફાઇલમાં રૂટ મૂકો. હબ પર સોર્સ NAT પણ દૂરની બાજુના રિટર્ન રૂટની જરૂર દૂર કરે છે, પરંતુ તે વપરાશકર્તાનું સરનામું છુપાવે છે, તેથી દૂરની સાઇટના લોગ અને સરનામા-આધારિત નિયમો વપરાશકર્તાઓને અલગ પાડવાનું બંધ કરે છે.

ક્લાયન્ટથી ચકાસો, પછી ઊલટા ક્રમમાં રોલબેક કરો

ફક્ત ICMP નહીં, TCP પોર્ટ ચકાસો, કારણ કે પિંગ પસાર થઈ શકે છે જ્યારે સેવા અવરોધિત રહે છે. ક્લાયન્ટથી nc -vz 10.20.0.50 445 અને traceroute -n 10.20.0.50 દર્શાવે છે કે બીજો હોપ હબનું ટનલ સરનામું છે કે નહીં. હબ પર, tcpdump -ni tun0 host 10.20.0.50 અને સાઇટ-ટુ-સાઇટ ઇન્ટરફેસ પર એ જ ફિલ્ટર: બંને પર વિનંતી પણ કોઈ પર જવાબ નહીં, સમસ્યાને દૂરની બાજુ પર ખસેડે છે.

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

રોલબેક સૂચિ રાખો, કારણ કે ચાર ઑબ્જેક્ટ બદલાયા છે અને ત્રણ ભૂલવા સહેલા છે: ધકેલાયેલો રૂટ, હબનો રૂટ, સિલેક્ટર અને ફાયરવોલ નિયમો. તેમને ઊલટા ક્રમમાં પાછા ખેંચો, SA ફરી સ્થાપિત કરો અને એક વપરાશકર્તાને ફરી જોડાવા દો. આંશિક રોલબેક એવી ટનલ તરફ રૂટ છોડે છે જે હવે મેળ ખાતી નથી, અને તે મૂળ મૌન કરતાં વાંચવું વધુ મુશ્કેલ છે. OpenVPN 2.6 મેન્યુઅલ તમારી આવૃત્તિ માટે push, route અને iroute નું દસ્તાવેજીકરણ કરે છે.