OpenVPN വഴി പൊതു പ്രിഫിക്സ്: തിരിച്ചുവരവ് പാത ശരിയാക്കുക

ടണൽ ഉയരുന്നതും ക്ലൈന്റ് എതിർവശത്തേക്ക് പിംഗ് ചെയ്യുന്നതും കാണുക, തുടർന്ന് VPN-ന് പിന്നിലുള്ള ഒരു പൊതു വിലാസം മറ്റെവിടെ നിന്നോ മറുപടി നൽകുന്നു, അല്ലെങ്കിൽ അത് മറുപടി നൽകുന്നില്ല. ഈ ലക്ഷണത്തിന് സാധാരണയായി സൈഫറുമായോ സർട്ടിഫിക്കറ്റുകളുമായോ യാതൊരു ബന്ധവുമില്ല. ദാതാവ് റൂട്ട് ചെയ്ത പ്രിഫിക്സ് ഒരു IP റൂട്ടായി എത്തിക്കുന്നു, അത് OpenVPN വഴി കൊണ്ടുപോകുക എന്നത് ആ റൂട്ട് രണ്ട് തലങ്ങളിൽ പുനർനിർമ്മിക്കുകയും തിരിച്ചുവരവ് പാതയിൽ സോഴ്സ് വിലാസം സംരക്ഷിക്കുകയും ചെയ്യുക എന്നാണ്. WAN ബ്രിഡ്ജ് ചെയ്യേണ്ടതില്ല, വിലാസം ഒരു ഇന്റർഫേസിൽ ചേർക്കുന്നത് മുകളിലെ റൂട്ട് സൃഷ്ടിക്കുന്നില്ല.

പ്രിഫിക്സ് ആദ്യം നിങ്ങളിലേക്ക് റൂട്ട് ചെയ്യണം

ബ്ലോക്ക് എങ്ങനെ എത്തിക്കുന്നുവെന്ന് ദാതാവിനോട് ചോദിക്കുക. നിങ്ങളുടെ സെർവറിന്റെ പ്രധാന വിലാസത്തിലേക്ക് റൂട്ട് ചെയ്ത പ്രിഫിക്സ്, ദാതാവ് WAN സെഗ്മെന്റിൽ നേരിട്ട് എത്തുമെന്ന് പ്രതീക്ഷിക്കുന്ന വിലാസങ്ങളിൽ നിന്ന് വ്യത്യസ്തമാണ്. ഇവിടത്തെ രൂപകൽപ്പനയിൽ ആദ്യ മാതൃക മാത്രമാണ് പ്രവർത്തിക്കുന്നത്.

ദാതാവ് 198.51.100.64/28 നിങ്ങളുടെ പ്രവേശന സെർവറിലേക്ക് റൂട്ട് ചെയ്താൽ, ആ ശ്രേണിയിലെ പാക്കറ്റുകൾ സെർവറിൽ എത്തി, നിങ്ങൾ അവ കൈമാറാത്ത പക്ഷം അവിടെ നിൽക്കും. ദാതാവ് പകരം ശ്രേണി നിങ്ങളുടെ അപ്ലിങ്കിലേക്ക് ബ്രിഡ്ജ് ചെയ്താൽ, സെർവർ അതിന് ARP മറുപടി നൽകണം, അത് മറ്റൊരു പ്രശ്നമാണ്.

OpenVPN തൊടുന്നതിന് മുമ്പ് ഡെലിവറി മാതൃക പരീക്ഷിക്കുക: പുറത്തുനിന്ന് ബ്ലോക്കിലെ ഒരു വിലാസത്തിലേക്ക് പിംഗ് ചെയ്ത് ഏത് ഇന്റർഫേസ് അത് സ്വീകരിക്കുന്നുവെന്ന് കാണുക. ഒന്നും എത്തിയില്ലെങ്കിൽ ഒരു ടണൽ കോൺഫിഗറേഷനും സഹായിക്കില്ല. വിലാസം WAN-ൽ നേരിട്ട് മറുപടി നൽകുന്നുവെങ്കിൽ, ദാതാവ് റൂട്ട് ചെയ്യുന്നതിന് പകരം ബ്രിഡ്ജ് ചെയ്യുകയാണ്, താഴെയുള്ള രൂപകൽപ്പന ബാധകമല്ല.

രണ്ട് റൂട്ടിംഗ് തലങ്ങൾ: കേർണൽ റൂട്ടും iroute-ഉം

