Docker கொள்கலன்களின் டிராஃபிக்கை மட்டும் OpenVPN வழியாக எவ்வாறு வழிமாற்றுவது

ஹோஸ்ட்டை அதன் வழக்கமான அப்லிங்கில் வைத்து ஒரு கொள்கலன் துணைவலையத்தை சுரங்கப்பாதையில் வைக்கவும்: NAT வரிசை, மூல விதிகள், OpenVPN iroute மற்றும் MSS சரிபார்ப்புகள்.

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

கொள்கலனுக்குள் VPN வாடிக்கையாளரை இயக்குவது வேறு வடிவமைப்பு, குறுக்குவழி அல்ல. அப்போது கொள்கலன் அதன் சுரங்கப்பாதையையும் அதன் சான்றுகளையும் கொண்டிருக்கும், வேலை iptables இல் தங்காமல் Dockerfile க்கு மாறும்.

முன்னனுப்பல் இலக்கின் அடிப்படையில் வழித்தடத்தைத் தேர்ந்தெடுத்து, பின்னர் NAT மூலத்தை மீண்டும் எழுதுகிறது

அமைக்கப்பட்டிருக்கும் போது net.ipv4.ip_forward=1 , முன்னனுப்பப்பட்ட பாக்கெட் பிரதான அட்டவணையில் இலக்கின் அடிப்படையில் மட்டுமே வழிமாற்றப்படும். அந்த முடிவில் மூலத்திற்கு எந்தப் பங்கும் இல்லை. வழித்தடம் தேர்ந்தெடுக்கப்பட்ட பிறகே கர்னல் POSTROUTING ஐ இயக்குகிறது, அங்கேயே Docker இன் சொந்த விதி உள்ளது: -s 172.18.0.0/16 ! -o br-appnet -j MASQUERADE . பாலத்தை விட்டு வேறு இடைமுகத்திற்குச் செல்லும் அனைத்தும் மொழிபெயர்க்கப்படும், அது எந்த முகவரியாக மாறுகிறது என்பது வழித்தடம் அதை எந்த இடைமுகத்திற்கு அனுப்பியது என்பதைப் பொறுத்தது.

இந்த விதி என்னிடம் கேட்கப்படும் பெரும்பாலான அறிகுறிகளை விளக்குகிறது. பிரதான அட்டவணையில் தனிப்பட்ட இலக்கிற்கு வழித்தடம் இல்லாவிட்டால், பாக்கெட் ஹோஸ்ட்டின் இயற்பியல் முகவரியுடன் அப்லிங்கில் வெளியேறும். உங்கள் வழங்குநர் இலக்கை வீசிவிடுகிறார், அல்லது தொலைத் தளம் எதிர்பார்க்காத RFC 1918 மூலத்தை வீசிவிடுகிறது, சுரங்கப்பாதை மேலேயும் ஆரோக்கியமாகவும் இருக்கும்போது கொள்கலன் நேரம் முடிகிறது. tun0 இல் பிடிப்பு எதையும் காட்டாது, அதுவே அறிகுறி. வழித்தடம் உண்மையில் tun0 ஐ நோக்கிச் சென்றால், MASQUERADE மூலத்தை 10.8.0.10 ஆக மீண்டும் எழுதுகிறது, அதே கொள்கலன் நீங்கள் எதையும் தொடாமல் வேலை செய்கிறது.

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

ip route get 192.168.11.222 from 172.18.0.5 iif br-appnet

அந்தப் பதில் அப்லிங்கைப் பெயரிட்டால், சுரங்கப்பாதை படத்தில் இல்லை, சுரங்கப்பாதைப் பக்க அமைப்பு எதுவும் உதவாது.

விருந்தாளியை சுரங்கப்பாதையின் சொந்த முகவரிக்கு நகர்த்துங்கள்

மிகச் சிறிய வேலை செய்யும் மாற்றம் வெளியேறும்போது வெளிப்படையான மூல மறுஎழுத்தாகும். அதைச் சேர்ப்பதற்குப் பதிலாகச் செருகுங்கள்: Docker ஏற்கனவே POSTROUTING இன் தலையில் அமர்ந்துள்ளது, எனவே -A உடன் சேர்க்கப்பட்ட விதி Docker இன் விதிக்குப் பிறகு மதிப்பிடப்படும், ஒருபோதும் இயங்காது.

iptables -t nat -I POSTROUTING 1 -s 172.18.0.0/16 -o tun0 -j SNAT --to-source 10.8.0.10

இது நிலைத்திருக்குமா என்பதை இரண்டு நிபந்தனைகள் தீர்மானிக்கின்றன. முகவரி வாடிக்கையாளர் உண்மையில் வைத்திருப்பதாக இருக்க வேண்டும், எனவே ஒவ்வொரு வாடிக்கையாளருக்கும் ifconfig-push 10.8.0.10 255.255.255.0 கொண்ட பதிவுடன் அதைப் பிணைக்கவும்; ஒருபோதும் ஒதுக்கப்படாத முகவரியைப் பெயரிடும் விதி பிழையல்ல, அமைதியான வீழ்ச்சிகளை உருவாக்குகிறது. தொலைப் பக்கம் அந்த மூலத்தை ஏற்று பதில்களைத் திருப்பி வழிமாற்ற வேண்டும், அதனால்தான் அங்குள்ள அனுமதிப் பட்டியல் விருந்தாளி துணைவலையத்தை அல்ல, சுரங்கப்பாதை முகவரியைப் பெயரிடுகிறது. வாடிக்கையாளர் முகவரி மாறும் போது, -j MASQUERADE உடன் -o tun0 இடைமுகத்தில் உள்ளதைப் பின்பற்றுகிறது, ஆனால் நிலையான மதிப்புக்கு எதிராக எழுத முடியாத தொலைக் கொள்கையின் விலையில்.

