ניהול firewalld ב-Rocky Linux ו-AlmaLinux: מדריך מעשי

מהו firewalld ומדוע Rocky ו-AlmaLinux מפיצות אותו

firewalld הוא מנהל ה-firewall המותקן כברירת מחדל ב-Rocky Linux, ב-AlmaLinux ובהפצות נוספות המבוססות על Red Hat Enterprise Linux (RHEL). הוא אינו מבצע בדיקה של חבילות (packets) בעצמו. הוא שומר תצורה וממיר אותה לחוקי nftables. פקודה אחת, firewall-cmd, עורכת את התצורה בזמן שהשרת נשאר פעיל.

אם אתם כבר מכירים את אופן הפעולה של ufw בשרת Ubuntu VPS, אתם מכירים את התפקיד. firewalld מוסיף שני מושגים שאינם קיימים ב-ufw. הראשון הוא zones: מדיניות בעלת שם שאליה ממוינות חבילות. השני הוא הפרדה בין חוקים פעילים (live) לחוקים שמורים, המתבצעת באמצעות הדגל --permanent, והיא המקור העיקרי לבלבול בכלי זה.

כל מה שמופיע להלן הוא פקודה שיש להריץ בשרת שלכם. בדקו כל שינוי ממכונה שנייה, כיוון שחוק שנראה תקין בתוך השרת עלול להיות שגוי כשניגשים אליו מהאינטרנט.

פתח את SSH לפני כל פעולה אחרת

רוב ההתקנות של Rocky ושל AlmaLinux כוללות את firewalld כברירת מחדל, והתצורה המגיעה עם המערכת מאפשרת SSH. חלק מתמונות הענן המינימליות מסירות אותו. בדוק זאת במקום להניח שהשירות קיים.

sudo dnf install -y firewalld
sudo systemctl enable --now firewalld
sudo firewall-cmd --state

firewall-cmd --state מדפיס running. אם השירות אינו פעיל, כל קריאת firewall-cmd אחרת תחזיר FirewallD is not running ותסתיים עם קוד שגיאה שאינו אפס. זהו הדבר הראשון שיש לבדוק כאשר נראה שפקודה אינה מבצעת דבר.

כעת בדוק אילו שירותים מורשים כרגע.

sudo firewall-cmd --list-all

הפלט המלא מכיל שורות נוספות. אלו השורות החשובות:

public (active)
  target: default
  interfaces: eth0
  sources:
  services: cockpit dhcpv6-client ssh
  ports:
  rich rules:

ssh בשורת ה-services: היא הסיבה לכך שהסשן שלך עדיין פעיל. אם היא חסרה, הוסף אותה לפני שתשנה דבר אחר, שכן הפעלת חומת אש ללא חוק SSH תנתק את הסשן ולא תאפשר לך להתחבר מחדש.

sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

target: default פירושו שחבילה שאינה תואמת לאף חוק נדחית עם הודעת ICMP (פרוטוקול הודעות בקרה באינטרנט) מסוג host-prohibited, כך שלקוח המנסה להתחבר לפורט סגור מקבל No route to host באופן מיידי. הגדרת היעד ל-DROP תגרום לשרת להישאר שקט, וסורקים ימתינו עד ל-timeout.

sudo firewall-cmd --permanent --zone=public --set-target=DROP
sudo firewall-cmd --reload

הבן את המשמעות לפני שתריץ זאת: DROP גם מונע מהשרת להשיב ל-ping, כך שגם מערכות הניטור שלך יפסיקו לקבל מענה.

מדוע הכלל שלי נעלם? הדגל --permanent

ל-firewalld יש שתי תצורות במקביל. תצורת ה-runtime היא מה שה-kernel אוכף ברגע זה. התצורה ה-permanent היא מה שנשמר ב-/etc/firewalld/zones/public.xml ומה שחוזר לאחר טעינה מחדש (reload) או אתחול (reboot).

פקודה ללא --permanent משנה את ה-runtime בלבד. היא עובדת מיידית אך נעלמת בטעינה או באתחול הבא. פקודה עם --permanent כותבת לקובץ ולא משנה דבר שרץ כרגע, לכן הפורט נשאר סגור עד שתבצעו reload. אף אחת מההתנהגויות הללו אינה באג. שתיהן מפתיעות משתמשים, כיוון שהפקודה מדפיסה success בכל מקרה.

