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

நிலை லேபிளை அல்ல, கர்னலைப் படியுங்கள்

இணைக்கப்பட்டதாகத் தெரிவிக்கும் சுரங்கம் குறைந்தது ஒரு குழந்தை சங்கத்தை நிறுவியுள்ளது, ஆனால் நீங்கள் நினைப்பது அல்ல. Linux இல் கர்னல் என்ன பயன்படுத்தப்படுகிறது என்பதைக் காட்டுகிறது: ip xfrm policy தேர்வான் இணைகளைப் பட்டியலிடுகிறது, swanctl --list-sas (அல்லது பழைய ipsec statusall) ஒவ்வொரு திசையிலும் போக்குவரத்து தேர்வான்கள் உட்பட இரு பக்கமும் ஒப்புக்கொண்டதைக் காட்டுகிறது. புதிய முன்னொட்டு இரண்டிலும் இல்லாவிட்டால், கட்டமைப்பு கோப்பு என்ன சொன்னாலும் அது பாதுகாப்பற்றது.

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

கொள்கை அடிப்படை: இரு பக்கமும் புதிய முன்னொட்டைப் பட்டியலிட வேண்டும்

strongSwan சொற்களில் தேர்வான் குழந்தை கட்டமைப்பின் local_ts மற்றும் remote_ts இல் உள்ளது, leftsubnet மற்றும் rightsubnet இன் வாரிசுகள். புதிய முன்னொட்டு இரு பக்கமும் கண்ணாடி போலத் தோன்ற வேண்டும்: தளம் A உள்ளூர் என்பதை தளம் B தொலை என்கிறது. பொருந்தாமை அரிதாகவே தெளிவான பிழை தரும். இரு பக்கமும் வெட்டுமிடம் வரை சுருங்கும், பழைய முன்னொட்டு தொடர்ந்து செயல்படும், புதியது மட்டும் அமைதியாகத் தோல்வியடையும்.

swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policy

pfSense அல்லது OPNsense இல் இது புதிய உள்ளூர் சப்நெட்டை புதிய தொலை சப்நெட்டுடன் இணைக்கும் இரண்டாவது Phase 2 பதிவு, பின்னர் பயன்பாடு. பழைய பதிவை வைத்திருங்கள்; மாற்றினால் அசல் சப்நெட் சேர்ப்பதற்குப் பதிலாக நகரும். ஏற்கனவே உள்ள Phase 2 0.0.0.0/0 போன்ற பெருநெட் அல்லது சுருக்கப்பட்ட வரம்பை உள்ளடக்கினால், அதன் அருகில் குறுகிய பதிவைச் சேர்க்க வேண்டாம்: ஒன்றுடன் ஒன்று மேலிடும் தேர்வான்கள் போட்டி கொள்கைகளை நிறுவுகின்றன, மதிப்பீட்டு வரிசையே வெற்றியாளரைத் தீர்மானிக்கிறது.

IKEv1 ஒவ்வொரு சப்நெட் இணையையும் அதன் சொந்த Phase 2 ஆக்குகிறது, ஒரு பரிமாற்றத்திற்கு ஒரு இணையை ஏற்கும் பக்கம் மற்றவற்றை விட்டுவிடும். IKEv2 ஒரு குழந்தையில் பல தேர்வான் இணைகளைக் கொண்டு செல்லும், ஆனால் இரு செயலாக்கங்களும் ஏற்றுக்கொண்டால் மட்டுமே. swanctl --list-sas இல் உள்ள பட்டியலே உண்மை; நீங்கள் எழுதியது ஒரு கோரிக்கை.

பாதை அடிப்படை: பாதையே கொள்கை

XFRM இடைமுகம் அல்லது VTI சாதனம் பாதை அட்டவணையின்படி போக்குவரத்தைக் கொண்டு செல்கிறது. புதிய முன்னொட்டை இரு தளங்களிலும் சாதனத்தை நோக்கி செலுத்துங்கள், இடைமுகத்தின் மாற்றத்துடன் பிணைந்த நிலை பயன்படுத்தப்படும். ஒத்திசைக்க தேர்வான் இணை இல்லை, அதனால் சப்நெட்டுகள் பெருகும்போது இந்த வடிவமைப்பு நன்றாக அளவாகிறது. strongSwan அனுப்பும் வழிகாட்டி கர்னல் பக்கத்தை விரிவாக விளக்குகிறது.

ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10

WireGuard மேலும் செல்கிறது. AllowedIPs ஒரே நேரத்தில் கிரிப்டோ அனுமதி பட்டியல் மற்றும் wg-quick வழியாக பாதை அட்டவணைப் பதிவும் ஆகும். ஒரு பக்கத்தில் மட்டும் முன்னொட்டைச் சேர்த்தால் கைக்குலுக்கல், வெளியேறும் பாக்கெட்டுகள் மற்றும் மௌனம் கிடைக்கும், ஏனெனில் தொலை பக்கம் தன் பட்டியலில் இல்லாத மூலத்தின் பாக்கெட்டுகளை வீசும். wg set வடிவம் முழு பட்டியலையும் மாற்றுகிறது, எனவே முன்பு செயல்பட்ட முன்னொட்டுகளை மீண்டும் எழுதுங்கள், இல்லையேல் அவற்றை வெட்டிவிடுவீர்கள்:

wg set wg0 peer <PUBKEY> allowed-ips 192.168.10.0/24,192.168.60.0/24
ip route add 192.168.60.0/24 dev wg0

wg-quick க்கு பதிலாக wg set பயன்படுத்தியிருந்தால் அந்த இரண்டாவது கட்டளை விருப்பமானது அல்ல. கர்னல் புதிய பட்டியலை உடனே ஏற்கிறது, ஆனால் எதுவும் அதற்கு பாதையைச் சேர்க்கவில்லை, எனவே உள்ளூரில் உருவாக்கப்பட்ட போக்குவரத்து இன்னும் இயல்புநிலை நுழைவாயில் வழியாகவே வெளியேறுகிறது. புதிய WireGuard சப்நெட் சுரங்க ஹோஸ்ட்டிலிருந்து வேலை செய்து மடிக்கணினியிலிருந்து செயல்படாததற்கு இதுவே பொதுவான காரணம்.

திரும்பும் பாதை சுரங்கத்தை விட அதிகமுறை தோல்வியடைகிறது

புதிய தொலை சப்நெட்டில் உள்ள ஹோஸ்டுகள் பதில்களை VPN நுழைவாயில் வழியாக அனுப்ப வேண்டும். அந்த நுழைவாயில் அவர்களின் இயல்புநிலை ரவுட்டர் இல்லாதபோது பதில் LAN ரவுட்டருக்குச் செல்லும், அது அதை வீசும் அல்லது தனிப்பட்ட மூல முகவரியுடன் இணையத்திற்கு அனுப்பும். நுழைவாயிலிலிருந்து அல்ல, தொலை பக்கத்து ஹோஸ்ட்டிலிருந்து சோதியுங்கள்: Linux இல் ip route get 10.30.20.15 அல்லது PowerShell இல் Find-NetRoute -RemoteIPAddress 10.30.20.15 ஹோஸ்ட் உண்மையில் பயன்படுத்தும் அடுத்த தாவலைக் காட்டும். பதில் சுரங்கத்தின் இறுதிப் புள்ளி இல்லாவிட்டால், அங்கு புதிய முன்னொட்டுக்கு நிலையான பாதையைச் சேர்க்கவும்.

திரும்பும் பாதை இல்லாத தளத்தில் மூல NAT சட்டபூர்வமான மாற்று, மேலும் பல hub-and-spoke பயன்பாடுகள் ஒவ்வொரு சேவையகத்தையும் தொடாமல் இருப்பது இப்படியே. இலக்குப் பக்க நுழைவாயிலிலும் புதிய முன்னொட்டுக்கு இதைப் பயன்படுத்துங்கள்:

iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADE

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

ஃபயர்வால்கள் திரும்பும் பாதையின் மறுபாதி. மண்டல அடிப்படையிலான சாதனங்கள் தற்போதைய சுரங்க இடைமுகத்தின் மண்டலத்தை புதிய சப்நெட்டுக்கு தானாக விரிவாக்காது, பழைய முன்னொட்டுக்கு எழுதிய விதி பொருந்தாது. IPsec ஐக் குறை சொல்வதற்கு முன் புதிய சப்நெட்டை மண்டலத்திலோ இரு திசை விதி இணையிலோ சேர்க்கவும்.

மூன்று கேள்விகளில் முடிவு செய்து, பின்னர் போக்குவரத்தால் சரிபார்க்கவும்

சுருக்கம்: பக்கத்தின் கட்டமைப்பு முன்னொட்டுகளைப் பெயரிடுகிறதா (கொள்கை அடிப்படை), அல்லது போக்குவரத்து இடைமுகத்துக்கு பாதையாகிறதா (பாதை அடிப்படை)? இரு முனைகளும் புதிய முன்னொட்டைப் பட்டியலிடுகிறதா? புதிய சப்நெட்டிலிருந்து அசல் மூல வரம்புக்கு திரும்பும் வழி உண்டா?

Tunnel styleWhere the prefix goesWhat breaks if you skip it
Policy-based IPsecSelector pair on both peersOld subnets work, the new one fails with no clear error
Route-based XFRM or VTIRoute into the device on both sitesPackets routed but not transformed, or the state never matches
WireGuardAllowedIPs on both peers plus a routeHandshake succeeds, replies are dropped
Overlapping supernetAdjust the existing entry insteadA shadowed policy wins or loses by evaluation order

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

tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg show

கொள்கை அடிப்படையிலான சுரங்கத்தில் ip xfrm state இன் கவுண்டர்கள் இரு திசையிலும் உயர வேண்டும்; தட்டையான கவுண்டர்கள் என்பது பாக்கெட் பாதையாக்கப்பட்டது ஆனால் தேர்ந்தெடுக்கப்படவில்லை. WireGuard இல் wg show பக்கம் வாரியாக பரிமாற்றத்தைத் தெரிவிக்கிறது, பூஜ்ஜிய பைட்டுகள் பெறப்பட்ட கைக்குலுக்கல் தொலை பக்கத்தின் பட்டியலை அல்லது அதன் திரும்பும் பாதையைச் சுட்டுகிறது.

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

தொடர்புடைய கட்டுரைகள்