வடிகட்டுதல் மற்ற பாதி. Docker FORWARD கொள்கையை drop ஆக வைத்து, ஒவ்வொரு டீமன் மறுதொடக்கத்திலும் தனக்குச் சொந்தமான சங்கிலிகளைக் காலி செய்கிறது, எனவே உள்ளூர் கொள்கையை DOCKER-USER இல் வைக்கவும், அது நீடிக்கும்:

iptables -I DOCKER-USER -i br-appnet -o tun0 -j ACCEPT
iptables -I DOCKER-USER -i tun0 -o br-appnet -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

திரும்பும் விதி முக்கியம்: tun0 க்கு வரும் பதில் பாலம் திறந்த இணைப்பிற்கு வெளிச்செல்லும் திசை ஏற்கப்பட்டதால் மட்டும் ஏற்கப்படுவதில்லை.

மூல விதியுடன் ஹோஸ்ட்டை நேரடியாக வைத்திருங்கள்

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

echo "200 vpnbox" >> /etc/iproute2/rt_tables
ip rule add from 172.18.0.0/16 lookup vpnbox pref 1000
ip route add default dev tun0 table vpnbox

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

திரும்பும் பாதைக்கு இப்போது உதவி தேவை. தொலைப் பக்கம் மொழிபெயர்க்கப்படாத 172.18.0.x ஐப் பார்க்கிறது, அது எங்கே வசிக்கிறது என்பதை அறிய காரணமில்லை. சேவையகத்தில் ஒவ்வொரு வாடிக்கையாளருக்கும் கோப்பிற்கு iroute 172.18.0.0 255.255.0.0 தேவை, சேவையகத்தின் உள் அட்டவணை அந்த முன்னொட்டை இந்த வாடிக்கையாளருக்குக் கொடுக்க, மேலும் தள்ளப்பட்ட route 172.18.0.0 255.255.0.0 தேவை, மற்ற வாடிக்கையாளர்கள் அது இருப்பதை அறிய.

நம்புவதற்கு முன் இரண்டு சரிபார்ப்புகள். இயக்கவும் ip route show default : redirect-gateway def1 உடன் அட்டவணையில் 0.0.0.0/1 மற்றும் 128.0.0.0/1 உள்ளன tun0 வழியாக, மேலும் ஹோஸ்ட் முற்றிலும் நேரடியாக இல்லை, ஏனெனில் அந்த அரை-இயல்புநிலைகள் default ஐ மாற்றாமல் வெல்லும். ip rule add உடன் சேர்க்கப்பட்ட விதிகளும் மறுதொடக்கத்தில் மறைந்துவிடும், எனவே அவற்றை up ஸ்கிரிப்டில் வைத்திருங்கள்.

பாக்கெட் அளவு நீங்கள் சந்திக்கும் இரண்டாவது தோல்வி

1500 பைட் பால இடைமுகம் வெளிப்புற UDP மற்றும் IP தலைப்புகள் சேர்க்கப்பட்ட பிறகு சுரங்கப்பாதைக்கு அதன் திறனுக்கு மேல் கொடுக்கிறது. சிறிய பரிமாற்றங்கள் கடக்கின்றன, எனவே DNS தீர்கிறது மற்றும் TLS கைக்குலுக்கல் முடிகிறது, பின்னர் பெரிய பதிவேற்றம் எங்கும் பிழையின்றி தொங்குகிறது. அனுப்புநர் அதே பிரிவு அளவைத் திரும்பத் திரும்பச் செய்கிறார், ஏனெனில் சிறியதாக இருக்கச் சொல்லும் ICMP துண்டாக்கல் தேவைச் செய்தி ஒருபோதும் வராது.

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

ip link set dev tun0 mtu 1400
iptables -t mangle -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

கிளாம்ப் TCP ஐ மட்டுமே மீண்டும் எழுதுகிறது. UDP, QUIC உட்பட, அதற்குப் பதிலாக விருந்தாளி இடைமுகத்தைக் குறைக்க வேண்டும், --opt com.docker.network.driver.mtu=1400 உடன் வலையம் உருவாக்கும்போது அல்லது பொருந்தும் compose விசையுடன்.

DNS மற்றும் மீண்டும் செய்யத் தகுந்த சரிபார்ப்புகள்

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

  • தோல்வியடையும் கோரிக்கையை விருந்தாளிக்குள் இயக்கவும்; ஹோஸ்ட் பக்கச் சோதனை வேறு மூல முகவரியைப் பயன்படுத்தி சிக்கலை மறைக்கிறது.
  • நீங்கள் சேர்த்த NAT மற்றும் வடிகட்டி விதிகளின் கவுண்டர்களைப் படியுங்கள். பூஜ்ஜியப் பொருத்தம் கொண்ட விதி வழிமாற்றல் தவறு, கொள்கைத் தவறு அல்ல.
  • உங்கள் SNAT விதியில் உள்ள சுரங்கப்பாதை முகவரி வாடிக்கையாளர் உண்மையில் வைத்திருப்பதுதானா என்பதை உறுதிப்படுத்துங்கள்.
  • சேவையகத்தை நிறுத்தத்திற்குக் குறை கூறும் முன் விருந்தாளியின் MTU ஐக் குறைக்கவும் அல்லது MSS ஐக் கிளாம்ப் செய்யவும்.

பட்டியலை இறங்கி முதல் தோல்வியில் நிற்கவும். அந்த அடுக்கே சரிசெய்ய வேண்டியது; கீழே சேர்க்கப்படும் எதுவும் உடையும் எல்லையை மறைக்கிறது மட்டுமே.

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