OpenVPN-ന് പ്രിഫിക്സ് രണ്ട് സ്ഥലങ്ങളിൽ ആവശ്യമാണ്. പ്രിഫിക്സ് ടണൽ ഉപകരണത്തിന്റേതാണെന്ന് കേർണൽ അറിയണം, അങ്ങനെ കൈമാറ്റം ചെയ്യപ്പെടുന്ന പാക്കറ്റുകൾ ഡിഫോൾട്ട് റൂട്ടിലേക്കല്ല, OpenVPN-ലേക്ക് കടക്കും. ഏത് പ്രാമാണീകരിച്ച ക്ലൈന്റാണ് പ്രിഫിക്സിന്റെ ഉടമ എന്നും OpenVPN അറിയണം, അതാണ് ക്ലൈന്റ്-നിർദ്ദിഷ്ട ഡയറക്ടറിയിലെ iroute എൻട്രി.

സെർവർ വശത്തെ റൂട്ട് ഇങ്ങനെയാണ്, പ്രിഫിക്സും മാസ്കും അനുവദനയുമായി പൊരുത്തപ്പെടണം:

ip route add 198.51.100.64/28 dev tun0

ക്ലൈന്റ്-നിർദ്ദിഷ്ട കോൺഫിഗറേഷൻ ഉടമസ്ഥത അനുവദിക്കുന്നു. ക്ലൈന്റ് സർട്ടിഫിക്കറ്റിന്റെ പൊതുനാമത്തിൽ പേരുള്ള CCD ഫയലിൽ അത് വയ്ക്കുക, സെർവർ യഥാർത്ഥത്തിൽ വായിക്കുന്നത് ആ ഡയറക്ടറിയാണെന്ന് ഉറപ്പാക്കുക:

iroute 198.51.100.64 255.255.255.240

OpenVPN-ന്റെ റൂട്ട് ചെയ്ത നെറ്റ്വർക്കുകളെക്കുറിച്ചുള്ള ഡോക്യുമെന്റേഷൻ രണ്ട് തലങ്ങളും അവ എന്തുകൊണ്ട് വേർതിരിഞ്ഞിരിക്കുന്നുവെന്നും വിവരിക്കുന്നു. iroute ഇല്ലാത്ത കേർണൽ റൂട്ട് പാക്കറ്റുകളെ ഉടമയില്ലാതെ ടണലിലേക്ക് അയയ്ക്കുന്നു, OpenVPN അവ വലിച്ചെറിയുന്നു. കേർണൽ റൂട്ട് ഇല്ലാത്ത iroute പാക്കറ്റുകളെ സെർവറിന്റെ ഡിഫോൾട്ട് പാതയിൽ വിടുന്നു. രണ്ട് പിഴവുകളും ക്ലൈന്റ് വശത്തുനിന്ന് തകർന്ന ടണൽ പോലെ തോന്നുന്നു.

സേവന വിലാസം എവിടെയാണ്

ഡെലിഗേറ്റ് ചെയ്ത പ്രിഫിക്സ് ടണലിന്റെ സ്വന്തം വിലാസങ്ങളല്ല. വേണമെങ്കിൽ ലിങ്ക് സ്വകാര്യ സ്പേസിൽ നിന്ന് നമ്പർ ചെയ്യുക, പൊതു സേവന വിലാസം സേവനം യഥാർത്ഥത്തിൽ പ്രവർത്തിക്കുന്നിടത്ത് വയ്ക്കുക.

സേവനം പ്രാദേശികമായി അവസാനിപ്പിക്കുന്ന Linux ക്ലൈന്റിൽ ഒരു ഹോസ്റ്റ് വിലാസം മതി:

ip address add 198.51.100.70/32 dev lo

പ്രിഫിക്സ് തുടർന്ന് ഒരു VM ഹോസ്റ്റിലേക്കോ മറ്റൊരു LAN-ലേക്കോ റൂട്ട് ചെയ്താൽ, പകരം ആ ഡൗൺസ്ട്രീം പാതയും അതിന്റെ തിരിച്ചുവരവ് റൂട്ടും കോൺഫിഗർ ചെയ്യുക. ബ്ലോക്കിലെ ഓരോ വിലാസവും VPN ക്ലൈന്റിന് നൽകേണ്ടതില്ല, അത് പിന്നീട് പൊരുത്തക്കേടുകൾ സൃഷ്ടിക്കുന്നു.

തിരിച്ചുവരവ് പാതയിൽ പൊതു സോഴ്സ് നിലനിർത്തുക