כתבו את הצמד בכל פעם.

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --reload

ניתן לקרוא את שתי התצורות, וזו הדרך המהירה ביותר לגלות איזו משתי הטעויות ביצעתם.

sudo firewall-cmd --list-services
sudo firewall-cmd --permanent --list-services

הראשונה מדפיסה את הסט הפעיל. השנייה מדפיסה את הסט השמור. אם הסט הפעיל מכיל שירות שהסט השמור לא מכיל, הכלל הזה ימות בטעינה הבאה. אם הסט השמור מכיל שירות שהסט הפעיל לא מכיל, שכחתם לבצע reload. הפקודה sudo firewall-cmd --runtime-to-permanent מעתיקה את כל הסט הפעיל לקובץ השמור, דבר שימושי לאחר סשן של ניסויים.

הפקודה --reload שומרת על מצב מעקב החיבורים (connection tracking), כך שסשן ה-SSH שלכם ישרוד אותה. הפקודה --complete-reload טוענת מחדש גם את מודולי ה-kernel ומאבדת את המצב הזה, מה שבדרך כלל מנתק כל חיבור פתוח, כולל שלכם. השתמשו ב-reload הרגיל.

רשת ביטחון אחת מובנית במערכת. כלל runtime יכול לפוג מעצמו.

sudo firewall-cmd --add-service=http --timeout=5m

הכלל הזה מסיר את עצמו לאחר חמש דקות. לא ניתן לשלב אותו עם --permanent, וזו בדיוק הנקודה: הוא קיים לצורך בדיקת שינוי שאינכם בטוחים לגביו. רשת הביטחון הישנה יותר טובה: השאירו סשן SSH שני פתוח בזמן שאתם עורכים חוקים, ואל תסגרו אותו עד ש-login חדש יוכיח שהחוקים החדשים עובדים.

אזורים (Zones), ומדוע רק אזור ברירת המחדל רלוונטי בשרת VPS

אזור הוא קבוצה בעלת שם של הרשאות עם רמת אמון משויכת. firewalld משייך כל חבילת מידע נכנסת לאזור אחד בלבד. המערכת משווה את כתובת המקור של החבילה מול רשימת ה-sources: של כל אזור. אם אין התאמה, המערכת משתמשת באזור שאליו משויך ממשק הרשת הנכנס. אם הממשק אינו משויך לאף אזור, החבילה מועברת לאזור ברירת המחדל.

sudo firewall-cmd --get-default-zone
sudo firewall-cmd --get-active-zones

בשרת VPS עם ממשק רשת אחד, התשובה הראשונה היא כמעט תמיד public, וזהו האזור היחיד שבו תשתמשו. הפקודה firewall-cmd ללא הארגומנט --zone= פועלת על אזור ברירת המחדל, וזו הסיבה שכל פקודה קצרה במדריך זה עובדת ללא ציון שם האזור.

להלן הכשל שגורם לבזבוז זמן רב: אם הממשק משויך לאזור אחר, החוקים שלכם יוחלו על public בזמן שהתעבורה מטופלת במקום אחר, כך ששום דבר שתוסיפו לא ישפיע ולא תקבלו על כך התראה. הפקודה --get-active-zones מציגה את השיוך:

public
  interfaces: eth0

אם הממשק מופיע תחת שם אזור שונה, עליכם לכתוב את החוקים שלכם שם באמצעות --zone=, או להעביר את הממשק.

sudo firewall-cmd --permanent --zone=public --change-interface=eth0
sudo firewall-cmd --reload

NetworkManager מנהל את הממשקים ב-Rocky וב-AlmaLinux, והוא מחיל מחדש את האזור בכל פעם שהחיבור עולה. הגדירו זאת גם שם כדי שאתחול (reboot) לא יבטל את עבודתכם. קחו את שם החיבור מהפקודה הראשונה, שכן הוא כמעט אף פעם אינו זהה לשם ההתקן (device).

sudo nmcli connection show
sudo nmcli connection modify "System eth0" connection.zone public

