ஒரு Azure VPN VM-இல் இரண்டு பொது IP: எது என்ன செய்கிறது

ஒரு Azure VPN VM-இல் இரண்டு பொது IP இருந்தால் அரிதாகவே நிறைவேறும் எதிர்பார்ப்பு உருவாகிறது: கிளையண்டுகள் இணைக்கும் முகவரியே இணையதளங்கள் காணும் முகவரியாகவும் இருக்கும். இந்த முடிவை மூன்று சுயாதீன முடிவுகள் தருகின்றன, அவற்றில் முதலாவது மட்டுமே சுரங்கப்பாதை கேட்பானைப் பற்றியது. இரண்டாவது முன்னனுப்பப்பட்ட கிளையண்ட் போக்குவரத்திற்குப் பயன்படும் விருந்தினர் மூலம், மூன்றாவது அந்த மூலத்திற்குப் பொருந்தும் Azure வெளியேற்ற முறை. ஒன்றை மாற்றினால் மற்ற இரண்டும் இருந்த இடத்திலேயே இருக்கும், எனவே ஒவ்வொன்றையும் வெளிப்படையாக முடிவு செய்யுங்கள்.

முடிவு 1: சுரங்கப்பாதை எங்கு முடிகிறது

Azure பொது IP ஒரு NIC-இல் உள்ள தனிப்பட்ட IP கட்டமைப்புடன் இணைக்கப்பட்டுள்ளது; இது விருந்தினர் இயக்க முறைமைக்குள் நீங்கள் சேர்க்கும் முகவரி அல்ல. ஊகிக்காமல் மேப்பிங்கைப் படியுங்கள்: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. அந்த வினவல் திருப்பித் தரும் எந்தத் தனிப்பட்ட முகவரியும் விருந்தினர் உண்மையில் வைத்திருக்க வேண்டியதே.

ஒரு NIC பல IP கட்டமைப்புகளைச் சுமக்க முடியும், எனவே இரண்டு பொது முகவரிகளுக்கு இரண்டு NIC தேவையில்லை. வடிவமைப்பு உண்மையில் இரண்டு NIC-ஐப் பயன்படுத்தினால், ஒவ்வொன்றும் அதன் சொந்த விருந்தினர் பாதைகளையும் அடுத்த தாவல்களையும் கொண்டு வரும், நீங்கள் எளிமைப்படுத்துவதற்குப் பதிலாக ஒரு ரூட்டிங் முடிவைச் சேர்த்துள்ளீர்கள்.

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

முடிவு 2: முன்னனுப்பப்பட்ட கிளையண்ட் எந்த மூலத்தைப் பயன்படுத்துகிறது

நுழைவாயில் கிளையண்ட் கோரிக்கையை மறைகுறியாக்கிய பிறகு, அது முன்னனுப்பும் பாக்கெட் VPN கேட்பானை அடைந்த பாக்கெட்டிலிருந்து வேறுபடும். விருந்தினருக்கு முன்னனுப்புதல் இயக்கப்பட்டிருக்க வேண்டும், ஓட்டத்தை அனுமதிக்கும் ஃபயர்வால் கொள்கை மற்றும் மேக வடிவமைப்பு அனுமதிக்கும் மூல முகவரி தேவை. கிளையண்டின் உள் முகவரியை மொழிபெயர்த்தால், Azure மதிப்பிடுவது அந்த மொழிபெயர்க்கப்பட்ட மூலத்தையே, கிளையண்டின் உள் முகவரியை அல்ல.

குறுகிய SNAT விதி விருந்தினர்-தனிப்பட்ட மூலத்தைத் தேர்ந்தெடுக்கலாம், ஆனால் பிந்தைய Azure மொழிபெயர்ப்பை மிஞ்ச முடியாது. VM-க்குள் ஒவ்வொரு கிளையண்டிற்கும் பொறுப்புணர்வு தேவைப்பட்டால் SNAT தேர்ந்தெடுக்கவும்; துணைப்பிணையத்தின் வெளியேற்ற வடிவமைப்பு ஏற்கனவே நிலையான பொது மூலத்தைத் தந்தால், இரண்டாவது மொழிபெயர்ப்பு நிலையை மட்டுமே சேர்க்கும் என்றால் அதைத் தவிர்க்கவும்.

முடிவு 3: எந்த Azure வெளியேற்ற முறை வெல்கிறது

Microsoftவெளியேற்ற முன்னுரிமை வரிசையைஆவணப்படுத்துகிறது: சாதனம் அல்லது நுழைவாயிலுக்குப் பொருந்தும் பாதைக்கு முன்னுரிமை உள்ளது, மேலும் தொடர்புடைய பாதையில் துணைப்பிணையத்தின் NAT Gateway இணைப்பு நிகழ்வு-நிலை பொது IP-ஐ விட முன்னுரிமை பெறுகிறது. இந்த வரிசையே 10.20.0.5-க்கு மொழிபெயர்ப்பது இணையதளம் 198.51.100.20-ஐக் காணும் என்பதை நிரூபிக்காததற்குக் காரணம். வெளியேற்ற வடிவமைப்பை ஏற்பதற்கு முன் பயனுள்ள பாதை அட்டவணை, NAT Gateway தொடர்பு மற்றும் NIC-இன் பொது IP ஆகியவற்றை ஒன்றாகப் படியுங்கள்.

வையுங்கள்Azure NIC முன்னனுப்புதல் அமைப்பைLinux முன்னனுப்புதலிலிருந்து தனியாக. மேகக் கொடி மூலம் அல்லது இலக்கு NIC-க்கு ஒதுக்கப்படாத பாக்கெட்டுகளை அனுமதிக்கிறது; அது net.ipv4.ip_forward-ஐ இயக்காது, விருந்தினர் அமைப்பு மேக அனுமதியைத் தராது.

சுரங்கப்பாதை சாக்கெட்டுக்கு அதன் சொந்த மூல முடிவு உள்ளது

wg-quick கீழ் WireGuard-இன் Address WireGuard இடைமுகத்திற்கு முகவரியை ஒதுக்குகிறது; இது வெளிப்புற UDP பிணைப்பு அறிவுறுத்தல் அல்ல. மறைகுறியாக்கப்பட்ட சாக்கெட்டின் மூலம் பாதை அட்டவணையைப் பின்பற்றுகிறது, எனவே கொள்கைப் பாதை அல்லது இரண்டாவது இயல்புநிலை இடைமுகம் முகவரியைத் தொடாமல் அதை நகர்த்தலாம்.OpenVPN-இன் local விருப்பமும் UDP multihome-உம் அதே விதத்தில் நடந்துகொள்ளும்: அவை கேட்பான் மற்றும் அதன் பதில்களைப் பற்றியவை, முன்னனுப்பப்பட்ட ஒவ்வொரு கிளையண்டின் இணைய மூலத்தைப் பற்றியவை அல்ல.

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

என்ன ஏற்க வேண்டும், எந்த வரிசையில்

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

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