உங்கள் ஹாட்ஸ்பாட்டின் ஃபயர்வால் குத்தகைக்கு முன் DHCP-ஐ தடுக்கிறது

புதிய தொலைபேசி உங்கள் ஹாட்ஸ்பாட்டில் இணைகிறது, எந்த முகவரியையும் காட்டாது, ஒருபோதும் பெறாது. அணுகல் புள்ளி சரியாக உள்ளது, 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 வெளியேற்றத்தை தனித்தனி பணிகளாகச் சரிபார்க்கவும். குத்தகை உள்ளூர் முகவரியிடலை நிறுவுகிறது, அதற்கு மேல் எதுவுமில்லை.