OpenVPN பின்னால் Docker மற்றும் VM போக்குவரத்து: வழியா அல்லது மறுஎண்ணீடா?

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

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

ஒரே மாதிரி தோன்றும் இரண்டு தோல்விகள்

முதலாவது திரும்பும் வழியின் பிரச்சினை. வெளியிடப்பட்ட போர்ட் கொள்கலனுக்கு மொழிபெயர்க்கப்படுகிறது, கோரிக்கை வருகிறது, பதில் ஹோஸ்ட்டின் இயல்புநிலை வழித்தடத்தின் வழியாக அனுப்பப்படுகிறது, அதை OpenVPN கிளையண்ட் tun0 நோக்கி திருப்பியுள்ளது. பதில் தொலை சகாவினர் எதிர்பார்க்காத முகவரியிலிருந்து வெளியேறி, நிராகரிக்கப்படுகிறது. இரண்டாவது முன்னொட்டு மோதல்: Docker இன் இயல்புநிலை பாலம் 172.17.0.0/16 ஐ வைத்திருக்கிறது, நிறுவன சுரங்கம் அதே வரம்பை தள்ளுகிறது.

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

மூன்று கேள்விகளால் தீர்மானியுங்கள்

கேள்வி ஒன்று: VPN ஐ நிறுத்தும்போது தோல்வி மறைகிறதா? சுரங்கம் அணைந்திருக்கும்போது எல்லாம் இயங்கினால், திரும்பும் வழியை சந்தேகியுங்கள். கேள்வி இரண்டு: ip route show table all அதே முன்னொட்டை இருமுறை பட்டியலிடுகிறதா, ஒருமுறை பாலத்தில் ஒருமுறை tun0 இல்? அதுவே மோதல். கேள்வி மூன்று: பாதிக்கப்பட்ட முகவரி கொள்கலனா, NAT விருந்தினரா அல்லது பாலமாக்கப்பட்ட விருந்தினரா?

மூன்றாவது கேள்வி முக்கியம், ஏனெனில் ஒவ்வொன்றுக்கும் வேறு சரியான தீர்வு உள்ளது, கொள்கலன் தீர்வை libvirt விருந்தினருக்குப் பயன்படுத்துவது ஒரு மாலையை வீணாக்கும்.

ip route
ip route show table all | grep -E '172\.1[7-9]|10\.8'
docker network inspect bridge --format '{{.IPAM.Config}}'

திரும்பும் வழி: ஒரு மூல முகவரிக்கான அட்டவணை

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

ip rule add from 172.22.0.3 lookup 10
ip route add default via 172.22.0.1 table 10

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

இதன் மூலம் உறுதிப்படுத்துங்கள்: ip route get 1.1.1.1 from 172.22.0.3. பதிலில் பாலத்தின் இடைமுகம் இருக்க வேண்டும், tun0 அல்ல. இவ்வாறு சேர்க்கப்பட்ட விதிகள் மறுதொடக்கத்தில் மறைந்துவிடும், எனவே அவற்றை கொள்கலனை வைத்திருக்கும் unit அல்லது பிணைய கொக்கியில் வையுங்கள்.

அதே முறை WireGuard கொள்கலனுக்கும் வேலை செய்கிறது, அங்கு பதில் வழிக்கும் வெளிப்படையான விதி தேவை.

முன்னொட்டு மோதல்: பாலத்தை மறுஎண்ணீடு செய்யுங்கள்

வழித்தட அட்டவணை ஒரு முன்னொட்டை ஒரே இடத்திற்கு அனுப்புகிறது. VPN 172.17.0.0/16 ஐ தள்ளும்போது Docker இன் பாலம் ஏற்கனவே அங்கு இருந்தால், குறைந்த மெட்ரிக் வெல்லும்: Docker அதன் இணைக்கப்பட்ட வழியை மெட்ரிக் 0 இல் நிறுவுகிறது, தள்ளப்பட்ட வழி 50 இல் வருகிறது. அப்போது Docker இயங்கிக்கொண்டிருக்கும்போதே சுரங்கம் உடைந்ததாகத் தோன்றும், அல்லது நேர்மாறாக, நிறுவல் வரிசையைப் பொறுத்து. மெட்ரிக்குடன் போராடுவதற்குப் பதிலாக பாலத்தை மறுஎண்ணீடு செய்யுங்கள்.

{
  "bip": "10.200.0.1/24",
  "default-address-pools": [{"base": "10.201.0.0/16", "size": 24}]
}

மாற்றத்திற்குப் பிறகு Docker ஐ மறுதொடக்கம் செய்து பழைய குளத்தால் கட்டப்பட்ட பிணையங்களை மீண்டும் உருவாக்குங்கள். அதற்குப் பதிலாக மெட்ரிக்கை மாற்றுவது மோதலை அடுத்த துவக்கத்திற்கு நகர்த்துகிறது.

VM களுக்கு மீண்டும் வேறு பதில் தேவை

இயல்புநிலை NAT பிணையத்தில் உள்ள libvirt விருந்தினர் ஹோஸ்ட்டின் வழித்தடத்தை மரபுரிமையாகப் பெறுகிறது, ஹோஸ்ட்டின் சுரங்கம் இயல்புநிலை வழியை வைத்திருக்கும் தருணத்தில் வெளியே செல்வதை நிறுத்துகிறது. விருந்தினரை பாலம் அல்லது macvtap சாதனத்திற்கு மாற்றுவது இயற்பியல் பிணையத்தில் அவருக்கு சொந்த வழியைத் தருகிறது. virt-manager இல் வன்பொருளைச் சேர்க்கவும், Network ஐத் தேர்ந்தெடுக்கவும், மூலத்தை macvtap ஹோஸ்ட் சாதனத்தில் அமைக்கவும், மாதிரியாக virtio வைத்திருங்கள், பின்னர் பழைய NAT இடைமுகத்தை முடக்குங்கள்.

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

ஹோஸ்ட்டின் LAN மட்டுமே தேவைப்படும் விருந்தினருக்கு, விற்பனையாளரின் கிளையண்டில் காணாமல் போன சுவிட்ச் இருக்கலாம்: Mullvad உடன் mullvad lan set allow libvirt ஐத் தொடாமல் உள்ளூர் அணுகலை மீட்டெடுக்கிறது. கொள்கலன் சுரங்கம் வழியாக மட்டுமே அணுகப்பட வேண்டும் என்றால், வெளியிடப்பட்ட போர்ட்டை சுரங்க முகவரியுடன் பிணைக்கவும், -p 10.8.0.5:8080:8080, ஒவ்வொரு முகவரியிலும் வெளியிடுவதற்குப் பதிலாக.