התאמה לפי כתובת מקור (Source matching) גוברת על התאמה לפי ממשק, וזו הדרך שבה כתובת אחת מקבלת מדיניות שונה. האזור המובנה trusted מאשר הכל.

sudo firewall-cmd --permanent --zone=trusted --add-source=203.0.113.10/32
sudo firewall-cmd --reload

היזהרו עם אזור זה. הוא פותח כל פורט בשרת עבור אותה כתובת, כולל מסד הנתונים שחשבתם שהוא פרטי. השתמשו ב-rich rule כאשר אתם מעוניינים בפורט אחד בלבד, ולא במארח (host) שלם.

מהו שירות ב־firewalld?

שירות הוא אוסף בעל שם של פורטים, המסופק כקובץ XML. הפקודה --add-service=https פותחת את פורט 443/tcp מכיוון ש-/usr/lib/firewalld/services/https.xml מגדיר מה המשמעות של https.

sudo firewall-cmd --get-services
sudo firewall-cmd --info-service=https

הפקודה --info-service מציגה את הפורטים המסתתרים מאחורי השם:

https
  ports: 443/tcp

השתמשו בשם כאשר הוא קיים. הדבר משפר את הקריאות של --list-all כעבור שישה חודשים, וחבילות כגון Cockpit מתקינות קובץ שירות משלהן. השתמשו ב---add-port עבור כל דבר שאין לו הגדרה.

הפער שיש לשים לב אליו: השירות ssh משמעותו 22/tcp ותו לא. אם העברתם את SSH לפורט אחר במסגרת הקשחת הגישה ל-SSH בשרת, אזי --add-service=ssh לא יפתח את הפורט שבו אתם משתמשים בפועל.

sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload

בהפצות מבוססות RHEL קיים מנעול נוסף על הדלת הזו. SELinux (קיצור של security-enhanced Linux) מתייג מספרי פורטים, ו-sshd אינו מורשה להיקשר (bind) לפורט שאינו תואם את התוויות שלו. במקרה כזה הוא מסרב לעלות, והלוג מציג error: Bind to port 2222 on 0.0.0.0 failed: Permission denied.. יש לתייג את הפורט תחילה.

sudo dnf install -y policycoreutils-python-utils
sudo semanage port -a -t ssh_port_t -p tcp 2222

כיצד ניתן לראות מה פתוח כרגע?

sudo firewall-cmd --list-all
sudo firewall-cmd --list-rich-rules
sudo nft list table inet firewalld | head -n 40

שני הכלים הראשונים מציגים את מה ש־firewalld "חושב" שמוגדר. הכלי השלישי קורא את הכללים שהקרנל (kernel) אוכף בפועל בטבלה שבבעלות firewalld. עליהם להציג תוצאות זהות.

אף אחד מאלו אינו מהווה הוכחה מוחלטת. בצעו בדיקה ממכונה אחרת:

nc -zv 203.0.113.20 443

אל תריצו את הבדיקה מהשרת עצמו. firewalld מאשר כל תעבורה שמגיעה דרך ממשק ה-loopback, לכן curl http://localhost:8080 יצליח ללא קשר לכללים שהגדרתם. בדיקה זו מאשרת רק שהשירות פעיל, אך אינה מעידה דבר על מצב ה-firewall.

אפשור פורט אינטרנט

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-services

הפקודה האחרונה אמורה כעת להציג את http https לצד מה שהיה שם קודם. אם האתר עדיין אינו מגיב, ייתכן שהבעיה אינה ב־firewall. חוק מאפשר מעבר חבילות מידע (packets), אך תהליך עדיין צריך להאזין להן.

sudo ss -tlnp

socket שמוצג כ־0.0.0.0:443 או *:443 מקבל חיבורים מכל כתובת. socket שמוצג כ־127.0.0.1:443 מגיב ב־loopback בלבד, ושום חוק firewall לא יהפוך אותו לנגיש מבחוץ. המדריך פורטים ו־sockets מאזינים ב־Linux מכסה את ההבדל הזה בפירוט רב יותר.

כיצד סוגרים פורט שוב?

sudo firewall-cmd --permanent --remove-service=http
sudo firewall-cmd --reload

