OpenVPN દ્વારા LAN ઍક્સેસ તૂટી? ઝોન, રૂટ અને પરત માર્ગ તપાસો

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

LAN તરફ જતું પેકેટ કયો ફિલ્ટર જુએ છે

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

OpenWrt આ વિભાજનને તપાસવાલાયક બનાવે છે, અને તફાવત એક વાર વાંચવા યોગ્ય છે. જે ઝોન ટનલ સમાપ્ત કરે છે તેને LAN ઝોન તરફ ફોરવર્ડ નિયમ જોઈએ છે, જ્યારે ઇનપુટ નિયમ ફક્ત રાઉટર પર ચાલતી સેવાઓને નિયંત્રિત કરે છે. કાર્યરત વ્યવસ્થાપન પૃષ્ઠ અને મૃત LAN સાથે મળીને તે ગુમ થયેલા ફોરવર્ડ નિયમનું સામાન્ય પરિણામ છે.

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

ટનલ વહન કરતા ઝોનના ફોરવર્ડ લક્ષ્યને જુઓ: accept એ છે જે સીડીને જોઈએ છે, અને reject નીચેની દરેક સમય સમાપ્તિ સમજાવે છે. બે પડોશી સેટિંગ્સ સમાન લક્ષણ પેદા કરે છે, તેથી અહીં હોવા દરમિયાન તેમને બાકાત રાખો. વાયરલેસ અલગીકરણ વાયરવાળા હોસ્ટને વાયરલેસ ક્લાઇન્ટથી છુપાવે છે, અને નિષ્ક્રિય LAN હોસ્ટને ઑફલાઇન ગણતું રાઉટર ફોરવર્ડિંગ કામ કર્યા પછી પણ જવાબો ફેંકી શકે છે.

વિભાજિત ટનલને પુશ કરેલું પ્રિફિક્સ કેમ જોઈએ

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

push "route 192.168.50.0 255.255.255.0"

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

ip route show | grep 192.168.50

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

જવાબને એવું સરનામું જોઈએ જ્યાં તે પહોંચી શકે

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

tcpdump -ni tun0 host 192.168.50.20

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

યોગ્ય જગ્યાએ પૂરી થતી સીડી

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

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

નામ સીડીના અંતમાં આવે છે, કદી શરૂઆતમાં નહીં. જે શેર 192.168.50.20 તરીકે જવાબ આપે છે પણ nas.local તરીકે નહીં તે નામ-નિરાકરણ અથવા શોધ પ્રત્યય તરફ ઇશારો કરે છે, અને ફાયરવોલ ફેરફારો તેમાંથી કંઈપણ બદલી શકતા નથી.

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