ഡെലിഗേറ്റ് ചെയ്ത പ്രിഫിക്സിൽ നിന്നുള്ള മറുപടി ടണലിലൂടെ പുറത്തുപോയി ദാതാവിന്റെ റൂട്ടിൽ എത്തണം. ദൂരെയുള്ള ഹോസ്റ്റ് അത് സ്വന്തം ISP വഴി അയച്ചാൽ, സോഴ്സ് വിലാസം വ്യാജമായി തോന്നും, ദാതാവോ ലക്ഷ്യസ്ഥാനമോ അത് വലിച്ചെറിയുന്നു. പരിഹാരം സോഴ്സ് അടിസ്ഥാനമാക്കിയ നിയമമോ സമർപ്പിത റൂട്ടിംഗ് പട്ടികയോ ആണ്, വീതിയേറിയ NAT അല്ല. അതില്ലാതെ സേവനം ടണൽ പങ്കാളിയിൽ നിന്ന് പ്രവർത്തിക്കുന്നു, മറ്റെല്ലായിടത്തും പരാജയപ്പെടുന്നു.

പ്രവേശന സെർവറിൽ വീതിയേറിയ masquerade നിയമമാണ് സാധാരണ കുറ്റവാളി. അത് പൊതു സോഴ്സ് സെർവറിന്റെ പ്രധാന വിലാസത്തിലേക്ക് മാറ്റിയെഴുതുന്നു, ക്ലൈന്റ് യഥാർത്ഥത്തേത് ഒരിക്കലും കാണുന്നില്ല:

iptables -t nat -S POSTROUTING

ആവശ്യമുള്ള സ്വകാര്യ VPN ക്ലൈന്റുകളിൽ മാത്രം NAT പരിമിതപ്പെടുത്തുക, ഡെലിഗേറ്റ് ചെയ്ത പ്രിഫിക്സ് വിവർത്തനം ചെയ്യാതെ വിടുക. തുടർന്ന് സെർവർ പ്രിഫിക്സ് എങ്ങനെയെങ്കിലും കൈമാറുന്നുണ്ടെന്ന് ഉറപ്പാക്കുക, കാരണം ഡിഫോൾട്ട്-നിഷേധ കൈമാറ്റ ശൃംഖല അതിനെ നിശബ്ദമായി വലിച്ചെറിയുന്നു.

വിശ്വസിക്കുന്നതിന് മുമ്പ് രണ്ട് ദിശകളും പരിശോധിക്കുക

പരിശോധന ഒരെണ്ണമല്ല, നാല് നിരീക്ഷണങ്ങളാണ്. ദാതാവിന്റെ റൂട്ട് എത്തുന്നുവെന്നും, കേർണൽ പ്രിഫിക്സ് ടണലിലേക്ക് അയയ്ക്കുന്നുവെന്നും, OpenVPN അത് ശരിയായ ക്ലൈന്റിന് ആരോപിക്കുന്നുവെന്നും, മറുപടി പൊതു സോഴ്സ് കേടുകൂടാതെ തിരികെ വരുന്നുവെന്നും ഉറപ്പാക്കുക. ഓരോ നിരീക്ഷണത്തിനും സ്വന്തം കമാൻഡുണ്ട്, അതിനാൽ പരാജയം മുഴുവൻ രൂപകൽപ്പനയെയല്ല, ഒരു പാളിയെ സൂചിപ്പിക്കുന്നു. ഓരോ കോൺഫിഗറേഷൻ മാറ്റത്തിനും ശേഷം അവ ആ ക്രമത്തിൽ പ്രവർത്തിപ്പിക്കുക.

ഡെലിഗേറ്റ് ചെയ്ത വിലാസം ഏത് പാതയിലൂടെ പോകുന്നുവെന്ന് കേർണലിനോട് ചോദിക്കുക, അഭ്യർത്ഥന നടക്കുമ്പോൾ ടണൽ നിരീക്ഷിക്കുക:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

റിവേഴ്സ്-പാത്ത് ഫിൽട്ടറിംഗ് ശരിയായ റൂട്ട് റദ്ദാക്കാം. ടണലിലും അപ്ലിങ്കിലും ഫലപ്രദമായ ക്രമീകരണം പരിശോധിക്കുക, കർശന മോഡ് എത്തിയ ഇന്റർഫേസുമായി സോഴ്സ് പൊരുത്തപ്പെടാത്ത ട്രാഫിക് നിരസിക്കുന്നുവെന്ന് ഓർക്കുക:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

അവസാനം, പരാജയ സാഹചര്യം പരീക്ഷിക്കുക. ടണൽ നിർത്തി, പൊതു പ്രിഫിക്സ് സാധാരണ അപ്ലിങ്കിലൂടെ ചോരുന്നില്ലെന്ന് ഉറപ്പാക്കുക. VPN പുനഃസ്ഥാപിക്കുമ്പോൾ ഹോസ്റ്റ് തുറക്കുന്ന പോർട്ടുകൾ വികസിപ്പിക്കാതെ സേവനം തിരികെ വരണം.