એક Pi પર hostapd અને OpenVPN: ડિફોલ્ટ રૂટ કોનો છે?

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

કંઈપણ સંપાદિત કરતા પહેલા ઇન્ટરફેસની યાદી બનાવો

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

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

ip -br addr
ip route show
ip link show master br0
bridge link show

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

બ્રિજને તેનો પોતાનો ડિફોલ્ટ રૂટ આપો

Raspberry Pi OS ઘણી વાર બ્રિજને ડિફોલ્ટ રૂટ વિના છોડી દે છે જ્યારે ઇન્ટરફેસ ફાઇલ લખાયા પછી બ્રિજ બન્યું હોય. બ્લોક /etc/dhcpcd.conf માં હોવો જોઈએ, અને તેણે Pi ને નહીં, અપસ્ટ્રીમ રાઉટરનું નામ આપવું જોઈએ.

interface br0
static ip_address=192.168.50.2/24
static routers=192.168.50.1
static domain_name_servers=192.168.50.1

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

systemctl restart dhcpcd પછી ip route show default એ br0 ને એક વાર સૂચિબદ્ધ કરવું જોઈએ અને વાયર્ડ પોર્ટથી કોઈ નકલ નહીં. ટેબલને નહીં, લુકઅપને ખાતરી કરો, કારણ કે જૂની એન્ટ્રી જીતતી એન્ટ્રીની બાજુમાં બેસી શકે છે: ip -4 route get 203.0.113.10 એ br0 નું નામ આપવું જોઈએ. તે સરનામું TEST-NET-3 દસ્તાવેજી શ્રેણીમાંથી આવે છે, તેથી તમે આ વાંચો ત્યારે તે વાસ્તવિક સર્વર સાથે અથડાઈ શકતું નથી.

ટનલને તેના પોતાના સર્વર સુધીનો માર્ગ ચોરવાથી રોકો

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

જોડાણ પહેલાં અને પછી તે ટ્રાન્સપોર્ટ માર્ગની ઝડપી સરખામણી તે દસ સેકન્ડ વસૂલાય છે. ip -4 route get 203.0.113.10 બંને સ્થિતિમાં અંડરલે ઉપકરણનું નામ આપવું જોઈએ, ફક્ત મેટ્રિક બદલાય છે. જો ટનલ ઉપર આવ્યા પછી તે tun0 નું નામ આપે, તો હોસ્ટ રૂટ ક્યારેય સ્થાપિત થયો ન હતો અને આગલું પુનઃજોડાણ નિષ્ફળ જશે.

જ્યારે ફક્ત પસંદ કરેલા પ્રીફિક્સ ટનલ પાર કરવા જોઈએ, ત્યારે route-nopull વાપરો અને ઇચ્છિત રૂટ જાતે ઉમેરો, અથવા સર્વરથી સાંકડો સેટ મોકલો. તે ડિઝાઇનમાં બ્રિજ ડિફોલ્ટ રૂટ રાખે છે, અને DNS આગળનો નિર્ણય બને છે: dnsmasq ને ઘરના રિઝોલ્વર તરફ ફોરવર્ડ કરવું ફક્ત તે નામો માટે અર્થપૂર્ણ છે જે ખરેખર ત્યાં રહે છે.

ફોરવર્ડિંગ અને NAT નો નિર્ણય કરો

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

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

NAT નિયમ તે શોર્ટકટ છે જે ત્યારે કામ કરે છે જ્યારે સર્વર એક્સેસ પોઇન્ટ પ્રીફિક્સ સ્વીકારશે નહીં, પરંતુ કિંમત એ છે કે દરેક ક્લાયન્ટ દૂરના છેડાના લોગમાં Pi ના ટનલ સરનામા તરીકે દેખાય. NAT વિના પ્રીફિક્સ રૂટ કરવું સરનામાં દૃશ્યમાન રાખે છે અને ઘરની બાજુ પર 192.168.50.0/24 માટે પરત રૂટ પર આધાર રાખે છે.

ફાયરવોલ નિયમોની બાજુમાં પસંદગી લખો, કારણ કે ડિઝાઇનમાં અદૃશ્ય NAT નિયમ છ મહિના પછી અસમજાવી બને છે. IPv6 ને એ જ નિર્ણયમાં રાખો; તૂટેલા IPv6 માર્ગની બાજુમાં કાર્યકારી IPv4 માર્ગ બ્રાઉઝરમાં હજી અડધો તૂટેલો જ વંચાય છે.

ક્લાયન્ટથી ચકાસો, પછી સ્વચ્છ રીતે રોલબેક કરો

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

ip -4 route get 203.0.113.10
ping -c 3 -I br0 203.0.113.10

પછી ખાતરી કરો કે Pi પાસે હજી તેનો પોતાનો બહારનો માર્ગ છે: ip route get 203.0.113.10 એ અંડરલે ઉપકરણનું નામ આપવું જોઈએ, અને જો સર્વર ICMP ની મંજૂરી આપે તો ping -c 3 -I br0 203.0.113.10 એ જવાબ આપવો જોઈએ. જો પહેલા બે ક્લાયન્ટ પગલાં પાસ થાય અને ત્રીજું નિષ્ફળ જાય, તો ખામી ફોરવર્ડિંગ અથવા NAT માં છે. જો બીજું પગલું નિષ્ફળ જાય, તો બ્રિજ અથવા DHCP હજી અપૂર્ણ છે.

રોલબેક એ એક ફાઇલ સંપાદન અને બે આદેશો છે: બ્લોક દૂર કરો, dhcpcd ફરી શરૂ કરો, અને ડિફોલ્ટ રૂટને સ્પષ્ટ રીતે ip route replace default via 192.168.50.1 dev br0 સાથે બદલો. જાળવણી વિન્ડો બંધ થાય તે પહેલાં આ કરો, પછી નહીં, કારણ કે ડિફોલ્ટ રૂટ ગુમાવેલ Pi તે નેટવર્કથી પહોંચી શકાય તેમ નથી જે તમે તેને સમારવા માટે વાપરશો.