במקור, הגדרת הבלוג שלי תוכננה כפרויקט 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 הביתית שלי נשארת פרטית! 🚀