הכלל של --permanent חל גם כאן, והוא משמעותי יותר בכיוון הזה. הסרת שירות מה-runtime בלבד גורמת לפורט להיראות סגור, אך בטעינה מחדש או ב-reboot הבא הוא ייפתח שוב מתוך הקובץ השמור. זהו פרצת אבטחה שלא תבחינו בה, כיוון שהבדיקה שביצעתם עברה בהצלחה.

הסרה של רכיב שלא היה קיים מדפיסה Warning: NOT_ENABLED: http ועדיין מסתיימת ב-exit code 0. הוספה של אותו רכיב פעמיים מדפיסה Warning: ALREADY_ENABLED: http. שני המקרים בטוחים. שם שגוי הוא סיפור אחר: Error: INVALID_SERVICE משמעותו של-firewalld אין הגדרה בשם הזה ושום דבר לא השתנה.

אם ה---list-all שלכם מציג cockpit ואתם לא משתמשים ב-Cockpit web console בפורט 9090, הסירו אותו. כל פורט פתוח הוא שירות שאתם חייבים לתחזק ולעדכן.

הגבלת פורט לכתובת מקור אחת

כללי Rich הם הדרך המפורטת להגדרה, עבור מקרים שבהם שם שירות פשוט אינו מספיק כדי להגדיר את כוונתכם. הגבלת גישת SSH לכתובת IP אחת של משרד דורשת הרצה של שתי פקודות, והשנייה שבהן היא זו שאנשים נוטים לשכוח.

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.10/32" service name="ssh" accept'
sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --reload

אזור (zone) הוא אוסף של הרשאות, ולא רשימה ממוספרת שנעצרת בהתאמה הראשונה. כלל ה-Rich מוסיף אישור (accept) עבור כתובת אחת. הוא אינו חוסם איש. כל עוד ssh נמצא בשורת ה-services:, כל האינטרנט עדיין מגיע לפורט 22 וכלל ה-Rich אינו משנה דבר שניתן למדוד. הסירו את ההגדרה הרחבה, אחרת ההגדרה הצרה היא בגדר קישוט בלבד.

עבור פורט שאין לו שם שירות, ציינו את מספר הפורט במקום.

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.10/32" port port="5432" protocol="tcp" accept'

כדי להשליך (drop) תעבורת רשת רועשת ולשמור תיעוד, הציבו את אלמנט ה-log לפני הפעולה; זהו הסדר ששפת כללי ה-Rich מצפה לו.

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="198.51.100.0/24" log prefix="fw-drop " level="info" limit value="3/m" drop'
sudo firewall-cmd --reload
sudo journalctl -k -g fw-drop

הערך limit מונע הצפה של חבילות הממלאות את ה-journal. לפני שאתם נועלים את ה-SSH לכתובת אחת, ודאו שכתובת זו יציבה. חיבור ביתי עם כתובת IP משתנה ינעל אתכם מחוץ לשרת ביום שבו הכתובת תתחלף, לכן ודאו תחילה שגישת ה-console של ספק השירות שלכם נבדקה ועובדת.

פקודות ufw והמקבילות שלהן ב-firewall-cmd

אותן משימות, כלי שונה. כל שורת --permanent זקוקה ל-sudo firewall-cmd --reload אחריה, וזהו הדבר היחיד שרשימה מסוג זה לא יכולה להראות לכם.

• sudo ufw enable הופך ל-sudo systemctl enable --now firewalld
• sudo ufw disable הופך ל-sudo systemctl disable --now firewalld
• sudo ufw status verbose הופך ל-sudo firewall-cmd --list-all
• sudo ufw allow OpenSSH הופך ל-sudo firewall-cmd --permanent --add-service=ssh
• sudo ufw allow 443/tcp הופך ל-sudo firewall-cmd --permanent --add-port=443/tcp
• sudo ufw delete allow 443/tcp הופך ל-sudo firewall-cmd --permanent --remove-port=443/tcp
• sudo ufw allow from 203.0.113.10 to any port 22 הופך לכלל העשיר (rich rule) המוצג לעיל
• sudo ufw reload הופך ל-sudo firewall-cmd --reload
• sudo ufw default deny incoming הוא כבר האופן שבו אזור public מתנהג, ו---set-target=DROP הוא הגרסה השקטה שלו
• sudo ufw logging on הופך ל-sudo firewall-cmd --set-log-denied=all

