VPN شما فقط پس از ورود به دلیل حلقه کلید کار می‌کند

دستور وقتی وارد شده‌اید کار می‌کند، پس آن را در یک اسکریپت راه‌اندازی می‌گذارید و به خانه می‌روید. صبح روز بعد ماشین آنلاین است و تونل نه. افسانه این است که فراخوانی کارآمد یعنی سرویس کارآمد. در عمل تفاوت معمولاً یکی از دو چیز است: پروفایل به نشست کاربری شما تعلق دارد نه به سیستم، یا راز با چیزی باز می‌شود که فقط پس از ورود شما وجود دارد. هر دو در آزمایش دستی بی‌عیب کار می‌کنند و دقیقاً در لحظه‌ای شکست می‌خورند که هیچ‌کس نگاه نمی‌کند.

چرا ورود آن را کار می‌اندازد

ورود گرافیکی یک باس نشست و یک عامل سرویس راز راه می‌اندازد، و همین‌جاست که بسیاری از کلاینت‌های دسکتاپی گذرواژه پروفایل یا عبارت عبور کلید خصوصی را نگه می‌دارند. فعال‌سازی‌ای که پس از ورود به‌عنوان کاربر شما اجرا می‌شود می‌تواند آن راز را از این عامل بخواهد و موفق شود. همان فعال‌سازی که توسط واحد زمان بوت اجرا می‌شود هیچ نشست، باس و عاملی ندارد، بنابراین جستجو شکست می‌خورد یا روی درخواستی که کسی نمی‌بیند مسدود می‌شود.

همان پروفایل را پیش و پس از ورود اجرا کنید و از یک پیکربندی دو نتیجه متفاوت می‌گیرید. این نشانه وابستگی به اعتبارنامه است، نه تونل خراب، و توضیح می‌دهد چرا یک آزمایش دستی در ترمینال کمتر از آنچه به نظر می‌رسد اثبات می‌کند. تونل سالم است؛ چیزی که راز آن را باز می‌کند غایب است.

تصمیم بگیرید کدام مالک تونل را راه می‌اندازد

دو الگوی پشتیبانی‌شده وجود دارد و آمیختن آن‌ها راه دیگری برای شکست این کار است. NetworkManager می‌تواند اتصالی در سطح سیستم فعال کند، که وقتی ماشین از قبل شبکه خود را آنجا متمرکز کرده مناسب است. در عوض، یک واحد systemd اختصاصی VPN را مستقیماً اجرا می‌کند و خودش مالک رابط است.

systemctl list-unit-files 'openvpn*'
systemctl list-unit-files 'wg-quick*'
nmcli connection show --active
systemctl enable --now wg-quick@wg0

هر دو مالک را روی یک پیکربندی اجرا نکنید. اگر NetworkManager رابط را مدیریت کند و یک واحد هم آن را بالا بیاورد، بر سر مسیرها و DNS با هم می‌جنگند و وضعیت حاصل به این بستگی دارد که کدام دیرتر تمام شده است.

راز را جایی بگذارید که سرویس بتواند بخواند

سرویس پس‌زمینه نمی‌تواند به یک درخواست پاسخ دهد. عبارت‌های عبور گواهی، گذرواژه‌های حساب و فایل‌های احراز هویت ارجاع‌شده همگی به چیدمان ذخیره‌سازی نیاز دارند که واحد بدون انسان به آن برسد، متعلق به حسابی باشد که سرویس را اجرا می‌کند و برای بقیه ناخوانا باشد.

میان‌بر وسوسه‌انگیز این است که فایل را تا ناپدید شدن خطای مجوز برای همه خوانا کنید. این یک شکست راه‌اندازی را با افشای طولانی‌مدت اعتبارنامه معاوضه می‌کند و همان تغییری است که هیچ‌کس به آن بازنمی‌گردد. از سازوکاری استفاده کنید که استقرار از قبل به آن اعتماد دارد: یک فایل اعتبارنامه محدود، یک کلید رمزنگاری‌نشده که با مجوزهای فایل محافظت می‌شود، یا اتصالی در سطح سیستم با انبار راز خودش.

رویدادی را آزمایش کنید که واقعاً رخ می‌دهد

راه‌اندازی دستی سرویس پس از ورود تقریباً هیچ چیز را آزمایش نمی‌کند. راه‌اندازی مجدد کنید، یا ورود گرافیکی را برای یک چرخه غیرفعال کنید، و ببینید واحد خودبه‌خود بالا می‌آید. این تنها آزمایشی است که دسترس‌پذیری اعتبارنامه، آمادگی شبکه و ترتیب واحدها را با هم به کار می‌گیرد. همچنین همان آزمایشی است که شکستی را که کاربر گزارش کرده بازتولید می‌کند، کاری که راه‌اندازی دستی هرگز نمی‌کند.

systemctl is-enabled wg-quick@wg0
journalctl -u wg-quick@wg0 -b --no-pager
systemctl status systemd-networkd-wait-online --no-pager

ترتیب به اندازه اعتبارنامه اهمیت دارد. واحدی که پیش از پیکربندی پیوند بالادستی زیرین شروع شود تسلیم می‌شود، و برخی توزیع‌ها در اینکه منتظر اتصال بمانند یا نه متفاوت‌اند. اگر واحد هنگام بوت شکست گزارش کند اما وقتی سی ثانیه بعد با دست راه‌اندازی شود موفق شود، مشکل ترتیب یافته‌اید نه مشکل راز.

مسیرها و DNS را بررسی کنید، نه فقط رابط را

رابطی که وجود دارد تونل کارآمدی نیست. پس از یک راه‌اندازی بدون نظارت، پیش از بررسی یک نام، مسیرها، وضعیت حل‌کننده و یک مقصد را بر اساس نشانی بررسی کنید. سپس برنامه‌ای را که تونل برای آن وجود دارد بررسی کنید.

ip -4 route show
resolvectl status
ping -c 3 10.61.0.1
curl -sS --max-time 5 https://internal.example/ -o /dev/null -w '%{http_code}\n'

اگر نشانی کار کند و نام نه، مشکل باقی‌مانده سیاست DNS است نه تونل. ثبت کنید کدام مالک سرویس را راه می‌اندازد و راز کجا زندگی می‌کند، چون نفر بعدی که این ماشین را راه‌اندازی مجدد می‌کند به هر دو واقعیت نیاز خواهد داشت.