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 ක්ලැම්ප් කරන්න.

ලැයිස්තුව පහළට ගොස් පළමු අසාර්ථකත්වයේ නවතින්න. එම ස්තරය නිවැරදි කළ යුත්තේය; පහළින් එකතු කරන ඕනෑම දෙයක් බිඳෙන මායිම සඟවයි පමණි.

අදාළ ලිපි