Pi પરના હોટસ્પોટ ક્લાયન્ટ્સ TUN VPN દ્વારા ઘરના LAN સુધી પહોંચતા નથી

જે હોટસ્પોટ ક્લાયન્ટ્સને સરનામું મળે છે પણ ઘરનું શેરિંગ ખોલી શકતા નથી, તેમને પુલ નહીં, પરત માર્ગની જરૂર છે. TUN માર્ગ, પ્રીફિક્સ માલિકો અને NAT અનુસરો.

સ્થાનિક Wi-Fi અને Ethernet ક્લાયન્ટ્સ Pi ના હોટસ્પોટ સાથે જોડાય છે, તેના DHCP શ્રેણીમાંથી સરનામું લે છે અને ઇન્ટરનેટ પૃષ્ઠો ફરિયાદ વિના લોડ કરે છે. પછી એ જ ક્લાયન્ટ્સ ઘરના LAN પર ફાઇલ શેરિંગ કે વેબ ઇન્ટરફેસ ખોલતી વખતે સમયસીમા વીતી જાય છે, જ્યારે Pi પોતે ટનલ દ્વારા તે LAN સુધી પહોંચે છે. વાયરલેસ સ્તરમાં કંઈ તૂટેલું નથી. જે ખૂટે છે તે રૂટેડ કરાર છે: હોટસ્પોટ પ્રીફિક્સ TUN ઇન્ટરફેસમાં લઈ જવું પડશે, અને ઘરની બાજુએ કંઈક જાણવું પડશે કે જવાબો ત્યાં પાછા કેવી રીતે મોકલવા. એક પણ પેકેટ આખી મુસાફરી પૂરી કરે તે પહેલાં બંને અર્ધા હોવા જોઈએ.

ત્રણ અલગ કામો સાથે ત્રણ જોડાણો

Linux Ethernet બ્રિજ ગંતવ્ય MAC સરનામા પ્રમાણે ફ્રેમ ફોરવર્ડ કરે છે. OpenVPN TUN મોડમાં IP પેકેટ વહન કરે છે અને તેમાં MAC સ્તર જ નથી, તેથી સ્થાનિક બ્રિજ ઉમેરવાથી ટનલ ક્યારેય પોર્ટ તરીકે નોંધાતી નથી. કર્નલ TUN/TAP દસ્તાવેજીકરણ તે વિભાજન સમજાવે છે: TAP ઉપકરણ Ethernet ઇન્ટરફેસ જેવું લાગે છે, TUN ઉપકરણ નહીં. બે સ્થાનિક પોર્ટને બ્રિજ કરીને પછી રૂટ કરતી રચના રાઉટર છે, ઇન્ટરફેસના નામ ગમે તે કહે.

એ ભેદ માલિકી નક્કી કરે છે. ક્લાયન્ટ્સનું સબનેટ, તેમનું ડિફોલ્ટ ગેટવે અને તે શ્રેણીની DHCP સત્તા Pi ની સ્થાનિક યોજનાની છે. ઘરના DHCP પ્રસારણ રૂટેડ ટનલ ઓળંગતા નથી, અને કોઈ બ્રિજ સેટિંગ તેને બદલતું નથી; ક્લાયન્ટ્સને ઘરના DHCP સર્વર તરફ દોરવું એ અલગ, જાણી જોઈને કરેલી રિલે રચના છે જેની પોતાની નિષ્ફળતાની રીતો છે.

મોડેમને પણ ક્લાયન્ટ બ્રિજની બહાર રાખો. PPP જોડાણ બીજા લેબલવાળું Ethernet ઉપકરણ નથી, અને pppd નું દસ્તાવેજી ડિફોલ્ટ-રૂટ તર્ક IPCP વાટાઘાટ પછી ચાલે છે અને તે કડી પડે ત્યારે તેનો માર્ગ પાછો ખેંચે છે. DHCP ટેમ્પલેટ કોપી કરીને દરેક usb0 ને ppp0 નામ આપવાથી ગેટવે, મેટ્રિક કે જીવનચક્ર વિશે કંઈ સાબિત થતું નથી.

કોઈપણ રૂપરેખા સંપાદિત કરતા પહેલાં પ્રીફિક્સ પસંદ કરો

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

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

પ્રથમ કુંડ એ underlay સરનામું છે જે કેરિયરે મોડેમને આપ્યું; તે ક્લાયન્ટ તરફના દરેક પ્લાનની બહાર રહેવું જોઈએ. બીજો એ ટનલ સબનેટ છે જે સર્વરે પસંદ કર્યું, ઘણી વખત તેનું પોતાનું ખાનગી /24 નેટવર્ક. ત્રીજો હોટસ્પોટ બ્રિજ છે, અને ચોથો એ ઘરનું પ્રીફિક્સ છે જ્યાં તમે પહોંચવા માગો છો. આ ચાલમાં હોટસ્પોટને 172.28.90.0/24 મળે છે જેમાં બ્રિજ 172.28.90.1 પર છે, અને ઘરની સેવા LAN 192.168.77.0/24 રાખે છે, જે ગ્રાહક રાઉટર સાથે આવતા 192.168.1.0/24 અને 10.0.0.0/24 ડિફોલ્ટ અને 100.64.0.0/10 કેરિયર શ્રેણી ટાળે છે.

