במקור, הגדרת הבלוג שלי תוכננה כפרויקט IPv6 בלבד דרך WireGuard, מכיוון שהכל פועל על שרת ביתי (אגב, ניתן לקבל כתובות IPv6 בחינם ב-route64.org). כדי לשפר את הזמינות, הוספתי כעת פרוקסי IPv4 חיצוני (תודה ל-@Larvitz).
עם זאת, מיד צצו בעיות SSL: מכיוון שבמקור גם רשומת ה-A וגם רשומת ה-AAAA עברו דרך הפרוקסי, אימות ה-Let's Encrypt בשרת שלי נכשל.
הפתרון: ה-„IPv6-Hack“
הפתרון היה לכוון את רשומת ה-AAAA באופן מפורש ישירות לכתובת ה-WireGuard של השרת שלי, במקום להעביר אותה גם כן דרך הפרוקסי.
- דומיין:
blog.burningboard.org - רשומת A (פרוקסי):
194.28.98.217 - רשומת AAAA (שרת):
2a11:6c7:f05:a8::2(WireGuard)
באמצעות רשומת ה-AAAA הישירה הזו לכתובת ה-WireGuard שלי, Let’s Encrypt ממשיך להגיע לשרת שלי ישירות דרך IPv6 (מכיוון שרשומת AAAA מקבלת עדיפות כברירת מחדל) ומנפיק את תעודת ה-SSL. תעבורת ה-IPv4 מועברת אליי מהפרוקסי כשהיא מוצפנת.
הקונפיגורציה הסופית
כדי שהתקשורת תעבוד בצורה חלקה, היינו צריכים להתאים את שרתי ה-Caddy:
1. בשרת שלי (NixOS, blog.nix)
כדי שכתובות ה-IP האמיתיות של המבקרים יגיעו בצורה נכונה ולא יידרסו על ידי כתובת ה-IP של הפרוקסי, יש לסמן אותו כנאמן (trusted):
services.caddy.globalConfig = ''
servers {
trusted_proxies static 2a06:9801:1c:1000::10
}
'';
2. בפרוקסי החיצוני (Caddy)
כדי שהפרוקסי יפנה לשרת שלי בצורה נכונה דרך HTTPS, עליו לשלוח את שם המארח (SNI):
reverse_proxy [https://[2a11:6c7:f05:a8::2]:443](https://[2a11:6c7:f05:a8::2]:443) {
header_up Host {host}
transport http {
tls_server_name blog.burningboard.org
}
}
הבלוג זמין כעת דרך IPv4 ו-IPv6, מוצפן בצורה מאובטחת, וכתובת ה-IP הביתית שלי נשארת פרטית! 🚀
