VPN സർവർ ഒരു പുതിയ പൊതു IP ലേക്ക് മാറ്റുന്നത്: ആദ്യം എന്ത് പരിശോധിക്കണം
സ്ഥലത്തെ മാറ്റിസ്ഥാപിക്കലും സമാന്തര കട്ട്ഓവറും വ്യത്യസ്ത സ്ഥലങ്ങളിൽ തകരുന്നു. കോൺഫിഗറേഷനുകൾ, NAT, സർട്ടിഫിക്കറ്റുകൾ എന്നിവ പരിശോധിച്ച്, ഓരോ ക്ലയന്റും പേര് എങ്ങനെ പരിഹരിക്കുന്നു എന്ന് നോക്കുക.
ഒരു വിലാസം വീണ്ടും അനുവദിക്കാൻ ഒരു മിനിറ്റ് എടുക്കും. അടുത്ത ആഴ്ചയാണ് മാറ്റം തകരുന്ന സ്ഥലം, ദാതാവിന്റെ കൺസോൾ സൂചിപ്പിക്കുന്ന സ്ഥലത്ത് അപൂർവ്വമായേ. പുതിയ പൊതു IP നാല് സ്ഥലങ്ങളിൽ പരാമർശിക്കുന്നു: ഡീമൺ കേൾക്കുന്ന സോക്കറ്റ്, ക്ലയന്റുകൾ പരിശോധിക്കുന്ന വിശ്വാസ ആങ്കർ, പഴയ വിലാസം പേരിടുന്ന ഓരോ നിയമവും, കൂടാതെ അവയെ ബന്ധിപ്പിക്കുന്ന DNS റെക്കോർഡും. രണ്ട് മാറ്റങ്ങൾ നിയന്ത്രണ പാനലിൽ ഒരുപോലെ തോന്നുമെങ്കിലും തികച്ചും വ്യത്യസ്തമായി പ്രവർത്തിക്കുന്നു: നിങ്ങൾ പ്രവർത്തിപ്പിക്കുന്ന യന്ത്രത്തിൽ വിലാസം വീണ്ടും അനുവദിക്കുക, അല്ലെങ്കിൽ രണ്ടാമത്തെ എൻഡ്പോയിന്റ് നിർത്തി ക്ലയന്റുകളെ അങ്ങോട്ട് മാറ്റുക. താഴെയുള്ള പരിശോധനകൾ വിലകുറഞ്ഞ പരാജയങ്ങൾ ആദ്യം വയ്ക്കുന്നു, ഓരോ ഭാഗവും ഏത് മാറ്റത്തിന് ബാധകമെന്ന് പറയുന്നു.
സ്ഥലത്തെ മാറ്റിസ്ഥാപിക്കലും സമാന്തര കട്ട്ഓവറും വ്യത്യസ്ത ജോലികളാണ്
സ്ഥലത്തെ മാറ്റിസ്ഥാപിക്കൽ ഹോസ്റ്റ്, കീകൾ, റൂട്ടിംഗ് പട്ടിക, ഉപയോക്തൃ പട്ടിക എന്നിവ നിലനിർത്തുന്നു; വിലാസം മാത്രമാണ് മാറുന്നത്. ഫ്ലോട്ടിംഗ് IP യുടെ വീണ്ടും അനുവദിക്കൽ ഇതാണ് ചെയ്യുന്നത്, പല ദാതാക്കളിലും അതിഥി ഇത് ശ്രദ്ധിക്കുന്നേയില്ല, കാരണം വിവർത്തനം ഇൻസ്റ്റൻസിന് മുന്നിൽ നടക്കുന്നു. പുനർനിർമ്മാണമോ ദാതാവിന്റെ വീണ്ടും അനുവദിക്കലോ കൂടുതൽ കഠിനമാണ്: അതിഥി മാറ്റം കാണുന്നു, പഴയ മൂല്യം കാഷെ ചെയ്ത എല്ലാം അതേ നിമിഷത്തിൽ അത് അറിയുന്നു.
സമാന്തര എൻഡ്പോയിന്റ് എന്നത് അതേ ജോലി ചെയ്യുന്ന രണ്ടാമത്തെ ഹോസ്റ്റാണ്. അത് നിർമ്മിച്ച്, ഒരു പ്രൊഫൈൽ ഉപയോഗിച്ച് പരിശോധിച്ച്, പുതിയത് യഥാർത്ഥ പാതയിൽ സ്വയം തെളിയിക്കുന്നതുവരെ പഴയതിനെ ഉത്തരം നൽകാൻ അനുവദിക്കുക. വില അവസ്ഥയാണ്. പങ്കിട്ട peer എൻട്രികൾ, റദ്ദാക്കലുകൾ, ലോഗിംഗ് എന്നിവയില്ലാതെ യാദൃച്ഛികമായി ഒരേ പേര് പങ്കിടുന്ന രണ്ട് നെറ്റ്വർക്കുകളാണ് നിങ്ങൾക്കുള്ളത്.
| Question | In-place swap | Parallel endpoint |
|---|---|---|
| Rollback in one step? | Only if you can get the old address back | Point DNS back; old host still up |
| Blast radius | Every client at once | Only the clients you moved |
| Best when | The address is yours to reassign | The old address is gone for good |
പഴയ വിലാസം എഴുതിയിരിക്കുന്ന ഓരോ സ്ഥലവും കണ്ടെത്തുക
ടെക്സ്റ്റ് സ്കാനിൽ തുടങ്ങുക, കാരണം കോൺഫിഗറേഷൻ ഫയലുകളാണ് എളുപ്പമുള്ള പകുതി. ഡീമൺ കോൺഫിഗ്, ഫയർവാൾ ഭാഗങ്ങൾ, മോണിറ്ററിംഗ് ലക്ഷ്യങ്ങൾ, ഡിസ്കിലുള്ള ഏതെങ്കിലും സൃഷ്ടിച്ച ക്ലയന്റ് ബണ്ടിൽ എന്നിവ തിരയുക. നിങ്ങൾ ഒരു IPv6 വിലാസം പ്രസിദ്ധീകരിക്കുന്നുണ്ടെങ്കിൽ അതും ഉൾപ്പെടുത്തുക; A റെക്കോർഡ് മാത്രം പിന്തുടരുന്ന മാറ്റം ഇരട്ട-സ്റ്റാക്ക് ക്ലയന്റുകളെ പഴയ പാതയിൽ ഉപേക്ഷിക്കുന്നു.
OLD=203.0.113.10
grep -RIn -- "$OLD" /etc /root
ss -lunpt | grep -F "$OLD"
nft list ruleset | grep -F "$OLD"
iptables-save | grep -F "$OLD"
wg show all endpoints
പിന്നീട് കെർണൽ സ്കാൻ ചെയ്യുക, കാരണം പ്രവർത്തിക്കുന്ന സിസ്റ്റം വിലാസം ഒരു ഫയലും പരാമർശിക്കാത്ത സ്ഥലങ്ങളിൽ സൂക്ഷിക്കുന്നു. സ്റ്റാറ്റിക് സ്രോതസ്സ് NAT നിയമം, ipset എൻട്രി, bind വിലാസം, conntrack എൻട്രി എന്നിവ അവ നീക്കിയ കോൺഫിഗ് മാറ്റത്തെക്കാൾ കൂടുതൽ കാലം നിലനിൽക്കുന്നു, ചിലത് സംരക്ഷിച്ച നിയമക്കൂട്ടത്തിൽ നിന്ന് തിരികെ വന്നതിനാൽ റീബൂട്ടും അതിജീവിക്കുന്നു. ഒരു പാളി മുകളിൽ, ദാതാവിന്റെ സുരക്ഷാ ഗ്രൂപ്പുകൾ, ലോഡ് ബാലൻസർ ലക്ഷ്യങ്ങൾ, മോണിറ്ററിംഗ് പരിശോധനകൾ എന്നിവ നിങ്ങളുടെ ഫയൽ സിസ്റ്റത്തിൽ ഒട്ടുമില്ല.
എന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ് ഇൻവെന്ററി എഴുതിവയ്ക്കുക; അത് റോൾബാക്ക് സ്ക്രിപ്റ്റായും പ്രവർത്തിക്കുന്നു.
ഹോസ്റ്റ്നെയിം ക്ലയന്റുകൾ കരകയറുന്നു; അക്ഷരാർത്ഥ IP ക്ലയന്റുകൾ നിശ്ശബ്ദമാകുന്നു
ക്ലയന്റുകൾ ഹോസ്റ്റ്നെയിം വഴി സർവറിൽ എത്തുന്നുവെങ്കിൽ, കട്ട്ഓവർ പ്രധാനമായും ഒരു DNS പ്രശ്നമാണ്, ഇന്നലെ സജ്ജീകരിച്ച TTL എത്ര മോശമാകുമെന്ന് തീരുമാനിക്കുന്നു. റിസോൾവറുകൾ കാഷെ ചെയ്യുന്നു, സ്റ്റബ് റിസോൾവറുകൾ വീണ്ടും കാഷെ ചെയ്യുന്നു, പല ക്ലയന്റുകളും പേര് പുതിയ കണക്ഷനിൽ മാത്രം തിരയുന്നു, അതിനാൽ സ്ഥാപിതമായ ടണൽ അതിന്റെ ആരംഭ വിലാസം നിലനിർത്തുന്നു.
എൻഡ്പോയിന്റ് അക്ഷരാർത്ഥ വിലാസമാണെങ്കിൽ, ഒന്നും വീണ്ടും പരിഹരിക്കുന്നില്ല, ഒന്നും പരാതി രേഖപ്പെടുത്തുന്നില്ല. WireGuard പരിഹരിച്ച സോക്കറ്റ് വിലാസം സംഭരിക്കുന്നു: Endpoint = vpn.example.net:51820 wg-quick up പ്രവർത്തിക്കുന്ന നിമിഷം IP ആകുന്നു, നിങ്ങൾ അത് മാറ്റുന്നതുവരെ അതേ IP ആയി തുടരുന്നു. OpenVPN കൂടുതൽ സഹിഷ്ണുതയുള്ളതാണ്: അത് കണക്ഷൻ സമയത്ത് remote ഹോസ്റ്റ്നെയിം പരിഹരിക്കുന്നു, resolv-retry infinite ഉപയോഗിച്ച് വീണ്ടും കണക്ഷനിൽ DNS വീണ്ടും ശ്രമിക്കുന്നു. അക്ഷരാർത്ഥ IP നൽകിയാൽ, രണ്ടും ഇനി ഇല്ലാത്ത ഒരു യന്ത്രത്തിലേക്ക് ഡയൽ ചെയ്യുന്നു.
ആളുകളെ തെറ്റിദ്ധരിപ്പിക്കുന്നത് കണ്ണാടി പ്രതിബിംബമാണ്. പുതിയ വിലാസത്തിലേക്ക് ഇതിനകം ചൂണ്ടിക്കാണിക്കുന്ന ഒരു ക്ലയന്റ്, പഴയ ശ്രോതാവ് ഇപ്പോഴും ഉത്തരം നൽകുമ്പോൾ, നിങ്ങളുടെ സ്വന്തം മേശയിൽ നിന്ന് നടത്തുന്ന എല്ലാ പരീക്ഷണവും വിജയിക്കുന്നു. ഞാനും ഇതിൽ വഞ്ചിക്കപ്പെട്ടു: പുതിയ എൻഡ്പോയിന്റ് ഒരു ഫോണിൽ ആദ്യ ശ്രമത്തിൽ തന്നെ ഉയർന്നു, പഴയ പ്രൊഫൈലുള്ള ഒരു ക്ലയന്റ് പഴയ ശ്രോതാവ് വളരെ വൈകി ഓഫ് ചെയ്തപ്പോൾ മാത്രമാണ് പുറത്തുവന്നത്.
വിശ്വാസം വിലാസത്തോടൊപ്പം നീങ്ങുന്നില്ല
WireGuard ഐഡന്റിറ്റിയെ ലഭ്യതയിൽ നിന്ന് വേർതിരിക്കുന്നു, ഇത് വിലാസ മാറ്റം ഏതാണ്ട് സൗജന്യമാക്കുന്നു. peer-കൾ പൊതു കീ ഉപയോഗിച്ച് തിരിച്ചറിയപ്പെടുന്നു, എൻഡ്പോയിന്റ് പാക്കറ്റുകൾ ഇപ്പോൾ പോകുന്ന സ്ഥലം മാത്രമാണ്; അവസാനം പ്രാമാണീകരിച്ച പാക്കറ്റിന്റെ സ്രോതസ്സ് വിലാസത്തിൽ നിന്ന് ഹോസ്റ്റ് peer-ന്റെ എൻഡ്പോയിന്റ് പുതുക്കുന്നു. നിഷ്ക്രിയ peer-ന് പുതിയ സ്ഥലവുമായി സംസാരിക്കാൻ കാരണം വേണം, അതിന്റെ സെഷൻ പഴകി handshake വീണ്ടും ശ്രമങ്ങൾ ദൃശ്യമായ ഒരിടത്ത് പരാജയപ്പെടുമ്പോൾ മാത്രമാണ് വിലാസം പഠിക്കുന്നത്. WireGuard ദ്രുത മാർഗ്ഗദർശി എൻഡ്പോയിന്റ് ഫീൽഡ് ഉൾക്കൊള്ളുന്നു.
TLS അടിസ്ഥാനമാക്കിയ സർവറുകൾ വിപരീത സന്ദർഭമാണ്. സർട്ടിഫിക്കറ്റ് ഒരു പേരിലേക്ക് ബന്ധിച്ചിരിക്കുന്നു, വിലാസം ഡയൽ ചെയ്യുന്ന ക്ലയന്റ് താൻ ഡയൽ ചെയ്തതിനെ വിഷയത്തിന്റെ ബദൽ പേരുകളുമായി താരതമ്യം ചെയ്യുന്നു. DNS SAN മാത്രം വഹിക്കുന്ന സർട്ടിഫിക്കറ്റിലേക്ക് IP വഴി ബന്ധിപ്പിക്കുക, പരിശോധന പരാജയപ്പെടുന്നു: ക്ലയന്റ് ഉപയോഗിച്ച പേര് സർട്ടിഫിക്കറ്റിൽ ഇല്ല. IP SAN ഉപയോഗിച്ച് പുനർനിർമ്മിക്കൽ ആ ഒരു കണക്ഷൻ ശരിയാക്കുന്നു, അടുത്ത മാറ്റത്തെ മോശമാക്കുന്നു. പ്രൊഫൈലിൽ ഹോസ്റ്റ്നെയിം നിലനിർത്തി verify-x509-name അതിന്റെ സ്ഥാനത്ത് വിടുന്നത് താഴെയുള്ള വിലാസം മാറുമ്പോഴും പരിശോധന കർശനമായി നിലനിർത്തുന്നു.
തുടർന്ന് ഡീമൺ എന്തിനോട് ബന്ധിച്ചിരിക്കുന്നു എന്ന് പരിശോധിക്കുക; പഴയ വിലാസത്തിൽ പിൻ ചെയ്ത സോക്കറ്റ് നിശ്ശബ്ദമായി പരാജയപ്പെടുന്നു. local 203.0.113.10 ഉപയോഗിച്ച് ആരംഭിച്ച OpenVPN സർവർ ആ വിലാസം പോയാൽ ഉയരാൻ വിസമ്മതിക്കുന്നു, 0.0.0.0 ലുള്ള ശ്രോതാവ് മാറ്റം സൗജന്യമായി പിന്തുടരുന്നു. NAT ഉം അതേ രീതിയിൽ പിളരുന്നു: MASQUERADE യന്ത്രത്തിന് ഇപ്പോൾ ഉള്ള ഏത് വിലാസവും പിന്തുടരുന്നു, സ്റ്റാറ്റിക് SNAT --to-source 203.0.113.10 ഇനി നിങ്ങളുടേതല്ലാത്ത വിലാസത്തിലേക്ക് വീണ്ടും എഴുതുന്നു, അതിനാൽ മടങ്ങിവരുന്ന ട്രാഫിക് അപ്രത്യക്ഷമാകുന്നു. പുതിയ വിലാസം വേറെ അപ്സ്ട്രീം ഗേറ്റ്വേയോടെ വന്നാൽ, rp_filter പരിശോധിക്കുക: റിവേഴ്സ്-പാത്ത് ഫിൽട്ടറിംഗ് കെർണൽ പ്രതീക്ഷിക്കാത്ത ഇന്റർഫേസിൽ എത്തുന്ന മടങ്ങിവരുന്ന ട്രാഫിക് ഉപേക്ഷിക്കുന്നു.
കട്ട്ഓവർ ക്രമവും അത് പ്രവർത്തിച്ചതിന്റെ തെളിവുകളും
ഒരു ദിവസം മുൻപ് TTL കുറയ്ക്കുക, പുതിയ ശ്രോതാവ് നിർത്തുക, നിങ്ങൾക്ക് മാത്രമുള്ള ഒരു പ്രൊഫൈൽ ഉപയോഗിച്ച് അത് തെളിയിക്കുക. ഒരേ നെറ്റ്വർക്കിനുള്ളിൽ നിന്നുള്ള പരീക്ഷണം ഏതാണ്ട് ഒന്നും തെളിയിക്കുന്നില്ല, അതിനാൽ സെല്ലുലാറിലുള്ള ഒരു ഫോൺ ഉപയോഗിച്ച്, എൻഡ്പോയിന്റിലേക്ക് പിംഗ് ചെയ്യുന്നതിന് പകരം ടണൽ കൊണ്ടുപോകേണ്ടത് പരിശോധിക്കുക.
മുഴുവൻ കാലയളവിലും രണ്ട് വിലാസങ്ങളും നിരീക്ഷിക്കുക. പുതിയ ഹോസ്റ്റിലെ wg show all latest-handshakes, അല്ലെങ്കിൽ OpenVPN സ്റ്റാറ്റസ് ഫയൽ, എത്ര peer-കൾ യഥാർത്ഥത്തിൽ മാറിയെന്ന് പറയുന്നു. പുതിയ എൻഡ്പോയിന്റിൽ പ്രതീക്ഷിച്ച peer-കൾ ഉണ്ടായിരിക്കുകയും പഴയതിൽ പിന്നിലായവർ മാത്രം ഉണ്ടായിരിക്കുകയും ചെയ്താൽ, പഴയ ശ്രോതാവിനെ വിരമിക്കുക, പഴയ NAT നിയമം നീക്കം ചെയ്യുക, ദാതാവിന്റെ ഫയർവാളിൽ നിന്ന് വിലാസം ഒഴിവാക്കുക. പഴയ ശ്രോതാവിനെ നീക്കം ചെയ്യുന്നതാണ് ഒഴിവാക്കപ്പെടുന്ന ഘട്ടം, അത് പഴയ പ്രൊഫൈൽ ഇപ്പോഴും പഴയ നെറ്റ്വർക്കിൽ എത്തുന്ന വിടവ് അടയ്ക്കുന്നു.
തുടങ്ങുന്നതിന് മുൻപ് റോൾബാക്ക് ട്രിഗർ രേഖാമൂലം നിശ്ചയിക്കുക: സമ്മതിച്ച കാലയളവിന് ശേഷം പുതിയ എൻഡ്പോയിന്റിന് ഒരു യഥാർത്ഥ ക്ലയന്റിൽ നിന്നും handshake ലഭിക്കുന്നില്ലെങ്കിൽ, പഴയ വിലാസം പുനഃസ്ഥാപിച്ച് പ്രൊഫൈൽ വിതരണം നിർത്തുക. തുടർന്ന് സ്കാൻ വീണ്ടും പ്രവർത്തിപ്പിച്ച്, വിരമിച്ച വിലാസത്തിൽ ഒരു ശ്രോതാവും ബന്ധിച്ചിട്ടില്ലെന്ന് ഉറപ്പാക്കുക. രണ്ട് കാര്യങ്ങൾ അടുത്ത മാറ്റത്തിലേക്ക് പോകുന്നു: അടുത്ത മാറ്റം DNS തിരുത്തലാകാൻ ക്ലയന്റ് പ്രൊഫൈലിലെ ഹോസ്റ്റ്നെയിം, സർവറിന്റെ വീണ്ടെടുക്കൽ കുറിപ്പുകൾക്കൊപ്പം സൂക്ഷിക്കുന്ന ഇൻവെന്ററി.