હોટસ્પોટની DHCP શ્રેણીમાં ફક્ત બ્રિજનું સરનામું ગેટવે તરીકે જાહેર કરો, બીજું કંઈ નહીં. હોટસ્પોટ ક્લાયન્ટ્સને ક્યારેય ગેટવે તરીકે ઘરનું સરનામું આપશો નહીં; તેમની પાસે તે સેગમેન્ટ સુધી લિંક-સ્તરનો માર્ગ નથી.

દરેક દિશાને તેની માલિકીની બાજુએ રૂટ કરો

Pi ને ટનલ દ્વારા ઘરના પ્રીફિક્સ માટે માર્ગની જરૂર છે. સર્વર મોડમાં સર્વરો સામાન્ય રીતે તે માર્ગ ધકેલે છે, તેથી પહેલાં ખાતરી કરો કે ફોરવર્ડિંગ ચાલુ છે અને કર્નલ tun0 માંથી ઘરનું સરનામું ઉકેલે છે.

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

જો ip route get હજી પણ underlay ઇન્ટરફેસની જાણ કરે છે, તો ત્યાં જ અટકો; માર્ગમાં આગળ કંઈ પણ ખોટી શોધ સુધારી શકતું નથી.

ઘરના ઉપકરણોને 172.28.90.0/24 સુધી કોઈ માર્ગ નથી, તેથી તેમના જવાબો ડિફોલ્ટ ગેટવે અનુસરે છે અને રાઉટર પર મરી જાય છે. બે સમર્થિત સુધારા છે. કાં તો ઘરના રાઉટર પર સ્થિર માર્ગ ઉમેરો જે હોટસ્પોટ પ્રીફિક્સને VPN સર્વરના LAN સરનામા તરફ દોરે, અથવા, જ્યારે સર્વર પોતે ગેટવે હોય, ત્યારે ક્લાયન્ટ પ્રીફિક્સ સર્વરની પોતાની રૂટિંગ કોષ્ટકમાં નોંધો. OpenVPN ના મલ્ટી-ક્લાયન્ટ મોડમાં ક્લાયન્ટ-વિશિષ્ટ ડિરેક્ટરી તે સંબંધ વહન કરે છે: ક્લાયન્ટ પ્રમાણપત્રના સામાન્ય નામ પરથી નામવાળી ફાઇલ, જેમાં iroute 172.28.90.0 255.255.255.0 ઉપરાંત તેને સર્વર કર્નલમાં સ્થાપિત કરતી મેળ ખાતી route લાઇન હોય છે. સર્વર પર અનુમાનિત કર્નલ માર્ગ એ સર્વરને કહેવા જેટલું જ નિવેદન નથી કે કયો ક્લાયન્ટ પ્રીફિક્સનો માલિક છે.

આ કામ કરે તે માટે ઘરના નેટવર્કની DHCP સેવા VPN સર્વર પર ખસેડશો નહીં. આખા ઘર માટે ડિફોલ્ટ ગેટવે બદલવો એ એક ખાનગી પરત માર્ગ ઉમેરવા કરતાં ઘણો મોટો ફેરફાર છે, અને તે DNS, સરનામા આરક્ષણો અને નવા લીઝને અવગણતા દરેક ઉપકરણને નિષ્ફળતામાં ખેંચે છે.

ફાયરવોલ વિશે અનુમાન કર્યા વિના ફોરવર્ડિંગ ખોલો

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

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

br0 થી tun0 સુધીનો સ્વીકાર નિયમ અને મેળ ખાતી જવાબ દિશા, તથા સ્રોતને ફરીથી લખી શકે તેવો postrouting નિયમ શોધો. જો ચેઇન નીતિ drop હોય અને કોઈ નિયમ મેળ ન ખાય, તો નીતિને accept તરફ ફેરવવાને બદલે સાંકડા સ્વીકારો ઉમેરો અને ફરી પરીક્ષણ કરો.

અનુવાદ એ આવશ્યકતા નહીં, નીતિની પસંદ છે. ઘરના LAN તરફ સ્રોત NAT દરેક હોટસ્પોટ ક્લાયન્ટને Pi ના ટનલ સરનામા જેવો દેખાડે છે, જે ઘરના લોગમાં પ્રતિ-ક્લાયન્ટ આરોપણ ગુમાવે છે અને મૂળ સ્રોતની અપેક્ષા રાખતી સેવાઓ તોડે છે. NAT વિના રૂટિંગ ક્લાયન્ટ સરનામાં દૃશ્યમાન રાખે છે પણ ઉપરના પરત માર્ગ પર આધાર રાખે છે. એક પસંદ કરો અને DNS અને IPv6 સાથે એ જ રીતે વ્યવહાર કરો, કારણ કે તૂટેલા IPv6 માર્ગની બાજુમાં કામ કરતો IPv4 માર્ગ બ્રાઉઝરમાં હજી પણ અડધો તૂટેલો વંચાય છે.

મુસાફરી ચકાસો, પછી તેને જાણી જોઈને તોડો

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

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

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

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

રચના ત્યારે જ સ્વીકારો જ્યારે હોટસ્પોટ ક્લાયન્ટ ઘરનું નામ ઉકેલી શકે, TCP સેવા ખોલી શકે અને એક મોડેમ પુનઃજોડાણ દરમિયાન સત્ર જીવંત રાખી શકે. જો કોઈ એપ્લિકેશનને ખરેખર ઘરના સેગમેન્ટમાં Ethernet-સ્તરની શોધની જરૂર હોય, તો સ્થાનિક બ્રિજને બ્રિજ્ડ કહીને પ્રસારણ આવવાની રાહ જોવાને બદલે સમર્થિત Layer 2 રચના પસંદ કરો.

સંબંધિત લેખો