VPN અને ઘરનું LAN એક જ સબનેટ વાપરે છે: પહેલા રૂટ જુઓ
બંને અડેપ્ટર 192.168.1.0/24 નો દાવો કરે છે અને એક જ રૂટ જીતે છે. ફરી નંબર આપતાં કે DNS ને દોષ આપતાં પહેલાં અડેપ્ટર યાદી, જીતતો રૂટ અને પરતનો રસ્તો જુઓ.
તમે ઓફિસના VPN સાથે જોડાઓ છો, ટ્રેનું ચિહ્ન લીલું થાય છે, ઇન્ટ્રાનેટ લોડ થાય છે, અને બે મીટર દૂરનું પ્રિન્ટર જવાબ આપવાનું બંધ કરે છે. આજે સવારે કામ કરતું શેરિંગ એ જ મશીન પર સમયસીમા વટાવે છે, અને કોઈ પણ લોગમાં પ્રિન્ટરનો ઉલ્લેખ નથી. પહેલી પ્રતિક્રિયા DNS છે, કારણ કે જે નામ ઉકેલાતું નથી તે અસ્તિત્વમાં ન હોય તેવા નામ જેવું લાગે છે, પણ સમસ્યા સરનામામાં છે: બે અડેપ્ટર હવે 192.168.1.0/24 નો દાવો કરે છે અને આ પ્રીફિક્સ ફક્ત એક જ રૂટ જીતી શકે છે. આ ક્રમમાં જુઓ અને કંઈપણ બદલતાં પહેલાં દેખાશે કે કયા અડેપ્ટરે તે લીધું.
લક્ષણથી શરૂ કરો, ટનલથી નહીં
સંકેત વ્યાપ છે. જો ઇન્ટ્રાનેટ કામ કરે અને દરેક સ્થાનિક ઉપકરણ નિષ્ફળ જાય, તો ટનલ સ્વસ્થ છે અને સ્થાનિક માર્ગ નથી. જો સ્થાનિક ઉપકરણો કામ કરે અને ઇન્ટ્રાનેટ નિષ્ફળ જાય, તો ઊલટું. જો એક હોસ્ટ સિવાય બધું કામ કરે, તો તમે એક એવા સરનામા સામે છો જે બંને બાજુ અસ્તિત્વમાં છે.
કોઈ સેટિંગને અડકતાં પહેલાં એક સ્થાનિક અને એક દૂરનું સરનામું લખી લો. “પ્રિન્ટર” ચકાસી શકાય તેવું નથી; 192.168.1.40 છે. એ એક જ પગલું આ સમસ્યામાં સૌથી સામાન્ય બગડેલો કલાક અટકાવે છે, જે છે રૂટિંગ નિર્ણય માટે DNS સેટિંગ ફરી લખવું.
પગલું 1: પ્રીફિક્સનો દાવો કરતા બંને અડેપ્ટર જુઓ
નેટવર્ક કનેક્શન્સ (ncpa.cpl) ખોલો અને બંને અડેપ્ટર સાથે સાથે વાંચો. Ethernet અડેપ્ટર 192.168.1.50/24 બતાવે છે, ગેટવે 192.168.1.1. VPN અડેપ્ટર 192.168.1.201/24 બતાવે છે, જે સર્વરે મોકલ્યું છે. બંને માન્ય છે, બંને માને છે કે પ્રીફિક્સ on-link છે, અને સ્ટેક તેના માટે એક જ રૂટ રાખશે.
Get-NetIPAddress -AddressFamily IPv4 સરનામાંની યાદી આપે છે, અને Get-NetIPInterface | Sort-Object InterfaceMetric એ ક્રમ બતાવે છે જેમાં સ્ટેક તેનો ઉપયોગ કરશે. એ મેટ્રિક કોલમ એ નિર્ણય છે જે તમે હમણાં વાંચવાના છો, તેથી યાદ રાખવાને બદલે આંકડા નોંધી લો.
DNS સિદ્ધાંત ખોટો છે તે સસ્તામાં સાબિત કરો: Resolve-DnsName printer.office.lan ગઈકાલે આપેલું એ જ સરનામું પરત આપે છે. નામ ઉકેલાયું; પછી પેકેટ ખોટા અડેપ્ટરમાંથી નીકળ્યું. અહીં બે મિનિટ રિઝોલ્વર સેટિંગમાં એક બપોર બચાવે છે.
પગલું 2: ખરેખર જીતેલો રૂટ વાંચો
Find-NetRoute -RemoteIPAddress 192.168.1.40 એ ઇન્ટરફેસ, આગળની હોપ અને સ્રોત છાપે છે જે સ્ટેક તે સરનામા માટે વાપરશે. એ આઉટપુટને સંકેત નહીં, જવાબ તરીકે ગણો. કઈ એન્ટ્રી હારી અને કેટલાથી તે જોવું હોય તો route print -4 આખું ટેબલ આપે છે.
વિશિષ્ટતા ઇરાદાને હરાવે છે. મોકલેલું 192.168.0.0/25 સ્થાનિક 192.168.0.0/24 ને હરાવે છે કારણ કે પ્રીફિક્સ લાંબું છે, તેથી 192.168.0.0 થી 192.168.0.127 ટનલમાંથી નીકળે છે જ્યારે ઉપરનો અડધો ભાગ સ્થાનિક રહે છે. કોઈ ભૂલ સંદેશ વગર અડધું LAN અદૃશ્ય થવું એ તે ટેબલ માટે સાચું વર્તન છે.
tracert -d 192.168.1.40 ટેબલની બહારથી તેની પુષ્ટિ કરે છે: જો પહેલી હોપ તમારા પોતાના રાઉટરને બદલે ટનલ સરનામું હોય, તો રૂટ જ આખી વાત છે. Linux પર એ જ પ્રશ્ન ip route get 192.168.1.40 છે, જે એક લીટીમાં સ્રોત સરનામું અને ઉપકરણ છાપે છે. જવાબ tun0 કહે ત્યારે બ્રાઉઝર તરફ જોવાનું બંધ કરો.
પગલું 3: ક્લાયંટને દોષ આપતાં પહેલાં પરતનો રસ્તો તપાસો
સાચો આગળનો રૂટ પણ નિષ્ફળ જાય છે જો દૂરની બાજુ જવાબ આપી શકે નહીં. જ્યારે ક્લાયંટના LAN સુધી ટનલ દ્વારા પહોંચાય છે, ત્યારે તે LANના ગેટવેને જાણવું પડે કે ટનલ પૂલ ક્યાં રહે છે: તે રાઉટર પર ip route add 10.8.0.0/24 via 192.168.1.12, અને સર્વરથી push “route 192.168.1.0 255.255.255.0” જેથી ક્લાયંટ પરતનો રસ્તો જાણે.
પહેલી એન્ટ્રી વગર જવાબ લક્ષ્યને તેના ડિફૉલ્ટ ગેટવે તરફ છોડે છે, જે ખાનગી સરનામું ISPને મોકલીને કાઢી નાખે છે. લક્ષણ એકદિશીય છે અને ખોટું વંચાય તેવું સહેલું છે: વિનંતીઓ tun0 પર દેખાય છે, જવાબ ક્યારેય નહીં.
VPN હોસ્ટ પર masquerade નિયમ તે સ્થિર રૂટની જરૂરિયાત દૂર કરે છે: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. તે અસલી સ્રોત સરનામાં પણ છુપાવે છે, જે પછીના દરેક લોગ પ્રશ્નને અઘરો બનાવે છે. ખોટા ડિફૉલ્ટ ગેટવેવાળો લક્ષ્ય હોસ્ટ એ જ મૌન પેદા કરે છે, શ્રેષ્ઠ કિસ્સામાં ICMP રીડાયરેક્ટ અને સામાન્ય કિસ્સામાં કાળો છિદ્ર, તેથી કેપ્ચર બંને છેડે લેવું જોઈએ.
પગલું 4: એવું સમારકામ પસંદ કરો જેની સાથે તમે જીવી શકો
આ માટે પાંચ સમારકામ વપરાય છે, અને તે એકબીજાના બદલે વાપરી શકાય તેવા નથી. કઈ આદેશ સૌથી ટૂંકો છે તેના પર નહીં, પણ એક સાથે શું પહોંચવા યોગ્ય રહેવું જોઈએ તેના પરથી પસંદ કરો.
| Repair | What it fixes | What it costs |
|---|---|---|
| Flip interface metrics | Alternating access: office now, home later, never both | Get-NetAdapter -Name "Ethernet 2" | Set-NetIPInterface -InterfaceMetric 21; set the VPN adapter back to 5000. A client that rewrites metrics on connect defeats it |
| Renumber one side | Every host reachable in both directions | DHCP reservations, printer queues, firewall rules and hard-coded addresses all move |
| Narrow the advertised prefix | Remote hosts really live in the upper half | Breaks the day someone adds a host below the cut |
| Translate with client-nat | Both address plans stay untouched | Stateless per-client mapping, unreadable logs, anything embedding addresses breaks |
| Publish one service with DNAT | One service on the VPN host reachable from the LAN | Both address plans stay; source addresses and reverse lookups stop being meaningful |
મેટ્રિક સૌથી સસ્તો વિકલ્પ છે અને લોકો પહેલા તેના તરફ જ હાથ લંબાવે છે. ફેરફાર ઇન્ટરફેસ પર લાગુ પડે છે, તેથી ટનલ ચાલુ હોય ત્યારે કામ કરે છે, અને તેની જગ્યા ક્લાયંટ પાસેની સ્ક્રિપ્ટમાં છે, તમે ભૂલી જશો તેવા શેલમાં નહીં. તે બે નેટવર્ક પર એક જ સરનામા સાથે એકસાથે પ્રવેશ આપી શકતું નથી, અને એ જ મર્યાદા બાકીના બધાને ટેબલ નીચે મોકલે છે.
ઘરના LANને ફરી નંબર આપવો 10.10.0.0/24 પર એ સ્વચ્છ ઉકેલ છે: એક DHCP લીઝ નવીકરણ સાથે જૂની શ્રેણીનો ઉલ્લેખ કરતા રિઝર્વેશન, પ્રિન્ટર ક્યૂ અને હાર્ડકોડેડ સરનામાં. ઓફિસની બાજુને ફરી નંબર આપવો સામાન્ય રીતે તમારો નિર્ણય નથી. IPv6 બંને નેટવર્ક ધરાવે ત્યારે અથડામણ સંપૂર્ણપણે દૂર કરે છે, યાદ રાખવા જેવી કોઈ વસ્તુને બદલે fd00::/8 માંથી અનન્ય સ્થાનિક પ્રીફિક્સ વાપરીને, પણ એપ્લિકેશન TCP પર ચકાસો, ping નહીં, કારણ કે ICMP કામ કરી શકે જ્યારે સેવા ન કરે.
OpenVPNનો પોતાનો અનુવાદ વિકલ્પ છેલ્લો ઉપાય છે, સર્વરથી ક્લાયંટ-વિશિષ્ટ ડિરેક્ટરી એન્ટ્રીમાં મોકલાય છે. વિકલ્પના નામ પછી ચાર પરિમાણ લે છે — દિશા, નેટવર્ક, નેટમાસ્ક અને ઉપનામ — અને ઉપનામ વૈકલ્પિક નથી: push "route 192.168.2.0 255.255.255.0" અને push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0". નેટવર્ક અને નેટમાસ્ક એ શ્રેણી છે જે ક્લાયંટ જુએ છે (192.168.2.0/24), ઉપનામ સર્વર બાજુની અસલી ઓફિસ શ્રેણી છે (192.168.1.0/24), અને મોકલેલો રૂટ તે દૃશ્યમાન શ્રેણીને પહોંચવા યોગ્ય બનાવે છે. પછી ઓફિસ તે ક્લાયંટને 192.168.2.x હેઠળ દેખાય છે. પ્રોફાઇલમાં મેપિંગનું દસ્તાવેજીકરણ કરો, નહીં તો આગલી વ્યક્તિ તેને રૂટિંગ ખામી તરીકે ડિબગ કરશે.
એક જ સેવા પ્રકાશિત કરવી એ અનુવાદનું સાંકડું સ્વરૂપ છે અને તેને OpenVPNના વિકલ્પની જરૂર જ નથી. VPN હોસ્ટ પરનો DNAT નિયમ એક પોર્ટ ફરી પ્રકાશિત કરે છે, તેથી LAN તેના સરનામાં રાખે છે અને જે હોસ્ટ સરનામું તે પહેલેથી જાણે છે ત્યાં સેવા સુધી પહોંચે છે. કિંમત સામાન્ય છે: સેવા VPN હોસ્ટને સ્રોત તરીકે જુએ છે, તેથી ક્લાયંટ પ્રમાણેના લોગ અને ઉલટી શોધ અર્થહીન થઈ જાય છે. તે એક પ્રિન્ટર ક્યૂ કે એક એડમિન પૃષ્ઠ આવરે છે, બંને બાજુના હોસ્ટ એકબીજા સુધી પહોંચવાનું નહીં.
શું હજુ કામ નહીં કરે, અને શું નોંધવું
બ્રોડકાસ્ટ રૂટેડ ટનલ પાર કરતું નથી. DLNA, UPnP, NetBIOS બ્રાઉઝિંગ અને Wake-on-LAN એ બ્રોડકાસ્ટ કે મલ્ટીકાસ્ટ પર આધાર રાખે છે જે tun ઉપકરણ લઈ જતું નથી, તેથી કોઈ રૂટ શોધ સુધારતું નથી. dev tap સાથે બ્રિજિંગ સેગમેન્ટ વધારે છે, અને તેની સાથે DHCP બ્રોડકાસ્ટ, ARP અને દરેક બીજું શોધ પેકેટ; દૂરના રાઉટરના LAN બાજુના સરનામા માટે route 192.168.2.1 255.255.255.255 જેવો યુનિકાસ્ટ હોસ્ટ રૂટ પસંદ કરો.
એક જ માર્ગ પર બંને 192.168.1.1 વાપરતા બે રાઉટર એ જ પ્રકારની સમસ્યા છે: સ્થાનિક સરનામું હંમેશા જીતે છે, તેથી એક LAN ખસે ત્યાં સુધી દૂરના રાઉટરનું પૃષ્ઠ પહોંચી ન શકાય તેવું રહે છે. બીજું અડેપ્ટર ઉમેરવાથી બંને કિસ્સામાં કંઈ બદલાતું નથી.
કંઈપણ સંપાદિત કરતાં પહેલાં પુરાવા નોંધો: ip route get કે Find-NetRoute, પ્રશ્નમાંના સરનામા પર ping -c 3, એક traceroute, અને ક્લાયંટ પર tcpdump -ni tun0 icmp, પછી સર્વર પર રૂટિંગ ટેબલ અને NAT કાઉન્ટર. જે ping એક દિશામાં કામ કરે અને બીજી દિશામાં મરી જાય તે પરતના રસ્તા તરફ ઇશારો કરે છે, ટનલ તરફ નહીં, અને એ એક જ ભેદ નક્કી કરે છે કે ઉપરના કયા સમારકામની તમને ખરેખર જરૂર છે.