WireGuard હેન્ડશેક કામ કરે છે, પરંતુ ઓફિસનું સબનેટ જવાબ આપતું નથી
WireGuard ચાલુ છે અને સર્વરને પિંગ કરે છે, તો પણ તેના LAN પર કંઈ જ જવાબ આપતું નથી. ક્લાયન્ટ પ્રીફિક્સ, સર્વર ફોરવર્ડિંગ અને જવાબનો માર્ગ તપાસો.
હેન્ડશેક પૂરો થાય છે, wg show તાજેતરના ટ્રાન્સફરની જાણ કરે છે, અને સર્વરનું ટનલ સરનામું પિંગનો જવાબ આપે છે. સર્વરના LAN પરનું હોસ્ટ જવાબ આપતું નથી. ત્રણ શરતો એકસાથે પૂરી થવી જોઈએ: ક્લાયન્ટે LAN પ્રીફિક્સને ટનલમાં રૂટ કરવું જોઈએ, સર્વરે પેકેટ ફોરવર્ડ કરવા જોઈએ, અને જવાબને પાછા ફરવાનો માર્ગ જોઈએ. ત્રણમાંથી એક ખૂટે ત્યારે લક્ષણ સરખું જ રહે છે.
AllowedIPs એ એક્સેસ સૂચિ અને રૂટિંગ કોષ્ટક બંને છે
ક્લાયન્ટ પર, AllowedIPs સૂચિ નક્કી કરે છે કે તે પીઅરને શું મોકલી શકાય અને WireGuard કયા રૂટ ઇન્સ્ટોલ કરે. જે પીઅર એન્ટ્રી ફક્ત સર્વરનું ટનલ સરનામું સૂચવે છે તે એક હોસ્ટ રૂટ ઇન્સ્ટોલ કરે છે, તેથી LANના ગંતવ્યો ક્યારેય ટનલમાં પ્રવેશતા નથી. LAN પ્રીફિક્સ ઉમેરવું એ પ્રથમ તપાસવાની વસ્તુ છે, અને કોપી કરેલી ગોઠવણી પછી સૌથી વધુ ખૂટતો ફેરફાર પણ એ જ છે. ડિફોલ્ટ રૂટ સુધી વિસ્તારેલો પીઅર અલગ રચના છે, અને તે ક્લાયન્ટનો ઇન્ટરનેટ ટ્રાફિક પણ ખસેડશે.
હોસ્ટ રૂટ અને LAN પ્રીફિક્સને અલગ એન્ટ્રી તરીકે રાખો. જો ઓફિસમાં બે સબનેટ હોય, તો બંને સૂચિમાં આવે છે, અને ખૂટતો બીજો પ્રીફિક્સ એવી નિષ્ફળતા ઉત્પન્ન કરે છે જે સંપૂર્ણ નહીં પણ પસંદગીની લાગે છે.
[Peer] PublicKey = <server public key> Endpoint = vpn.example.net:51820 AllowedIPs = 10.66.0.1/32, 192.168.50.0/24
ફોરવર્ડિંગ અને ભાષાંતર સર્વર પર જ હોવું જોઈએ
સર્વરને IP ફોરવર્ડિંગ સક્ષમ, ટનલમાંથી આવતા ટ્રાફિકને સ્વીકારતો ફોરવર્ડ નિયમ, અને તેના LAN ઇન્ટરફેસ તરફનો ભાષાંતર નિયમ જોઈએ. ભાષાંતર જ ઓફિસ નેટવર્કના દરેક હોસ્ટને સ્પર્શ્યા વિના રચનાને કામ કરાવે છે. પછી જવાબો LAN ક્યારેય સાંભળ્યું ન હોય એવા સરનામે નહીં, સર્વર પર પાછા આવે છે. તેના વિના, દરેક હોસ્ટને ટનલ સબનેટ માટે રૂટ અને તેને મંજૂરી આપતો ફાયરવોલ નિયમ જોઈએ, જે બીજા કોઈના સંચાલિત નેટવર્ક પર ભાગ્યે જ સ્વીકાર્ય હોય છે.
sysctl -w net.ipv4.ip_forward=1 iptables -A FORWARD -i wg0 -j ACCEPT iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
હાથે ઉમેરેલા નિયમો રીબૂટ પર અદૃશ્ય થાય છે, તેથી સર્વર ગોઠવણીના hook આદેશોથી તેમને ઇન્ટરફેસ સાથે બાંધો. જે નિયમ સમૂહ તેના ઇન્ટરફેસ કરતાં વધુ ટકે છે, તે રીતે મશીન એવી ટનલ માટે ટ્રાફિકનું ભાષાંતર કરવા લાગે છે જે હવે અસ્તિત્વમાં નથી.
જ્યારે LAN ખસી ગયું અને નિયમ નહીં
ઓફિસ સબનેટનું પુનઃક્રમાંકન કરતું રાઉટર બદલવું આ નિષ્ફળતાનું ઉત્તમ ઉદાહરણ છે. ટનલ ચાલુ રહે છે, હેન્ડશેક તાજું રહે છે, અને સર્વર પાછળ કંઈ જ જવાબ આપતું નથી, કારણ કે ભાષાંતર નિયમ હજી જૂનું સરનામું કહે છે. ઇન્સ્ટોલર સ્ક્રિપ્ટો ઘણી વાર સર્વરના LAN સરનામાને POSTROUTING નિયમમાં ઉમેરી દે છે, અને પુનઃક્રમાંકન પછી તે સરનામું કોઈ ઇન્ટરફેસ પર હોતું નથી. પછી પેકેટ એવા ગંતવ્ય તરફ ફરી લખાય છે જે જવાબ આપી શકતું નથી.
iptables -t nat -n -L POSTROUTING ip -br addr show
બે આઉટપુટની સરખામણી કરો. ઇન્ટરફેસ સૂચિમાં ન દેખાતું ભાષાંતર લક્ષ્ય એ જ ખામી છે, અને એક વાર જોઈ લીધા પછી તેને સુધારવું એક લીટીનો ફેરફાર છે. નિયમ WireGuard ગોઠવણીમાં નહીં પણ જનરેટ થયેલા unitમાં હોઈ શકે, તેથી સંપાદન પછી તે unit ફરી લોડ કરો અને ખાતરી કરો કે આગલું બૂટ તમારો ફેરફાર ફરી લખતું નથી.
NAT પાછળની બે સાઇટને મળવાનું સ્થળ જોઈએ
જ્યારે કોઈ પણ પક્ષ આવતા જોડાણો સ્વીકારતું નથી, ત્યારે વ્યવહારુ જવાબ છે જાહેર સરનામું અને બે WireGuard ઇન્ટરફેસ ધરાવતું નાનું હોસ્ટ. દરેક સાઇટ બહાર તરફ જોડાય છે, વચ્ચેનું હોસ્ટ દરેક પીઅરનું LAN પોતાના AllowedIPs, એટલે કે પોતાની સૂચિમાં, સૂચિબદ્ધ કરે છે, અને ફોરવર્ડિંગ બે ટનલ વચ્ચે પેકેટ લઈ જાય છે. કોઈ પણ સાઇટના ફાયરવોલમાં કંઈ બદલવાની જરૂર નથી, તેથી આ રચના સરળતાથી ફેલાય છે.
સાઇટો વચ્ચેનું રૂટિંગ મૂળ સ્રોત સરનામાં જાળવી રાખે છે અને તેથી પ્રતિ-હોસ્ટ લોગિંગ અર્થપૂર્ણ રાખે છે. જ્યારે બે LAN એકબીજા પર ઓવરલેપ થાય ત્યારે વચ્ચેના હોસ્ટ પર ભાષાંતર કરવું સરળ છે, પરંતુ લોગમાં સ્રોત ઓળખ ગુમાવવાની કિંમતે. પસંદ કરતા પહેલાં નક્કી કરો કે કઈ મિલકત મહત્વની છે.
ચાર તપાસ સાથે સ્તરોને અલગ કરો
ત્રણ વસ્તુ બદલીને આશા રાખવાને બદલે દરેક સ્તર માટે એક તપાસ કરો. પ્રથમ દરેક પીઅર માટે હેન્ડશેકની ઉંમર અને કાઉન્ટર બતાવે છે. બીજું બતાવે છે કે ક્લાયન્ટ ખરેખર તે ગંતવ્યને ટનલમાં રૂટ કરે છે કે નહીં. ત્રીજું અને ચોથું જણાવે છે કે વિનંતી પહોંચી કે નહીં અને પહોંચ્યા પછી કોઈ નીતિએ તેને કાઢી નાખી કે નહીં.
wg show ip route get 192.168.50.20 tcpdump -ni wg0 icmp iptables -vnL FORWARD --line-numbers
જે વિનંતી પહોંચે છે પણ કોઈ જવાબ લાવતી નથી તે જવાબના માર્ગ તરફ અથવા LAN હોસ્ટ તરફ નિર્દેશ કરે છે. જે વિનંતી ક્યારેય પહોંચતી નથી તે AllowedIPs અથવા ક્લાયન્ટના રૂટ તરફ નિર્દેશ કરે છે. આ બે પરિણામોને અલગ સુધારા જોઈએ, અને કેપ્ચર જ તેમને અલગ પાડે છે.