.nh .TH SLIRP4NETNS 1 "January 2022" "Rootless Containers" "User Commands" .SH "نام (NAME)" .PP slirp4netns \- شبکه‌سازی در حالت کاربر برای فضاهای نام شبکه بدون دسترسی ریشه .SH "خلاصه دستور (SYNOPSIS)" .PP slirp4netns [OPTION]... PID|PATH|FD [TAPNAME] .SH "توضیحات (DESCRIPTION)" .PP slirp4netns شبکه‌سازی در حالت کاربر (\(lqslirp\(rq) را برای فضاهای نام شبکه فراهم می‌کند. .PP برخلاف \fB\fCveth(4)\fR، slirp4netns نیازی به دسترسی‌های ریشه (root) بر روی میزبان ندارد. .PP پیکربندی پیش‌فرض: .RS .IP \(bu 2 MTU: 1500 .IP \(bu 2 CIDR: 10.0.2.0/24 .IP \(bu 2 Gateway/Host: 10.0.2.2 (آدرس شبکه + 2) .IP \(bu 2 DNS: 10.0.2.3 (آدرس شبکه + 3) .IP \(bu 2 شروع DHCP: 10.0.2.15 (آدرس شبکه + 15) .IP \(bu 2 پایان DHCP: 10.0.2.30 (آدرس شبکه + 30) .IP \(bu 2 IPv6 CIDR: fd00::/64 .IP \(bu 2 IPv6 Gateway/Host: fd00::2 .IP \(bu 2 IPv6 DNS: fd00::3 .RE .SH "گزینه‌ها (OPTIONS)" .PP \fB\fC\-c\fR, \fB\fC\-\-configure\fR رابط TAP را بالا می‌آورد. به‌طور پیش‌فرض، IP روی 10.0.2.100 (آدرس شبکه + 100) تنظیم خواهد شد. IPv6 روی یک آدرس تصادفی تنظیم می‌شود. از نسخهٔ v0.4.0، رابط loopback (\fB\fClo\fR) نیز بالا آورده می‌شود. .PP \fB\fC\-e\fR, \fB\fC\-\-exit\-fd=FD\fR مشخص کردن FD برای خاتمه دادن به slirp4netns. هنگامی که FD مشخص شود، slirp4netns با رخ دادن یک رویداد \fB\fCpoll(2)\fR روی FD خارج می‌شود. .PP \fB\fC\-r\fR, \fB\fC\-\-ready\-fd=FD\fR مشخص کردن FD جهت نوشتن در آن پس از اتمام مراحل مقداردهی اولیه. هنگامی که FD مشخص شود، slirp4netns مقدار \fB\fC"1"\fR را روی FD نوشته و FD را می‌بندد. پیش از نسخهٔ v0.4.0، نوشتن روی FD پس از پیکربندی شبکه (\fB\fC\-c\fR) اما پیش از پیکربندی سوکت API (\fB\fC\-a\fR) انجام می‌شد. .PP \fB\fC\-m\fR, \fB\fC\-\-mtu=MTU\fR (از نسخهٔ v0.2.0) مشخص کردن MTU (حداکثر=65521). .PP \fB\fC\-6\fR, \fB\fC\-\-enable\-ipv6\fR (از نسخهٔ v0.2.0، آزمایشی) فعال‌سازی IPv6 .PP \fB\fC\-a\fR, \fB\fC\-\-api\-socket\fR (از نسخهٔ v0.3.0) مسیر سوکت API .PP \fB\fC\-\-cidr\fR (از نسخهٔ v0.3.0) مشخص کردن CIDR، به عنوان مثال 10.0.2.0/24 .PP \fB\fC\-\-disable\-host\-loopback\fR (از نسخهٔ v0.3.0) ممنوع کردن اتصال به 127.0.0.1:* روی فضای نام میزبان .PP \fB\fC\-\-netns\-type=TYPE\fR (از نسخهٔ v0.4.0) مشخص کردن نوع فضای نام شبکه ([path|pid|tapfd]، پیش‌فرض=pid) اگر نوع فضای نام tapfd باشد، انتظار می‌رود نخستین آرگومان مکانی، یک توصیف‌کننده فایل موروثی باشد که به یک اتصال \fB\fC/dev/net/tun\fR مربوط می‌شود. این با \fB\fC\-\-configure\fR تداخل دارد و \fB\fcTAPNAME\fR نادیده گرفته می‌شود. .PP \fB\fC\-\-userns\-path=PATH\fR (از نسخهٔ v0.4.0) مشخص کردن مسیر فضای نام کاربر .PP \fB\fC\-\-enable\-sandbox\fR (از نسخهٔ v0.4.0) ورود به فضای نام کاربر و ایجاد یک فضای نام سوارکردن (mount namespace) جدید که در آن تنها /etc و /run از میزبان سوار شده‌اند. .PP نیازمند آن است که \fB\fC/etc/resolv.conf\fR یک پیوند نمادین به فایلی خارج از /etc و /run نباشد. .PP هنگام اجرا به عنوان کاربر ریشه (root)، فرآیند وارد فضای نام کاربر نمی‌شود اما تمامی مجوزها (capabilities) به جز \fB\fCCAP\_NET\_BIND\_SERVICE\fR لغو می‌شوند. .PP \fB\fC\-\-enable\-seccomp\fR (از نسخهٔ v0.4.0، آزمایشی) فعال‌سازی \fB\fCseccomp(2)\fR برای محدود کردن فراخوان‌های سیستمی. معمولاً در ترکیب با \fB\fC\-\-enable\-sandbox\fR\& استفاده می‌شود. .PP \fB\fC\-\-outbound\-addr=IPv4\fR (از نسخهٔ v1.1.0، آزمایشی) مشخص کردن آدرس ipv4 خروجی که slirp باید به آن مقید (bind) شود .PP \fB\fC\-\-outbound\-addr=INTERFACE\fR (از نسخهٔ v1.1.0، آزمایشی) مشخص کردن رابط خروجی که slirp باید به آن مقید شود (تنها ترافیک ipv4) .PP \fB\fC\-\-outbound\-addr=IPv6\fR (از نسخهٔ v1.1.0، آزمایشی) مشخص کردن آدرس ipv6 خروجی که slirp باید به آن مقید شود .PP \fB\fC\-\-outbound\-addr6=INTERFACE\fR (از نسخهٔ v1.1.0، آزمایشی) مشخص کردن رابط خروجی که slirp باید به آن مقید شود (تنها ترافیک ipv6) .PP \fB\fC\-\-disable\-dns\fR (از نسخهٔ v1.1.0) غیرفعال کردن DNS داخلی (به‌طور پیش‌فرض 10.0.2.3) .PP \fB\fC\-\-macaddress\fR (از نسخهٔ v1.1.9) مشخص کردن آدرس MAC رابط TAP (فقط با \-c معتبر است) .PP \fB\fC\-\-target\-type=TYPE\fR (از نسخهٔ v1.2.0) مشخص کردن نوع هدف ([netns|bess]، پیش‌فرض=netns). .PP حالت \fB\fCbess\fR (از نسخهٔ v1.2.0، آزمایشی) انتظار می‌رود با User Mode Linux استفاده شود. حالت \fB\fCbess\fR با \fB\fC\-\-configure\fR، \fB\fC\-\-netns\-type\fR، و \fB\fC\-\-userns\-path\fR\& تداخل دارد. .PP \fB\fC\-h\fR, \fB\fC\-\-help\fR (از نسخهٔ v0.2.0) نمایش راهنما و خروج .PP \fB\fC\-v\fR, \fB\fC\-\-version\fR (از نسخهٔ v0.2.0) نمایش نسخه و خروج.SH "مثال (EXAMPLE)" .PP \fBترمینال ۱\fP: ایجاد فضاهای نام user/network/mount .PP .RS .nf (host)$ unshare \-\-user \-\-map\-root\-user \-\-net \-\-mount (namespace)$ echo $$ > /tmp/pid .fi .RE .PP در این مستندات، از \fB\fC(host)$\fR به‌عنوان اعلان (prompt) پوستهٔ میزبان و از \fB\fC(namespace)$\fR به‌عنوان اعلان پوستهٔ در حال اجرا در فضاهای نام استفاده شده است. .PP اگر \fB\fCunshare\fR با شکست مواجه شد، دستورهای زیر را امتحان کنید (مشخص شده است که در Debian، Arch و نسخهٔ قدیمی CentOS 7.X مورد نیاز است): .PP .RS .nf (host)$ sudo sh \-c 'echo "user.max\_user\_namespaces=28633" >> /etc/sysctl.d/userns.conf' (host)$ if [ \-f /proc/sys/kernel/unprivileged\_userns\_clone ]; then sudo sh \-c 'echo "kernel.unprivileged\_userns\_clone=1" >> /etc/sysctl.d/userns.conf'; fi (host)$ sudo sysctl \-\-system .fi .RE .PP \fBترمینال ۲\fP: راه‌اندازی slirp4netns .PP .RS .nf (host)$ slirp4netns \-\-configure \-\-mtu=65520 $(cat /tmp/pid) tap0 starting slirp, MTU=65520 ... .fi .RE .PP \fBترمینال ۱\fP: مطمئن شوید که \fB\fCtap0\fR پیکربندی شده و به اینترنت متصل است .PP .RS .nf (namespace)$ ip a 1: lo: mtu 65536 qdisc noop state DOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 3: tap0: mtu 65520 qdisc fq\_codel state UNKNOWN group default qlen 1000 link/ether c2:28:0c:0e:29:06 brd ff:ff:ff:ff:ff:ff inet 10.0.2.100/24 brd 10.0.2.255 scope global tap0 valid\_lft forever preferred\_lft forever inet6 fe80::c028:cff:fe0e:2906/64 scope link valid\_lft forever preferred\_lft forever (namespace)$ echo "nameserver 10.0.2.3" > /tmp/resolv.conf (namespace)$ mount \-\-bind /tmp/resolv.conf /etc/resolv.conf (namespace)$ curl https://example.com .fi .RE .PP عملیات bind\-mount برای \fB\fC/etc/resolv.conf\fR تنها زمانی لازم است که \fB\fC/etc/resolv.conf\fR در میزبان به آدرس‌های loopback اشاره کند (\fB\fC127.0.0.X\fR، معمولاً \fB\fCdnsmasq(8)\fR یا \fB\fCsystemd\-resolved.service(8)\fR) که از داخل فضای نام قابل دسترس نیستند. .PP اگر \fB\fC/etc/resolv.conf\fR شما در میزبان توسط \fB\fCnetworkmanager(8)\fR یا \fB\fCsystemd\-resolved.service(8)\fR مدیریت می‌شود، ممکن است در عوض نیاز داشته باشید یک سیستم‌فایل جدید را روی \fB\fC/etc\fR سوار (mount) کنید تا هنگام بازتولید \fB\fC/etc/resolv.conf\fR در میزبان، از پیاده شدن (unmount) غیرمنتظرهٔ \fB\fC/etc/resolv.conf\fR جدید جلوگیری شود. .PP .RS .nf (namespace)$ mkdir /tmp/a /tmp/b (namespace)$ mount \-\-rbind /etc /tmp/a (namespace)$ mount \-\-rbind /tmp/b /etc (namespace)$ mkdir /etc/.ro (namespace)$ mount \-\-move /tmp/a /etc/.ro (namespace)$ cd /etc (namespace)$ for f in .ro/*; do ln \-s $f $(basename $f); done (namespace)$ rm resolv.conf (namespace)$ echo "nameserver 10.0.2.3" > resolv.conf (namespace)$ curl https://example.com .fi .RE .PP در صورت نصب بودن \fB\fCrootlesskit\fR، این مراحل را می‌توان با \fB\fCrootlesskit \-\-copy\-up=/etc\fR ساده‌تر کرد: .PP .RS .nf (host)$ rootlesskit \-\-net=slirp4netns \-\-copy\-up=/etc bash (namespace)$ cat /etc/resolv.conf nameserver 10.0.2.3 .fi .RE .SH "مسیریابی بسته‌های PING (ROUTING PING PACKETS)" .PP برای مسیریابی بسته‌های ping، ممکن است نیاز باشد \fB\fCnet.ipv4.ping\_group\_range\fR را با دسترسی ریشه (root) به‌درستی تنظیم کنید. .PP برای نمونه: .PP .RS .nf (host)$ sudo sh \-c 'echo "net.ipv4.ping\_group\_range=0 2147483647" > /etc/sysctl.d/ping\_group\_range.conf' (host)$ sudo sysctl \-\-system .fi .RE.SH "فیلتر کردن اتصالات (FILTERING CONNECTIONS)" .PP به‌طور پیش‌فرض، درگاه‌های شنوا روی \fB\fCINADDR\_LOOPBACK\fR (\fB\fC127.0.0.1\fR) در میزبان، از طریق دروازه (پیش‌فرض: \fB\fC10.0.2.2\fR) از فضای نام فرزند قابل دسترسی هستند. می‌توان از \fB\fC\-\-disable\-host\-loopback\fR برای منع اتصال به \fB\fCINADDR\_LOOPBACK\fR در میزبان استفاده کرد. .PP با این حال، اگر \fB\fC/etc/resolv.conf\fR روی میزبان به یک نشانی لوپ‌بک اشاره کند، نشانی لوپ‌بک میزبان ممکن است همچنان از طریق DNS داخلی (پیش‌فرض: \fB\fC10.0.2.3\fR) در دسترس باشد. در چنین مواردی ممکن است بخواهید iptables را برای محدود کردن دسترسی به DNS داخلی برپا کنید. .PP .RS .nf (host)$ nsenter \-t $(cat /tmp/pid) \-U \-\-preserve\-credentials \-n (namespace)$ iptables \-A OUTPUT \-d 10.0.2.3 \-p udp \-\-dport 53 \-j ACCEPT (namespace)$ iptables \-A OUTPUT \-d 10.0.2.3 \-j DROP .fi .RE .SH "سوکت API (API SOCKET)" .PP برنامه slirp4netns می‌تواند یک سرور API شبیه به QMP را روی یک فایل سوکت UNIX ارائه دهد: .PP .RS .nf (host)$ slirp4netns \-\-api\-socket /tmp/slirp4netns.sock ... .fi .RE .PP \fB\fCadd\_hostfwd\fR: در دسترس قرار دادن یک درگاه (فقط IPv4) .PP .RS .nf (namespace)$ json='{"execute": "add\_hostfwd", "arguments": {"proto": "tcp", "host\_addr": "0.0.0.0", "host\_port": 8080, "guest\_addr": "10.0.2.100", "guest\_port": 80}}' (namespace)$ echo \-n $json | nc \-U /tmp/slirp4netns.sock {"return": {"id": 42}} .fi .RE .PP اگر \fB\fChost\_addr\fR مشخص نشود، مقدار پیش‌فرض آن "0.0.0.0" خواهد بود. .PP اگر \fB\fCguest\_addr\fR مشخص نشود، روی نشانی پیش‌فرضی که متناظر با \fB\fC\-\-configure\fR است تنظیم می‌شود\&. .PP \fB\fClist\_hostfwd\fR: فهرست کردن درگاه‌های در دسترس قرار گرفته .PP .RS .nf (namespace)$ json='{"execute": "list\_hostfwd"}' (namespace)$ echo \-n $json | nc \-U /tmp/slirp4netns.sock {"return": {"entries": [{"id": 42, "proto": "tcp", "host\_addr": "0.0.0.0", "host\_port": 8080, "guest\_addr": "10.0.2.100", "guest\_port": 80}]}} .fi .RE .PP \fB\fCremove\_hostfwd\fR: حذف یک درگاه در دسترس قرار گرفته .PP .RS .nf (namespace)$ json='{"execute": "remove\_hostfwd", "arguments": {"id": 42}}' (namespace)$ echo \-n $json | nc \-U /tmp/slirp4netns.sock {"return": {}} .fi .RE .PP نکات: .RS .IP \(bu 2 کلاینت باید پس از ارسال هر درخواست، سوکت را با \fB\fCSHUT\_WR\fR توسط \fB\fCshutdown(2)\fR ببندد. به این معنی که هیچ پشتیبانی‌ای از keep\-alive و timeout وجود ندارد. .IP \(bu 2 برنامه slirp4netns در حین پردازش درخواست‌های API سامانه را متوقف می‌کند ("stops the world"). .IP \(bu 2 طول هر درخواست باید کمتر از ۴۰۹۶ بایت باشد. .IP \(bu 2 پاسخ‌های JSON ممکن است به جای \fB\fCreturn\fR شامل \fB\fCerror\fR باشند\&. .RE .SH "مسیرهای فضای نام تعریف‌شده (DEFINED NAMESPACE PATHS)" .PP کاربر می‌تواند بر خلاف شناسهٔ فرایند پیش‌فرض، یک مسیر فضای نام شبکه تعریف کند: .PP .RS .nf (host)$ slirp4netns \-\-netns\-type=path ... /path/to/netns tap0 .fi .RE .PP در حال حاضر آرگومان \fB\fCnetns\-type=TYPE\fR از مقادیر \fB\fCpath\fR یا \fB\fCpid\fR پشتیبانی می‌کند که پیش‌فرض آن \fB\fCpid\fR است\&. .PP علاوه بر این، می‌توان آرگومان \fB\fC\-\-userns\-path=PATH\fR را برای بازنویسی مقادیر پیش‌فرض مسیر فضای نام کاربری اضافه کرد .PP .RS .nf (host)$ slirp4netns \-\-netns\-type=path \-\-userns\-path=/path/to/userns /path/to/netns tap0 .fi .RE.SH "آدرس‌های خروجی (OUTBOUND ADDRESSES)" .PP کاربر می‌تواند در سناریوهای دارای چند IP، نشانی‌های IPv4 و IPv6 خروجی ترجیحی را تعیین کند. .PP .RS .nf (host)$ slirp4netns \-\-outbound\-addr=10.2.2.10 \-\-outbound\-addr6=fe80::10 ... .fi .RE .PP همچنین می‌توانید به جای نشانی‌های IP، از نام رابط‌ها (interface) استفاده کنید. .PP .RS .nf (host)$ slirp4netns \-\-outbound\-addr=eth0 \-\-outbound\-addr6=eth0 ... .fi .RE .SH "ارتباط میان فضاهای نام (INTER\-NAMESPACE COMMUNICATION)" .PP ساده‌ترین راه برای برقراری ارتباط میان فضاهای نام، تودرتو کردن (nesting) فضاهای نام شبکه درون فضای نام شبکه slirp4netns است. .PP .RS .nf (host)$ nsenter \-t $(cat /tmp/pid) \-U \-\-preserve\-credentials \-n \-m (namespace)$ mount \-t tmpfs none /run (namespace)$ ip netns add foo (namespace)$ ip netns add bar (namespace)$ ip link add veth\-foo type veth peer name veth\-bar (namespace)$ ip link set veth\-foo netns foo (namespace)$ ip link set veth\-bar netns bar (namespace)$ ip netns exec foo ip link set veth\-foo name eth0 (namespace)$ ip netns exec bar ip link set veth\-bar name eth0 (namespace)$ ip netns exec foo ip link set lo up (namespace)$ ip netns exec bar ip link set lo up (namespace)$ ip netns exec foo ip link set eth0 up (namespace)$ ip netns exec bar ip link set eth0 up (namespace)$ ip netns exec foo ip addr add 192.168.42.100/24 dev eth0 (namespace)$ ip netns exec bar ip addr add 192.168.42.101/24 dev eth0 (namespace)$ ip netns exec bar ping 192.168.42.100 .fi .RE .PP با این حال، این روش زمانی که بخواهید ارتباط میان چندین نمونه slirp4netns را برقرار کنید کارایی ندارد. برای ایجاد ارتباط میان چندین نمونه slirp4netns، باید یک پشته شبکه دیگر مانند \fB\fCvde\_plug(1)\fR را با slirp4netns ترکیب کنید. .PP .RS .nf (host)$ vde\_plug \-\-daemon switch:///tmp/switch null:// (host)$ nsenter \-t $(cat /tmp/pid\-instance0) \-U \-\-preserve\-credentials \-n (namespace\-instance0)$ vde\_plug \-\-daemon vde:///tmp/switch tap://vde (namespace\-instance0)$ ip link set vde up (namespace\-instance0)$ ip addr add 192.168.42.100/24 dev vde (namespace\-instance0)$ exit (host)$ nsenter \-t $(cat /tmp/pid\-instance1) \-U \-\-preserve\-credentials \-n (namespace\-instance1)$ vde\_plug \-\-daemon vde:///tmp/switch tap://vde (namespace\-instance1)$ ip link set vde up (namespace\-instance1)$ ip addr add 192.168.42.101/24 dev vde (namespace\-instance1)$ ping 192.168.42.100 .fi .RE .SH "ارتباط میان میزبان‌ها (INTER\-HOST COMMUNICATION)" .PP استفاده از VXLAN کارآمد و تأییدشده است. برای مشاهده مثالی از یک کلاستر چندگره‌ای Kubernetes بدون ریشه (rootless) به همراه VXLAN، پروژه Usernetes را ببینید: \fB\fChttps://github.com/rootless\-containers/usernetes\fR .SH "حالت BESS (برای USER MODE LINUX)" .PP برنامه slirp4netns (از نسخه v1.2.0 به بعد) می‌تواند به عنوان یک سرور سازگار با BESS برای فراهم کردن اتصال شبکه به User Mode Linux نیز مورد استفاده قرار گیرد. .PP \fBترمینال ۱\fP: آغاز slirp4netns .PP .RS .nf (host)$ slirp4netns \-\-target\-type=bess /tmp/bess.sock .fi .RE .PP \fBترمینال ۲\fP: آغاز User Mode Linux .PP .RS .nf (host)$ linux.uml vec0:transport=bess,dst=/tmp/bess.sock,depth=128,gro=1 root=/dev/root rootfstype=hostfs init=/bin/bash mem=2G (UML)$ ip addr add 10.0.2.100/24 dev vec0 (UML)$ ip link set vec0 up (UML)$ ip route add default via 10.0.2.2 .fi .RE .PP در حال حاضر، تنها یک نمونه واحد از User Mode Linux می‌تواند به سرور BESS متعلق به slirp4netns متصل شود. .PP همچنین مستندات User Mode Linux را ببینید: \fB\fChttps://www.kernel.org/doc/html/latest/virt/uml/user\_mode\_linux\_howto\_v2.html#bess\-socket\-transport\fR.SH "گزارش باگ‌ها (BUGS)" .PP در هستهٔ 4.20 مقدار پیش‌فرض \fB\fC/proc/sys/net/ipv4/tcp\_rmem\fR از 87380 به 131072 افزایش یافت. مشخص شده است که این تغییر موجب کاهش سرعت فوروارد پورت (port forwarding) در slirp4netns می‌شود: \fB\fChttps://github.com/rootless\-containers/slirp4netns/issues/128\fR\&. .PP به‌عنوان یک راهکار موقت، می‌توانید مقدار \fB\fC/proc/sys/net/ipv4/tcp\_rmem\fR را در داخل فضای نام (namespace) تنظیم کنید. از هستهٔ 4.15 به بعد، برای تغییر این فایل نیازی به دسترسی واقعی ریشه (root) نیست. .PP .RS .nf (host)$ nsenter \-t $(cat /tmp/pid) \-U \-\-preserve\-credentials \-n \-m (namespace)$ c=$(cat /proc/sys/net/ipv4/tcp\_rmem); echo $c | sed \-e s/131072/87380/g > /proc/sys/net/ipv4/tcp\_rmem .fi .RE .SH "همچنین ببینید (SEE ALSO)" .PP \fB\fCnetwork\_namespaces(7)\fR, \fB\fCuser\_namespaces(7)\fR, \fB\fCveth(4)\fR .SH "در دسترس بودن (AVAILABILITY)" .PP دستور slirp4netns تحت «اجازه‌نامهٔ عمومی همگانی گنو» نسخهٔ 2 (یا نسخه‌های بالاتر) از نشانی \fB\fChttps://github.com/rootless\-containers/slirp4netns\fR در دسترس است.