הבדל אחד ראוי לציון מפורש. ufw מנהל רשימה ממוספרת וניתן להוסיף כלל במיקום 1. ב-firewalld אין מספרי כללים, לכן "הצב כלל זה ראשון" אינו רלוונטי כאן. כאשר שני ערכי firewalld נראים כסותרים זה את זה, הכלל הרחב יותר (accept) הוא הקובע, מכיוון שאין בסט הכללים הגדרה של deny. עליכם להסיר את הכלל הרחב בעצמכם.

מדוע מכולת Docker שלי נגישה למרות שה־firewall נראה סגור?

מכיוון שפורט של מכולה שפורסם (published) לעולם לא מגיע לחלק של ה־firewall שהאזור (zone) שלך מנהל. docker run -d -p 8080:80 nginx מורה ל־Docker לכתוב חוקי NAT (תרגום כתובות רשת) וניתוב משלו. חבילה שמגיעה לפורט 8080 עוברת שכתוב וניתוב הלאה למכולה, ולכן היא מועברת (forwarded) במקום להימסר למארח (host). השורות services: ו־ports: באזור שלך מנהלות חבילות שנמסרות למארח. החוקים של Docker מנהלים את נתיב ההעברה, והם מאשרים את התעבורה.

התוצאה היא שרת שבו sudo firewall-cmd --list-all לא מציג את פורט 8080, אך nc -zv 203.0.113.20 8080 ממכונה אחרת מתחבר בכל זאת. בדוק מה Docker התקין:

sudo iptables -t nat -L DOCKER -n

התיקון נמצא בדגל הפרסום (publish flag). קשור את הפורט ל-loopback והצב לפניו reverse proxy.

docker run -d -p 127.0.0.1:8080:80 nginx

המכולה כעת עונה ל-curl http://127.0.0.1:8080 בתוך השרת ולא לשום דבר מבחוץ. משתמשי Ubuntu נתקלים באותה בעיה, המתוארת ב-מדוע מכולות Docker מפרסמות פורטים ישירות מעבר ל-ufw. גרסת ה-rootful של Podman, ש-Rocky ו-AlmaLinux מספקות במאגרים הבסיסיים, מפרסמת פורטים באותה גישת NAT, לכן בצע בדיקה ממכונה אחרת במקום להסתמך על רשימת האזורים.

הבטחת פעילות לאחר אתחול, והשגיאות שתפגשו

sudo systemctl is-enabled firewalld
sudo systemctl status firewalld

enabled ו־active (running) הם הכלים הדרושים לכם. חומת אש שרצה אך לא הוגדרה לעלייה אוטומטית תגן עליכם רק עד האתחול הראשון. בדיקה זו צריכה להופיע ברשימת המשימות שלכם ב־עשר הדקות הראשונות בשרת VPS חדש, לצד מפתחות SSH ועדכונים.

פקודות nftables גולמיות ו־firewalld אינן עובדות יחד. ל־firewalld יש טבלה בשם inet firewalld. פקודת sudo nft flush ruleset מוחקת אותה, השרת נותר חשוף לכל, ו־firewall-cmd --list-all עדיין תציג את התצורה המבוקשת שלכם, כיוון ש־firewalld מדווחת על מה שהיא סבורה שקיים ולא על מה שמוגדר בפועל ב־kernel. פקודת sudo firewall-cmd --reload מתקינה מחדש את החוקים. כתבו חוקים באמצעות firewall-cmd כדי שיחזרו לאחר טעינה מחדש.

שני מנהלי חומת אש על שרת אחד. התקנת ufw או iptables-services לצד firewalld יוצרת שני תהליכים שכותבים חוקים ללא מודעות זה לזה; המנצח הוא השירות שעלה אחרון. בחרו אחד. ב־Rocky וב־AlmaLinux,‏ firewalld היא הכלי הנתמך על ידי ההפצה.

