പുതിയ ഫോൺ നിങ്ങളുടെ ഹോട്ട്സ്പോട്ടിൽ ചേരുന്നു, വിലാസം കാണിക്കുന്നില്ല, ഒരിക്കലും ലഭിക്കുന്നുമില്ല. ആക്സസ് പോയിന്റ് കുഴപ്പമില്ല, DHCP ഡീമൺ പ്രവർത്തിക്കുന്നു, നിങ്ങൾ എഴുതിയ ഫയർവാൾ നിയമം വിലാസ പദ്ധതിയുമായി യോജിക്കുന്നതായി തോന്നുന്നു. എന്നാൽ അത് യഥാർത്ഥത്തിൽ ആവശ്യപ്പെടുന്നത് ക്ലയന്റ് ഇതിനകം താൻ ആവശ്യപ്പെടുന്ന വിലാസം കൈവശം വയ്ക്കണം എന്നാണ്. ആദ്യ DHCP പാക്കറ്റിൽ വിലാസമേയില്ല, അതിനാൽ നിയമം ഒരിക്കലും പ്രവർത്തിക്കുന്നില്ല.

ഒരു ക്ലയന്റ് ചേരുന്നത് നിരീക്ഷിക്കുക

ക്ലയന്റിന്റെ ഭാഗത്തുനിന്ന് ഒരു അസോസിയേഷൻ പിന്തുടരുക. റേഡിയോ അസോസിയേറ്റ് ചെയ്യുന്നു, ക്ലയന്റ് DHCP കണ്ടെത്തൽ അയയ്ക്കുന്നു, സർവർ ഓഫർ നൽകുന്നു, ക്ലയന്റ് അഭ്യർത്ഥിക്കുന്നു, സർവർ സ്ഥിരീകരിക്കുന്നു, അതിനുശേഷം മാത്രമാണ് ക്ലയന്റിന് മറ്റെന്തിനും ഉപയോഗിക്കാവുന്ന വിലാസം ഉണ്ടാകുന്നത്.

ആ അന്തിമ സ്ഥിരീകരണത്തിന് മുമ്പുള്ളതെല്ലാം സംഭവിക്കുന്നത് ക്ലയന്റിന് സാധാരണ ട്രാഫിക്കിന് ഗേറ്റ്വേ ഉപയോഗിക്കാനാകാത്തപ്പോഴാണ്. സബ്നെറ്റ് നിയമം മറക്കുന്ന വിൻഡോ അതാണ്.

ആദ്യ പാക്കറ്റിൽ യഥാർത്ഥത്തിൽ എന്തുണ്ട്

RFC 2131 വിലാസം ലഭിക്കുന്നതിന് മുമ്പുള്ള ക്ലയന്റിന്റെ DHCP പ്രക്ഷേപണങ്ങൾ പൂജ്യം ഉറവിട വിലാസം ഉപയോഗിക്കുന്നു എന്ന് വ്യക്തമാക്കുന്നു. ക്ലയന്റിൽ നിന്ന് സർവറിലേക്കുള്ള സന്ദേശങ്ങൾ UDP പോർട്ട് 67-ലേക്കും, സർവറിൽ നിന്ന് ക്ലയന്റിലേക്കുള്ളവ UDP പോർട്ട് 68-ലേക്കും പോകുന്നു. അതിനാൽ കണ്ടെത്തൽ 0.0.0.0 ഉറവിടമായി വരുന്നു, നിങ്ങളുടെ ക്ലയന്റ് സബ്നെറ്റിനുള്ളിൽ ഉറവിടം ആവശ്യപ്പെടുന്ന നിയമം അതുമായി ലളിതമായി പൊരുത്തപ്പെടുന്നില്ല.

ഇത് ക്ലയന്റിന്റെ ഭാഗത്തുള്ള തെറ്റായ കോൺഫിഗറേഷനല്ല. ഇത് പ്രോട്ടോക്കോൾ രൂപകൽപ്പന ചെയ്തതുപോലെ പ്രവർത്തിക്കുന്നു, അതിന് സാധ്യമായ ഏക വിൻഡോയിൽ.

ഏത് പാതയാണ് യഥാർത്ഥത്തിൽ ഇത് കൈകാര്യം ചെയ്യുന്നത്

ആക്സസ് പോയിന്റ് തന്നെ പാട്ടങ്ങൾ നൽകുന്നുണ്ടെങ്കിൽ, ഇത് പ്രാദേശിക സേവന സംഭാഷണമാണ്, IP ഉപയോഗിച്ച് ഫിൽട്ടർ ചെയ്ത പ്രാദേശിക പാതയിൽ ഇത് ഇൻപുട്ട്, ഔട്ട്പുട്ട് നയവുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു. VPN വഴി കൈമാറുന്ന ക്ലയന്റ് ട്രാഫിക് മറ്റൊരു തീരുമാനമാണ്, ആ ട്രാഫിക്കിനുള്ള NAT വീണ്ടും മറ്റൊന്നാണ്. ഈ മൂന്നും കൂട്ടിക്കലർത്തുന്നതാണ് ഇടുങ്ങിയ ഒഴിവുനിയമത്തെ വിശാലമാക്കുന്ന വഴി.

