તમારું LAN VPN ક્લાયન્ટ પરની સેવા સુધી કેમ પહોંચી શકતું નથી

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

તૂટ્યું ટનલ નથી

બંને છેડા ખાનગી શ્રેણીમાં બેસે છે, જે સામાન્ય કિસ્સો છે અને ખોટી ગોઠવણી નથી. 10.8.0.6 જેવું સરનામું ટનલની અંદર વાસ્તવિક છે અને બીજે ક્યાંય અસ્તિત્વમાં નથી, તેથી LANને ત્યાં કંઈ મોકલવાનું કોઈ કારણ નથી. રૂટિંગને અડકતા પહેલાં ખાતરી કરો કે સેવા ટનલની અંદર જ પહોંચી શકાય એવી છે: ક્લાયન્ટ પર ss -ltn બતાવે છે કે શ્રોતા 127.0.0.1, LAN ઇન્ટરફેસ કે ટનલ સરનામા સાથે જોડાયેલો છે. ફક્ત loopback સાથે જોડાયેલ ડીમન પોતાના સિવાય કોઈને જવાબ આપતું નથી, અને કોઈ રૂટ, DNAT કે પોર્ટ ફોરવર્ડિંગ તેને બદલતું નથી.

પોર્ટ 80 કે 443 પરનો પ્રોક્સી અલગ દૃશ્યતા ધરાવતું બીજું સાધન છે. તે પેકેટ નહીં, વિનંતીઓ ખસેડે છે, તેથી કાચા ડેટાબેઝ કનેક્શન માટે તે ખોટું સ્તર છે, અને તેના તરફ હાથ લંબાવવો એ જ રીતે આ સમસ્યા કોઈ કંઈ માપે તે પહેલાં ત્રણ સાધન ઊંડી થઈ જાય છે.

રૂટનો આકાર: LANને કહો કે પૂલ ક્યાં છે

LAN ગેટવે પર સ્થિર રૂટ સૌથી સ્વચ્છ જવાબ છે જ્યારે LAN અને ટનલ પૂલ એકબીજા પર ન આવે. પૂલને ટનલ સમાપ્ત કરતા મશીન તરફ વાળો:

ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12   # Windows, persistent

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

push "route 192.168.1.0 255.255.255.0"

સર્વરની પાછળ નહીં પણ એક ક્લાયન્ટની પાછળ રહેલા સબનેટ માટે, સર્વરને સિસ્ટમ રૂટ અને તે ક્લાયન્ટની ફાઇલમાં iroute એન્ટ્રી બંનેની જરૂર છે, જે client-config-dir હેઠળ રહે છે. iroute વિના, OpenVPN જાણે છે કે પ્રીફિક્સ અસ્તિત્વમાં છે અને તેને ખબર નથી કે કયો ક્લાયન્ટ તેનો માલિક છે: પેકેટ આવે છે અને ડીમન પાસે તેમને મેળવવા માટે કંઈ નથી.

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

NATનો આકાર: અંદર DNAT, અને જે SNAT લાઇન બધા છોડી દે છે

જ્યારે તમે LAN ગેટવેને અડકી શકતા નથી, અથવા બરાબર એક પોર્ટ પ્રકાશિત કરવા માંગો છો, VPN હોસ્ટ પર ભાષાંતર LAN પર કોઈ રૂટ વિના કામ કરે છે. પોર્ટ પ્રકાશિત કરો, ફોરવર્ડ કરો, અને ટનલમાં જતા માર્ગમાં સ્રોતનું ભાષાંતર કરો:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1

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

ગ્રાહક ફર્મવેર પોતાના સાંકળ નામો વાપરે છે અને તમારા માટે તે ભાષાંતર બનાવતું નથી. Tomato પર, આવતી નિયમ WANPREROUTING માં પડે છે અને પછી wanin જેવી ફિલ્ટર સાંકળમાં, અને પૂર્ણ દેખાતા નિયમ સેટને હજી પણ મેન્યુઅલ POSTROUTING લાઇનની જરૂર છે. તે ફર્મવેર ભૂલ નથી; તે ફક્ત આવતા ટ્રાફિક માટે લખાયેલ નિયમ સેટ છે.

સાચો દેખાતો નિયમ પણ પેકેટ કેમ પડતું મૂકે છે

આમાંની મોટાભાગની નિષ્ફળતાઓ તમે જોઈ રહ્યા છો તે નિયમમાં નથી. આ ક્રમમાં ચાર વસ્તુઓ તપાસો, અને જે પહેલી ન ટકે ત્યાં થોભો:

• સાંકળ ક્રમ. iptables -I ઉપર દાખલ કરે છે અને -A અંતે ઉમેરે છે, તેથી પહેલાનો પરવાનગી આપતો કે અવરોધતો નિયમ પહેલો નિર્ણય લે છે.
• ખોટી સાંકળ. રાઉટર પોતાને સંબોધિત ટ્રાફિક INPUTમાંથી પસાર થાય છે, અને ફોરવર્ડ કરેલ ટ્રાફિક તેને ક્યારેય અડતું નથી. એક સેવા પ્રકાશિત કરવા બંનેમાં નિયમોની જરૂર પડી શકે.
• દિશા ફ્લેગ. -i tun0 ક્લાયન્ટમાંથી આવતા ટ્રાફિક સાથે મેળ ખાય છે અને -o tun0 તેમની તરફ જતા ટ્રાફિક સાથે. ખોટા ફ્લેગ સાથેનું REJECT એવું કંઈક અવરોધે છે જે તમે ઇચ્છ્યું ન હતું.
• સ્રોત મર્યાદા. એક ક્લાયન્ટ સરનામું સ્વીકારતું ફોરવર્ડિંગ તે ક્લાયન્ટથી કામ કરે છે અને દરેક બીજા સ્રોતને એક શબ્દ વિના પડતું મૂકે છે.

શૂન્ય પેકેટ કાઉન્ટરવાળો નિયમ માર્ગમાં જ નથી, અને કાઉન્ટર વાંચવા એ ખોટી-સાંકળની સમસ્યાને ખોટા-નિયમની સમસ્યાથી અલગ પાડવાનો સૌથી ઝડપી રસ્તો છે.

સ્થાનિક ફોરવર્ડિંગ, જ્યારે LAN પર કંઈ બદલી શકાય નહીં

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

ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host

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

બીજો નિયમ ઉમેરતા પહેલાં બંને દિશાઓ ચકાસો

ભાષાંતર નિશાન છોડે છે, અને તેમને વાંચવા એ અનુમાન કરવા કરતાં સારું છે. VPN હોસ્ટ પર, conntrack -L બતાવે છે કે ભાષાંતર થયું કે નહીં, iptables -t nat -L -n -v બતાવે છે કે કાઉન્ટર ખસ્યા કે નહીં, અને tcpdump -ni any port 3000 બતાવે છે કે કયું સ્રોત સરનામું ખરેખર આવ્યું. ક્લાયન્ટ પર, ss -ltn પુષ્ટિ કરે છે કે શ્રોતા એવા સરનામા પર છે જ્યાં ટનલ પહોંચી શકે.

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