WAN IP બદલાયું અને ટનલ તૂટી ગઈ: ક્રમમાં તપાસ
WAN ઘટના નોંધો, પછી જુઓ શું તેની પાછળ ન આવ્યું: જૂની અનુવાદ એન્ટ્રીઓ, જૂના ગેટવે સાથે જોડાયેલા રૂટ, જૂના સરનામે હજુ મોકલતા પીઅર.
ટનલ તૂટી પડે છે, રાઉટર ફરી જોડાણ નોંધે છે, અને LAN પર કંઈ ખસ્યું નથી. નવું WAN સરનામું અંદર કંઈ બદલ્યા વિના બહારના જોડાણને અમાન્ય કરે છે: ક્લાયન્ટનું સ્રોત સરનામું બદલાયું છે, જૂની NAT સ્થિતિ એવા સ્રોત તરફ ઈશારો કરે છે જે હવે નથી, અને દૂરનું પીઅર કદાચ હજુ પણ અગાઉના સરનામે મોકલે છે. પુનઃપ્રાપ્તિ સામાન્ય વર્તન છે, અને ઉપયોગી પ્રશ્ન એ છે કે કઈ સ્થિતિ અપડેટ થવામાં નિષ્ફળ ગઈ.
લોગ વાંચતા પહેલા ઘટનાને નામ આપો
ઍક્સેસ સ્તરે ખરેખર શું થયું તે તપાસો. ISP લીઝ નવીકરણ એક ઘટના છે. ફરી જોડાયેલ સત્ર PPPoE બીજી છે. રીબૂટ થયેલ ફાઇબર મોડેમ, અથવા એક અપલિંકથી બીજા સુધી WAN ફેઇલઓવર, બહારનું સરનામું અથવા તેનો માર્ગ ત્રીજી રીતે બદલે છે. તે એક જ ઘટના નથી અને તે એક જ અવશેષ છોડતી નથી.
VPN લોગમાં ફરી જોડાણની લાઇન પણ WAN ફેરફારનો પુરાવો નથી. નિષ્ક્રિય સમયમર્યાદા, ફરી પ્રમાણીકરણનો અંતરાલ અને મૃત પીઅરની શોધ — બધા કોઈ સરનામા ફેરફાર વિના ફરી જોડાણ ઉત્પન્ન કરે છે. કંઈપણ નિષ્કર્ષ કાઢતા પહેલા ઍક્સેસ લોગના સમયચિહ્નોની VPN લોગ સાથે સરખામણી કરો, અને સરખામણી વિન્ડો પૂરતી પહોળી રાખો જેથી રાત્રિ દરમિયાન થયેલો ફેરફાર પકડાય.
રોમિંગ અને ફરી જોડાણ જુદા પ્રોટોકોલ છે
WireGuard માં પ્રમાણિત રોમિંગ પ્રોટોકોલમાં જ સમાયેલું છે: જ્યારે પીઅર નવા સ્રોત સરનામેથી યોગ્ય રીતે પ્રમાણિત પેકેટ મેળવે છે, ત્યારે તે તે પીઅરનું અંતિમ બિંદુ અપડેટ કરે છે. WireGuard ઝડપી શરૂઆત તે પીઅર રૂપરેખાંકન વર્ણવે છે જે આ શક્ય બનાવે છે, તેથી બદલાતા સરનામે રહેલો ક્લાયન્ટ ઘણી વાર દેખીતા રીસ્ટાર્ટ વિના સાજો થાય છે.
OpenVPN મૂળભૂત રીતે અલગ વર્તે છે. UDP સત્ર સમાપ્ત થઈને ફરી જોડાઈ શકે છે, અને વૈકલ્પિક float વર્તન પ્રમાણિત પીઅરને જ્યાં રૂપરેખાંકન પરવાનગી આપે ત્યાં નવા સરનામેથી ચાલુ રાખવા દે છે. TCP આધારિત ટનલ વધુ કડક છે, કારણ કે જોડાણ પોતે સરનામા જોડી સાથે બંધાયેલું છે. તે ફરક નક્કી કરે છે કે પુનઃપ્રાપ્તિ અદૃશ્ય લાગશે કે દર વખતે લોગમાં જાહેર થશે.
બંને વર્તન અંદરની એપ્લિકેશનો વિશે કંઈ કહેતા નથી. પુનઃપ્રાપ્ત ટનલ એ TCP સત્ર પુનઃસ્થાપિત કરતી નથી જેને પીઅર પહેલેથી મૃત માનતું હતું.
એ સ્થિતિ જેની ટનલ માલિક નથી
અનુવાદ અને રૂટિંગ સ્થિતિ ફરી જોડાણમાંથી એવી રીતે બચી જાય છે જે લોકોને આશ્ચર્યમાં મૂકે છે. જૂના સ્રોત માટે બનાવેલ conntrack એન્ટ્રી જવાબના માર્ગને એવા સરનામે લંગરાયેલો રાખે છે જે હવે નથી, અને તે ટનલ પાછી આવી ત્યારે નહીં, પોતાના સમયપત્રક મુજબ સમાપ્ત થાય છે. ટનલ સેવાનું રીસ્ટાર્ટ તે રાહ ટૂંકાવતું નથી, તેથી સમારેલી લિંક થોડા સમય માટે હજુ તૂટેલી દેખાઈ શકે છે.
રૂટ અને નીતિ નિયમો જૂના ગેટવે અથવા ઇન્ટરફેસનો સંદર્ભ લઈ શકે છે. WAN સ્વિચ પહેલા સાચો હતો તેવો નિયમ સમૂહ હવે બંધ ઉપકરણ તરફ ઈશારો કરી શકે છે, જે એવી ટનલ બનાવે છે જે જોડાયેલ હોવાનું જણાવે છે અને ટ્રાફિક ક્યાંય જતો નથી. તમે હોસ્ટ કરો છો તે સર્વર માટે ગતિશીલ DNS નવો સ્રોત મેળવતા ક્લાયન્ટથી અલગ સમસ્યા છે. રેકોર્ડ અપડેટ કરવો પડશે જેથી દૂરના ક્લાયન્ટ તમને શોધી શકે, અને કોઈ પણ ક્લાયન્ટ-બાજુ રૂપરેખાંકન એવા સરનામાની ભરપાઈ કરતું નથી જે અપસ્ટ્રીમ અનુવાદ આગળ મોકલશે નહીં.
તપાસને બહારથી અંદરના ક્રમમાં ગોઠવો
નીચેનો ક્રમ બહારના જોડાણથી અંદર તરફ જાય છે, અને પ્રથમ નિષ્ફળ પગલે થોભવું તે જ તેને ઉપયોગી બનાવે છે: દરેક પસંદગી ઉપરના સ્તરને બાદ કરે છે. ખામી સ્પષ્ટ લાગે તોપણ આ ક્રમ રાખો.
wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40
પ્રથમ આદેશ દરેક પીઅર માટે વર્તમાન અંતિમ બિંદુ અને હેન્ડશેકની ઉંમર બતાવે છે. બીજો અને ત્રીજો બતાવે છે કે બહારનું ઇન્ટરફેસ અને અંતિમ બિંદુ સુધીનો માર્ગ હજુ અર્થપૂર્ણ છે કે નહીં. conntrack ગણતરી અગાઉના સરનામેથી બચેલી સ્થિતિ માટે ઉપરછલ્લી તપાસ છે, અને જર્નલ એ જગ્યા છે જ્યાં ફરી જોડાણનું કારણ નોંધાય છે.
પછી રાઉટરથી નહીં, LAN ક્લાયન્ટથી પરીક્ષણ કરો. રાઉટરે પોતે મોકલેલ ping ફોરવર્ડ થયેલા ટ્રાફિકથી અલગ માર્ગ વાપરે છે, તેથી સફળ રાઉટર ping સાબિત કરે છે કે ટનલ અસ્તિત્વમાં છે, અને ક્લાયન્ટની પહોંચ વિશે કંઈ નહીં.
અપેક્ષિત વર્તન નક્કી કરો અને લખો
મોટાભાગની તૈનાતી માટે ફરી જોડાવું સાચું વર્તન છે, તેથી ધ્યેય તેને રોકવાનું નથી. તેના બદલે નક્કી કરો કે અંતરાલ દરમિયાન ટ્રાફિકનું શું થવું જોઈએ: રોકવો, થોભાવવો, કે બીજા માર્ગે ફેઇલઓવર કરવો. તે નિર્ણય ફાયરવોલ અને રૂટિંગ નીતિનો છે, VPN પ્રોફાઇલનો નથી.
એક અઠવાડિયું ઍક્સેસ ઘટનાઓ અને ફરી જોડાણના સમય સાથે નોંધો. મેળ ખાતી ઍક્સેસ ઘટના વિના વારંવાર ફેરફાર ઍક્સેસ સેવા તરફ ઈશારો કરે છે, અને VPN પ્રોફાઇલ બદલવાથી વારંવાર ફરી વાટાઘાટ કરતી અપલિંક ઠીક થશે નહીં. એક જ મિનિટમાં એન્ટ્રીઓની એક જોડી તે ઘટના માટે પ્રશ્ન ઉકેલે છે અને આગલી ઘટનાને આધારરેખા આપે છે.