חומת האש של ספק השרתים. לממשקי ניהול רבים של VPS יש חומת אש רשתית נפרדת. אם --list-all מראה שפורט פתוח וחיבור מבחוץ עדיין נכשל, בדקו את ממשק הניהול לפני שתשנו משהו בשרת. זה עובד גם הפוך: חוק פתוח בממשק הניהול לא יועיל אם firewalld דוחה את החבילה.

הרצת firewall-cmd ללא sudo. כל שינוי דורש הרשאות root. ללא הרשאות אלו, הבקשה נדחית על ידי מנגנון האימות ושום דבר לא משתנה, מה שנראה במבט חטוף כאילו הפקודה התעלמה מהבקשה.

שש פקודות מכסות את רוב צורכי היומיום: --list-all לקריאת המצב, --permanent --add-service או --add-port לפתיחת פורט, --permanent --remove-service לסגירתו, --reload להחלת הקובץ השמור, ו־--runtime-to-permanent לאחר סבב ניסויים. האזור (zone) הוא public, הדגל (flag) הוא --permanent, והבדיקה האמינה היחידה מגיעה ממכונה אחרת.

FAQ

מדוע חוק ה-firewalld שלי נעלם לאחר אתחול?

החוק הוחל על תצורת ה-runtime בלבד. sudo firewall-cmd --add-service=http מיושם באופן מיידי אך נמחק בטעינה מחדש או באתחול הבא, כיוון שהתצורה השמורה ב-/etc/firewalld/zones/public.xml לא עודכנה. הוסיפו את --permanent ולאחר מכן הריצו את sudo firewall-cmd --reload. כדי לשמור חוקים שכבר הוספתם ידנית, הריצו את sudo firewall-cmd --runtime-to-permanent, אשר מעתיק את סט החוקים הפעיל לקובץ השמור.

מדוע שום דבר לא משתנה לאחר הוספת חוק עם --permanent?

מכיוון ש---permanent כותב את הקובץ אך לא משנה את ה-firewall הפעיל. הפורט נשאר סגור עד ש-sudo firewall-cmd --reload טוען את התצורה השמורה לתוך ה-kernel. השוו בין sudo firewall-cmd --list-services לבין sudo firewall-cmd --permanent --list-services: אם הרשימה השמורה מכילה ערך שאינו מופיע ברשימה הפעילה, סימן שחסרה לכם טעינה מחדש (reload).

האם עלי להשתמש ב---add-service או ב---add-port?

השתמשו ב---add-service כאשר קיים שם מוגדר עבור השירות שאתם מריצים. הוא מצהיר על הכוונה, ו-sudo firewall-cmd --info-service=https מציג בדיוק אילו פורטים השם מכסה. השתמשו ב---add-port כאשר אין הגדרה לשירות שלכם, או כאשר הוא מאזין בפורט לא סטנדרטי. השירות ssh משמעותו 22/tcp בלבד, לכן אם העברתם את SSH לפורט 2222, עליכם להשתמש ב---add-port=2222/tcp בצירוף תווית SELinux מתאימה לאותו פורט.

מדוע מכולת Docker נגישה למרות ש-firewall-cmd מראה שהפורט סגור?

פורט שפורסם (published) עובר שינוי על ידי חוקי ה-NAT של Docker ומועבר למכולה, כך שהחבילה (packet) לעולם לא מגיעה למארח (host), ורשימות השירותים והפורטים של ה-zone מכסות רק חבילות המגיעות למארח. המכולה עונה מהאינטרנט בזמן ש---list-all לא מציג דבר. פרסמו ל-loopback במקום זאת, באמצעות docker run -d -p 127.0.0.1:8080:80 nginx, והציבו reverse proxy לפני המכולה.

האם ניתן להתקין ufw על Rocky Linux במקום firewalld?

שני מנהלי firewall על אותו שרת כותבים חוקים ללא מודעות זה לזה, והסט שישרוד תלוי בשירות שעלה אחרון. firewalld הוא הכלי הנתמך ב-Rocky Linux וב-AlmaLinux, הוא מותקן כברירת מחדל, והוא מנהל את אותו backend של nftables ש-ufw היה מנהל. למדו את ה-zone המוגדר כברירת מחדל ואת הדגל --permanent, ויהיה בידיכם הכלי המלא.