VPN வழியாக DHCP: ஒளிபரப்பைப் பாலமிடலாமா அல்லது ரிலே செய்யலாமா?

சுரங்கப்பாதையின் மறுபுறம் உள்ள புதிய மடிக்கணினிக்கு முகவரி கிடைப்பதில்லை, அதே மடிக்கணினி தலைமை அலுவலகத்தில் வேலை செய்கிறது. வழக்கமான முதல் ஊகம் சுரங்கப்பாதை DHCP-ஐ தடுக்கிறது என்பதாகும். பெரும்பாலும் ஒளிபரப்புக்கு ஒருபோதும் பாதை இருந்ததில்லை: கட்டமைக்கப்படாத வாடிக்கையாளர் 255.255.255.255-க்கு அனுப்புகிறது, சாதாரண IP திசைவி அந்தப் பொதியை அனுப்புவதில்லை. சுரங்கப்பாதை வழியிடப்பட்ட சுரங்கப்பாதை செய்வதையே செய்கிறது.

இரண்டு வடிவமைப்புகள் அதை மாற்ற முடியும், அவை சமமானவை அல்ல. ஒன்று ஒளிபரப்பை எடுத்துச் செல்கிறது; மற்றொன்று கோரிக்கையை ரிலே செய்கிறது.

ஒளிபரப்பு ஒருபோதும் திசைவியைக் கடப்பதில்லை

முகவரி இல்லாத DHCPv4 வாடிக்கையாளர் 0.0.0.0-இலிருந்து வரம்புக்குட்பட்ட ஒளிபரப்பு முகவரிக்கு UDP துறைகள் 67 மற்றும் 68-இல் அனுப்புகிறது. அந்தப் பொதி வடிவமைப்பின்படி அதன் இணைப்பிலேயே இருக்கும். அதை அனுப்பும் திசைவி தான் சேவை செய்யும் ஒவ்வொரு பிரிவையும் வெள்ளத்தில் மூழ்கடிக்கும்.

எனவே வழியிடப்பட்ட தளம்-தளம் சுரங்கப்பாதை ரிலேவை ஒரு சேவையகத்துடன் இணைக்கிறது. அது வாடிக்கையாளரின் ஒளிபரப்பு களத்தை விரிவாக்காது, எந்த தீச்சுவர் விதியும் அதைச் செய்யாது.

பாலமிடப்பட்ட சுரங்கப்பாதை உண்மையில் எதை விரிவாக்குகிறது

வேண்டுமென்றே பாலமிடப்பட்ட VPN அதன் ஆதரவு நிலைக்கு உட்பட்ட டோபாலஜியில் Ethernet ஒளிபரப்பை எடுத்துச் செல்ல முடியும், பின்னர் DHCP உள்ளூர் போக்குவரத்தாகக் கடக்க முடியும். இது உண்மையான விருப்பம், ஆனால் இது 2-ஆம் அடுக்கு வடிவமைப்பு முடிவு. ஒளிபரப்புடன் சேர்ந்து தோல்விக் களத்தையும் அணுகல் எல்லையையும் விரிவாக்குகிறீர்கள்.

பாலமிடுதல் ஒளிபரப்புப் புயல், ARP ஸ்கேன் அல்லது தவறான DHCP சேவையகம் எங்கு வரை செல்ல முடியும் என்பதையும் மாற்றுகிறது. தொலை அலுவலகத்தை அதே சுவிட்சில் இணைக்கப்போவதில்லை என்றால், முகவரிகளை வழங்க மட்டும் சுரங்கப்பாதையைப் பாலமிட வேண்டாம். இயக்குவதற்கு முன் அந்தத் தாக்க வீச்சைச் சோதியுங்கள்.

இது முகவரி வழங்குவதை விட பெரிய முடிவு, அதை வேண்டுமென்றே எடுக்க வேண்டும்.

அதற்கு பதிலாக கோரிக்கையை ரிலே செய்யுங்கள்

வழக்கமான பதில் வாடிக்கையாளரின் உள்ளூர் பிணையத்தில் ஒரு ரிலே. அது ஒளிபரப்பைப் பெற்று, அதை unicast கோரிக்கையாக மாற்றி, தன் முகவரியை நுழைவாயில் முகவரி புலத்தில் வைக்கிறது. சேவையகம் அந்த ரிலே முகவரிக்குப் பதிலளிக்கிறது.

எடுத்துக்காட்டாக ஒரு தொலை அலுவலகத்திற்கு, ரிலே அலுவலகத்தின் LAN-இல் அமர்ந்து, சேவையகத்தை தள VPN வழியாக அடைகிறோம். அந்த அலுவலகத்திற்கான எல்லை, ரிலே மற்றும் சேவையக அடையாளங்கள், முழுமையான திரும்பும் பாதை ஆகியவற்றைக் கட்டமைக்கவும். சுரங்கப்பாதை வழியாக UDP 67-ஐ அனுமதிப்பது எந்தக் குளத்தைப் பயன்படுத்த வேண்டும் என்று சேவையகத்திற்குச் சொல்லாது.

அனுப்பும் ஆனால் ஒருபோதும் பதிலைப் பெறாத ரிலே பொதுவாகத் திரும்பும் பாதைச் சிக்கல். எல்லையை மாற்றுவதற்கு முன் ரிலே முகவரிக்கான திரும்பும் வழியைச் சரிபார்க்கவும்.

DHCP-ஐ ARP-இலிருந்தும் சுரங்கப்பாதை முகவரியிடலிலிருந்தும் பிரிக்கவும்

DHCP UDP/IP மீது பயணிக்கிறது. Ethernet-இல், விருப்ப முகவரி ஏற்கனவே பயன்பாட்டில் உள்ளதா எனச் சரிபார்க்க ஹோஸ்ட் ARP-ஐயும் பயன்படுத்தலாம். அந்த முரண்பாட்டுச் சரிபார்ப்பு தனி இணைப்பு-உள்ளூர் செயல்பாடு, DHCP செய்திகளின் போக்குவரத்து அல்ல. DHCP அடிப்படையில் ARP என்று சொல்வது தவறு; இரண்டும் ஒருபோதும் தொடர்பில்லை என்று சொல்வது மிகவும் விரிவானது.

VPN வாடிக்கையாளர் தன் சுரங்கப்பாதை முகவரியை DHCP ஒளிபரப்புக்குப் பதிலாக VPN நடைமுறையிலிருந்தோ சேவையகத்தின் சொந்தக் குளத்திலிருந்தோ பெறலாம். பெயரில் DHCP உள்ள விருப்பம் தள்ளப்பட்ட வாடிக்கையாளர் அமைப்புகளை விவரிக்கலாம், ரிலே செய்யப்பட்ட DHCP பொதியை அல்ல. DHCP ஈடுபட்டுள்ளது எனக் கருதுவதற்கு முன் சேவையகத்தின் குளத்தைச் சரிபார்க்கவும்.

பெறும் பிணையம், ஒதுக்கீட்டின் உரிமையாளர், எல்லை, ரிலே உள்ளதா, மற்றும் இடையூறின் போது எதிர்பார்க்கப்படும் நடத்தை ஆகியவற்றைப் பதிவு செய்யுங்கள். பின்னர் அந்த மாதிரியின் வழியாகப் புதிய குத்தகை மற்றும் புதுப்பித்தலைச் சோதியுங்கள். இரு தளங்கள் ஒரே நிர்வகிக்கப்படாத குளத்திற்குச் சேவை செய்ய முடிந்தால், முதல் அலைந்து திரியும் மடிக்கணினிக்காகக் காத்திருக்கும் முரண்பாடு உங்களிடம் உள்ளது.