പാക്കറ്റ് എവിടെ കൈകാര്യം ചെയ്യുന്നു എന്നത് ഡീമോണിനെയും ഉപയോഗിക്കുന്ന ഫയർവാൾ കുടുംബത്തെയും ആശ്രയിച്ചിരിക്കുന്നു. അസംസ്കൃത സോക്കറ്റ് നടപ്പാക്കലുകൾ, ബ്രിഡ്ജ് ക്രമീകരണങ്ങൾ, മുൻകാല ഫിൽട്ടർ ഹുക്കുകൾ എന്നിവ അത് തികച്ചും മറ്റൊരിടത്തേക്ക് നീക്കുകയോ തടയുകയോ ചെയ്യാം. നിയമങ്ങൾ ചേർക്കുന്നതിന് മുമ്പ് ഡീമോണിന്റെ ഇന്റർഫേസ് ബൈൻഡിംഗും സജീവ ഹുക്കുകളും സ്ഥിരീകരിക്കുക.

ഫോറത്തിൽ നിന്ന് പകർത്തിയ പൊതുവായ ഇൻപുട്ട്, ഔട്ട്പുട്ട് പാചകക്കുറിപ്പ് നിങ്ങളുടെ നടപ്പാക്കൽ അതേ രീതിയിൽ ആ ശൃംഖലകളിലൂടെ കടന്നുപോകുന്നു എന്നതിന് തെളിവല്ല.

മറുപടി എല്ലായ്പ്പോഴും പ്രക്ഷേപണമല്ല

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

പിന്നീടുള്ള പാട്ട പുതുക്കലുകൾ മറ്റൊരു അവസ്ഥയിൽ അതേ കൈമാറ്റം ആവർത്തിക്കുന്നു, അതിനാൽ ആദ്യ ബന്ധനത്തിന് മാത്രമല്ല, അവയ്ക്കും ഇടം വയ്ക്കുക.

ഇടുങ്ങിയതായി പരിഹരിക്കുക, പിന്നീട് ബാക്കിയുള്ളത് പരിശോധിക്കുക

നിലവിലുള്ള നയം നിലനിർത്തുക, കാണാത്ത DHCP അനുമതി കണ്ടെത്തി ക്ലയന്റിന് അഭിമുഖമായ ഇന്റർഫേസിലേക്കും പ്രോട്ടോക്കോളിലേക്കും രണ്ട് പോർട്ടുകളിലേക്കും അത് പരിമിതപ്പെടുത്തുക. അഭ്യർത്ഥന സേവനത്തിൽ എത്തുന്നു എന്ന് തെളിയിക്കുക, തുടർന്ന് സേവനം മറുപടി നൽകുന്നു എന്ന് തെളിയിക്കുക. ഇവ രണ്ട് വ്യത്യസ്ത നിരീക്ഷണങ്ങളാണ്, തികഞ്ഞ ഫിൽട്ടറിംഗിന് പിന്നിൽ സേവനമോ പൂളോ ഉള്ള ക്രമീകരണം ഇപ്പോഴും തെറ്റായിരിക്കാം.

ടേബിൾ ഫ്ലഷ് ചെയ്യുന്നത് DHCP കോൺഫിഗറേഷന്റെ ഘട്ടമല്ല. iptables-ൽ flush തിരഞ്ഞെടുത്ത ശൃംഖലയിൽ നിന്നോ ടേബിളിൽ നിന്നോ നിയമങ്ങൾ ഇല്ലാതാക്കുന്നു, NAT ടേബിൾ ഫ്ലഷ് ചെയ്യുന്നത് വിവർത്തന നിയമം സൃഷ്ടിക്കുന്നില്ല. വിശാലമായ ACCEPT നയങ്ങൾ സ്ഥാപിക്കുന്നത് പാട്ടവുമായി ബന്ധമില്ലാത്ത സംരക്ഷണം നീക്കം ചെയ്യുന്നു, അതിനാൽ രണ്ടും പുനരുപയോഗിക്കാവുന്ന ഹോട്ട്സ്പോട്ട് പരിഹാരത്തിൽ വരുന്നില്ല.

ക്ലയന്റിന് പാട്ടം ലഭിച്ചുകഴിഞ്ഞാൽ, DNS, ഫോർവേഡിംഗ്, VPN പുറത്തേക്കുള്ള വഴി എന്നിവ വെവ്വേറെ ജോലികളായി പരിശോധിക്കുക. പാട്ടം പ്രാദേശിക വിലാസവൽക്കരണം സ്ഥാപിക്കുന്നു, അതിൽ കൂടുതലൊന്നുമില്ല.

അനുബന്ധ ലേഖനങ്ങൾ