സൈറ്റ്-ടു-സൈറ്റ് VPN-ലേക്ക് രണ്ടാമത്തെ സബ്നെറ്റ് ചേർക്കൽ: രണ്ട് വഴികൾ
പോളിസി അടിസ്ഥാനമാക്കിയ ടണലുകൾക്ക് ഇരുവശത്തും പൊരുത്തപ്പെടുന്ന സെലക്ടറുകൾ വേണം; റൂട്ട് അടിസ്ഥാനമാക്കിയവയ്ക്ക് ഒരു റൂട്ട് വേണം. ശരിയായ വഴി തിരഞ്ഞെടുത്ത് ആദ്യം തിരിച്ചുവരവ് റൂട്ട് ശരിയാക്കുക.
പ്രവർത്തിക്കുന്ന സൈറ്റ്-ടു-സൈറ്റ് ടണലിലേക്ക് രണ്ടാമത്തെ സബ്നെറ്റ് ചേർക്കാൻ ഒരു ഡിസൈനിൽ അഞ്ച് മിനിറ്റും മറ്റൊന്നിൽ ഏതാണ്ട് പൂർണ്ണ ഉച്ചകഴിഞ്ഞും വേണം. ടണൽ നിങ്ങൾ നൽകുന്ന പ്രിഫിക്സുകൾക്ക് റൂട്ടുകൾ ഇൻസ്റ്റാൾ ചെയ്യുമ്പോൾ നിങ്ങൾ ഒരു റൂട്ട് ചേർക്കുന്നു, ട്രാഫിക് അതിനെ പിന്തുടരുന്നു. ഒരു നിശ്ചിത സെലക്ടർ ജോടിയിൽ ചർച്ച ചെയ്യുമ്പോൾ, ഇരുവശവും പൊരുത്തപ്പെടുന്ന ജോടിയിൽ സമ്മതിക്കുന്നതുവരെ പുതിയ പ്രിഫിക്സ് സംരക്ഷണമില്ലാതെ തുടരും. മൂന്ന് കാര്യങ്ങൾ തീരുമാനിക്കുന്നു: ഓരോ വശത്തിന്റെയും കോൺഫിഗറേഷൻ യഥാർത്ഥത്തിൽ എന്ത് വിവരിക്കുന്നു, ചർച്ച ചെയ്ത ട്രാഫിക് ഏറ്റവും ചെറിയ പൊരുത്തപ്പെടുന്ന ജോടിയിലേക്ക് ചുരുങ്ങുന്നുണ്ടോ, ഏത് പുതിയ ശ്രേണിയുടെ തിരിച്ചുവരവ് വഴി ഉടമസ്ഥതയിലാണ്.
സ്റ്റാറ്റസ് ലേബലല്ല, കെർണൽ വായിക്കുക
കണക്റ്റുചെയ്തതായി റിപ്പോർട്ട് ചെയ്യുന്ന ടണൽ കുറഞ്ഞത് ഒരു ചൈൽഡ് അസോസിയേഷൻ ഇൻസ്റ്റാൾ ചെയ്തിട്ടുണ്ട്, പക്ഷേ നിങ്ങൾ കരുതുന്നതായിരിക്കണമെന്നില്ല. Linux-ൽ കെർണൽ എന്താണ് പ്രയോഗിക്കുന്നതെന്ന് കാണിക്കുന്നു: ip xfrm policy സെലക്ടർ ജോടികൾ ലിസ്റ്റ് ചെയ്യുന്നു, swanctl --list-sas (അല്ലെങ്കിൽ പഴയ ipsec statusall) ഓരോ ദിശയിലെയും ട്രാഫിക് സെലക്ടറുകൾ ഉൾപ്പെടെ ഇരുവശവും ചർച്ച ചെയ്തത് കാണിക്കുന്നു. പുതിയ പ്രിഫിക്സ് ഇവയൊന്നത്തിലും ഇല്ലെങ്കിൽ, കോൺഫിഗർ ഫയൽ എന്ത് പറഞ്ഞാലും അതിന് സംരക്ഷണമില്ല.
ഇത് റൂട്ട് ടേബിളുമായി താരതമ്യം ചെയ്യുക. റൂട്ട് അടിസ്ഥാനമാക്കിയ ക്രമീകരണത്തിൽ സംരക്ഷിത പ്രിഫിക്സുകൾക്കുള്ള അടുത്ത ഹോപ്പ് ടണൽ ഉപകരണമാണ്. പോളിസി അടിസ്ഥാനമാക്കിയ ക്രമീകരണത്തിൽ ദൂരെയുള്ള സബ്നെറ്റിന് പ്രത്യേക റൂട്ട് പലപ്പോഴും ഉണ്ടാകില്ല, ഡിഫോൾട്ട് റൂട്ട് മാത്രം, കാരണം ട്രാഫിക് തിരഞ്ഞെടുക്കുന്നത് പോളിസിയാണ്, ടേബിളല്ല.
പോളിസി അടിസ്ഥാനമാക്കിയവ: ഇരുവശവും പുതിയ പ്രിഫിക്സ് ലിസ്റ്റ് ചെയ്യണം
strongSwan പദങ്ങളിൽ സെലക്ടർ ചൈൽഡ് കോൺഫിഗറേഷനിലെ local_ts, remote_ts എന്നിവയിലാണ്, leftsubnet, rightsubnet എന്നിവയുടെ പിൻഗാമികൾ. പുതിയ പ്രിഫിക്സ് ഇരുവശത്തും കണ്ണാടിപോലെ വേണം: സൈറ്റ് A ലോക്കൽ എന്ന് വിളിക്കുന്നതിനെ സൈറ്റ് B ദൂരെ എന്ന് വിളിക്കുന്നു. പൊരുത്തക്കേട് അപൂർവ്വമായി വ്യക്തമായ പിശക് നൽകുന്നു. വശങ്ങൾ ഇന്റർസെക്ഷനിലേക്ക് ചുരുങ്ങുന്നു, പഴയ പ്രിഫിക്സ് പ്രവർത്തിക്കുന്നു, പുതിയത് മാത്രം നിശബ്ദമായി പരാജയപ്പെടുന്നു.
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policypfSense അല്ലെങ്കിൽ OPNsense-ൽ ഇത് പുതിയ ലോക്കൽ സബ്നെറ്റ് പുതിയ ദൂരെ സബ്നെറ്റുമായി ജോടിയാക്കുന്ന രണ്ടാമത്തെ Phase 2 എൻട്രി, തുടർന്ന് പ്രയോഗം എന്നാണ് അർത്ഥം. പഴയ എൻട്രി നിലനിർത്തുക; മാറ്റിസ്ഥാപിക്കുന്നത് യഥാർത്ഥ സബ്നെറ്റ് ചേർക്കുന്നതിനുപകരം നീക്കുന്നു. നിലവിലുള്ള Phase 2 ഇതിനകം 0.0.0.0/0 പോലുള്ള സൂപ്പർനെറ്റോ സംഗ്രഹിച്ച ശ്രേണിയോ ഉൾക്കൊള്ളുന്നുവെങ്കിൽ, അതിനടുത്ത് ഇടുങ്ങിയ എൻട്രി ചേർക്കരുത്: ഓവർലാപ്പിംഗ് സെലക്ടറുകൾ മത്സരിക്കുന്ന പോളിസികൾ ഇൻസ്റ്റാൾ ചെയ്യുന്നു, വിലയിരുത്തൽ ക്രമമാണ് വിജയിയെ തീരുമാനിക്കുന്നത്.
IKEv1 ഓരോ സബ്നെറ്റ് ജോടിയെയും സ്വന്തം Phase 2 ആക്കുന്നു, ഓരോ കൈമാറ്റത്തിനും ഒരു ജോടി സ്വീകരിക്കുന്ന വശം ബാക്കിയുള്ളവ ഉപേക്ഷിക്കുന്നു. IKEv2 ഒരു ചൈൽഡിൽ നിരവധി സെലക്ടർ ജോടികൾ കൊണ്ടുപോകാം, എന്നാൽ രണ്ട് ഇംപ്ലിമെന്റേഷനുകളും സ്വീകരിച്ചാൽ മാത്രം. swanctl --list-sas എന്നതിൽ നിന്നുള്ള ലിസ്റ്റാണ് സത്യം; നിങ്ങൾ ടൈപ്പ് ചെയ്തത് ഒരു അഭ്യർത്ഥനയാണ്.
റൂട്ട് അടിസ്ഥാനമാക്കിയവ: റൂട്ടാണ് പോളിസി
XFRM ഇന്റർഫേസോ VTI ഉപകരണമോ റൂട്ട് ടേബിൾ അനുസരിച്ച് ട്രാഫിക് കൊണ്ടുപോകുന്നു. പുതിയ പ്രിഫിക്സ് രണ്ട് സൈറ്റുകളിലും ഉപകരണത്തിലേക്ക് തിരിച്ചുവിടുന്നു, ഇന്റർഫേസിന്റെ പരിവർത്തനത്തിൽ ബന്ധിപ്പിച്ച അവസ്ഥ പ്രയോഗിക്കുന്നു. സമന്വയിപ്പിക്കാൻ സെലക്ടർ ജോടിയില്ല, അതിനാൽ സബ്നെറ്റുകൾ വർദ്ധിക്കുമ്പോൾ ഈ ഡിസൈൻ നന്നായി സ്കെയിൽ ചെയ്യുന്നു. strongSwan ഫോർവേഡിംഗ് ഗൈഡ് കെർണൽ വശം വിശദമായി പറയുന്നു.
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10WireGuard കൂടുതൽ മുന്നോട്ട് പോകുന്നു. AllowedIPs ഒരേസമയം ക്രിപ്റ്റോ അനുമതി ലിസ്റ്റും wg-quick വഴി റൂട്ട് ടേബിൾ എൻട്രിയുമാണ്. ഒരു വശത്ത് മാത്രം പ്രിഫിക്സ് ചേർത്താൽ ഹാൻഡ്ഷേക്കും പുറത്തുപോകുന്ന പാക്കറ്റുകളും നിശബ്ദതയും ലഭിക്കും, കാരണം ഉറവിടം തങ്ങളുടെ ലിസ്റ്റിൽ ഇല്ലാത്ത പാക്കറ്റുകൾ ദൂരെ വശം ഉപേക്ഷിക്കുന്നു. wg set രൂപം മുഴുവൻ ലിസ്റ്റും മാറ്റിസ്ഥാപിക്കുന്നു, അതിനാൽ മുമ്പ് പ്രവർത്തിച്ച പ്രിഫിക്സുകൾ വീണ്ടും എഴുതുക, അല്ലാത്തപക്ഷം അവ മുറിച്ചുകളയും:
wg set wg0 peer <PUBKEY> allowed-ips 192.168.10.0/24,192.168.60.0/24
ip route add 192.168.60.0/24 dev wg0wg-quick എന്നതിന് പകരം wg set ഉപയോഗിച്ചാൽ ആ രണ്ടാമത്തെ കമാൻഡ് ഐച്ഛികമല്ല. കെർണൽ പുതിയ ലിസ്റ്റ് ഉടൻ സ്വീകരിക്കുന്നു, പക്ഷേ അതിന് റൂട്ട് ചേർക്കാൻ ആരുമില്ല, അതിനാൽ ലോക്കലായി സൃഷ്ടിക്കുന്ന ട്രാഫിക് ഇപ്പോഴും ഡിഫോൾട്ട് ഗേറ്റ്വേയിലൂടെ പുറത്തുപോകുന്നു. പുതിയ WireGuard സബ്നെറ്റ് ടണൽ ഹോസ്റ്റിൽ നിന്ന് പ്രവർത്തിച്ച് ലാപ്ടോപ്പിൽ നിന്ന് പ്രവർത്തിക്കാതിരിക്കാനുള്ള ഏറ്റവും സാധാരണ കാരണം ഇതാണ്.
തിരിച്ചുവരവ് വഴി ടണലിനെക്കാൾ കൂടുതൽ തവണ പരാജയപ്പെടുന്നു
പുതിയ ദൂരെ സബ്നെറ്റിലെ ഹോസ്റ്റുകൾ മറുപടികൾ VPN ഗേറ്റ്വേ വഴി തിരികെ അയക്കണം. ആ ഗേറ്റ്വേ അവരുടെ ഡിഫോൾട്ട് റൂട്ടർ അല്ലാത്തപ്പോൾ മറുപടി LAN റൂട്ടറിലേക്ക് പോകുന്നു, അത് അത് ഉപേക്ഷിക്കുകയോ സ്വകാര്യ ഉറവിട വിലാസത്തോടെ ഇന്റർനെറ്റിലേക്ക് കൈമാറുകയോ ചെയ്യുന്നു. ഗേറ്റ്വേയിൽ നിന്നല്ല, ദൂരെ വശത്തെ ഹോസ്റ്റിൽ നിന്ന് പരിശോധിക്കുക: Linux-ൽ ip route get 10.30.20.15 അല്ലെങ്കിൽ PowerShell-ൽ Find-NetRoute -RemoteIPAddress 10.30.20.15 ഹോസ്റ്റ് യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന അടുത്ത ഹോപ്പ് കാണിക്കുന്നു. മറുപടി ടണലിന്റെ അന്തിമ പോയിന്റ് അല്ലെങ്കിൽ, അവിടെ പുതിയ പ്രിഫിക്സിന് സ്റ്റാറ്റിക് റൂട്ട് ചേർക്കുക.
തിരിച്ചുവരവ് റൂട്ട് ഇല്ലാത്ത സൈറ്റിൽ സോഴ്സ് NAT സാധുവായ ബദലാണ്, കൂടാതെ പല hub-and-spoke വിന്യാസങ്ങളും ഓരോ സെർവറിനെയും സ്പർശിക്കാതിരിക്കുന്ന വഴിയും അതാണ്. ലക്ഷ്യവശത്തെ ഗേറ്റ്വേയിലും പുതിയ പ്രിഫിക്സിൽ ഇത് പ്രയോഗിക്കുക:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADEചെലവ് യഥാർത്ഥമാണ്. ദൂരെയുള്ള ലോഗുകൾ വ്യക്തിഗത ഉറവിട വിലാസങ്ങൾ കാണിക്കുന്നത് നിർത്തുന്നു, യഥാർത്ഥ സബ്നെറ്റ് അടിസ്ഥാനമാക്കിയ ഫയർവാൾ നിയമങ്ങൾ ഗേറ്റ്വേയ്ക്കുള്ള ഒരു നിയമമായി ചുരുങ്ങുന്നു. റൂട്ട് ഇല്ലാത്തതുകൊണ്ടല്ല, ബോധപൂർവ്വം അത് തിരഞ്ഞെടുക്കുക.
ഫയർവാളുകളാണ് തിരിച്ചുവരവ് വഴിയുടെ മറ്റേ പകുതി. സോൺ അടിസ്ഥാനമാക്കിയ ഉപകരണങ്ങൾ നിലവിലുള്ള ടണൽ ഇന്റർഫേസിന്റെ സോൺ പുതിയ സബ്നെറ്റിലേക്ക് സ്വയമേവ വിപുലീകരിക്കുന്നില്ല, പഴയ പ്രിഫിക്സിനായി എഴുതിയ നിയമം പൊരുത്തപ്പെടുകയുമില്ല. IPsec-നെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് പുതിയ സബ്നെറ്റ് സോണിലേക്കോ ഇരു ദിശകളിലെയും നിയമ ജോടിയിലേക്കോ ചേർക്കുക.
മൂന്ന് ചോദ്യങ്ങളിലൂടെ തീരുമാനിക്കുക, പിന്നീട് ട്രാഫിക് കൊണ്ട് പരിശോധിക്കുക
ചുരുക്കം: വശത്തിന്റെ കോൺഫിഗറേഷൻ പ്രിഫിക്സുകൾ പേരിടുന്നുണ്ടോ (പോളിസി അടിസ്ഥാനം), അതോ ട്രാഫിക് ഇന്റർഫേസിലേക്ക് റൂട്ട് ചെയ്യുന്നുണ്ടോ (റൂട്ട് അടിസ്ഥാനം)? ഇരു അറ്റങ്ങളും പുതിയ പ്രിഫിക്സ് ലിസ്റ്റ് ചെയ്യുന്നുണ്ടോ? പുതിയ സബ്നെറ്റിൽ നിന്ന് യഥാർത്ഥ ഉറവിട ശ്രേണിയിലേക്ക് തിരികെയുള്ള വഴി ഉണ്ടോ?
| Tunnel style | Where the prefix goes | What breaks if you skip it |
|---|---|---|
| Policy-based IPsec | Selector pair on both peers | Old subnets work, the new one fails with no clear error |
| Route-based XFRM or VTI | Route into the device on both sites | Packets routed but not transformed, or the state never matches |
| WireGuard | AllowedIPs on both peers plus a route | Handshake succeeds, replies are dropped |
| Overlapping supernet | Adjust the existing entry instead | A shadowed policy wins or loses by evaluation order |
കൂടുതൽ മാറ്റങ്ങളും വളരെ നേരത്തെ അടയ്ക്കുന്ന സ്ഥലമാണ് പരിശോധന. ഗേറ്റ്വേയിൽ നിന്നുള്ള പിംഗ് കുറച്ച് മാത്രം തെളിയിക്കുന്നു, കാരണം ഗേറ്റ്വേ സ്വയം ഉറവിടമാക്കി അയക്കുന്നു, ഹോസ്റ്റിൽ നിന്ന് വ്യത്യസ്തമായ പോളിസിയുമായി പലപ്പോഴും പൊരുത്തപ്പെടുന്നു. പുതിയ സബ്നെറ്റിലെ ഹോസ്റ്റിൽ നിന്ന് പിംഗ് ചെയ്യുക, പിന്നീട് മാറ്റത്തിന് കാരണമായ ആപ്ലിക്കേഷൻ പ്രവർത്തിപ്പിക്കുക, സ്റ്റാറ്റസ് ഐക്കണല്ല കൗണ്ടറുകൾ നോക്കുക.
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg showപോളിസി അടിസ്ഥാനമാക്കിയ ടണലിൽ ip xfrm state കൗണ്ടറുകൾ ഇരു ദിശകളിലും ഉയരണം; പരന്ന കൗണ്ടറുകൾ പാക്കറ്റ് റൂട്ട് ചെയ്യപ്പെട്ടു എന്നാൽ തിരഞ്ഞെടുക്കപ്പെട്ടില്ല എന്നാണ് അർത്ഥം. WireGuard-ൽ wg show ഓരോ വശത്തെയും കൈമാറ്റം റിപ്പോർട്ട് ചെയ്യുന്നു, പൂജ്യം സ്വീകരിച്ച ബൈറ്റുള്ള ഹാൻഡ്ഷേക്ക് ദൂരെ വശത്തെ ലിസ്റ്റിലേക്കോ അതിന്റെ തിരിച്ചുവരവ് റൂട്ടിലേക്കോ വിരൽ ചൂണ്ടുന്നു.
പ്രിഫിക്സ്, വശത്തിന്റെ സെലക്ടർ അല്ലെങ്കിൽ റൂട്ട്, തിരിച്ചുവരവ് വഴിയെക്കുറിച്ചുള്ള തീരുമാനം, ഫയർവാൾ എൻട്രി എന്നിവ ബാക്കി ടണൽ ലിസ്റ്റിനൊപ്പം രേഖപ്പെടുത്തി അവസാനിപ്പിക്കുക. പിന്നീട് ഒരു ഗേറ്റ്വേ റീബൂട്ട് ചെയ്ത് വീണ്ടും പരിശോധിക്കുക: കൈകൊണ്ട് ചേർത്ത റൂട്ട് അപ്രത്യക്ഷമാകുന്നു, അടുത്ത വ്യക്തി അത് വീണ്ടും കണ്ടെത്തേണ്ടതില്ല.