Тестирајте го обновувањето на VPN серверот по рестартирање: што прво да проверите
Рестартирајте додека никој не е најавен, потоа поврзете се однадвор. Проверете ја единицата, интерфејсот, рутите и правилата на огнениот ѕид што треба сами да се вратат.
Рестартирајте го серверот додека никој не е најавен, потоа поврзете се од мрежа што не ја контролирате. Овој единствен тест одговара дали обновувањето е вистинско, бидејќи тунел што работи само откако некој рачно ќе изврши наредба не е обновување, туку поправка. Повеќето проверки запираат премногу рано: демонот изгледа активен, интерфејсот се крева, а страницата сепак не се вчитува. Јазот речиси секогаш е во постојаноста на деловите околу тунелот, не во самата наредба на тунелот.
Четири сопственици, четири различни теста
Пред рестартирањето, именувајте што треба да го врати тунелот. Тестот што го извршувате и поправката што ја применувате зависат од тој одговор, а има четири вообичаени сопственици: systemd единица за демонот на VPN, единица на примерок wg-quick за интерфејс на WireGuard, runtime за контејнери или профил на мрежен менаџер. Ако не можете да го именувате сопственикот, запрете и пронајдете го, бидејќи тест за рестартирање без очекуван пат за стартување само ви кажува дека нешто се случило.
Секој сопственик ја чува својата конфигурација на различно место. OpenVPN сервер управуван од systemd ја чита конфигурацијата при стартување, така што она што е во датотеката при подигање е она што се извршува. Интерфејсот wg-quick ги добива адресите, рутите и DNS од истата датотека, што значи дека интерфејс подигнат рачно од школка и никогаш овозможен како единица нема да се врати. Контејнерот го враќа своето влезно место, но не и промените на огнениот ѕид на домаќинот, освен ако тие не живеат надвор од контејнерот.
Прво основна состојба, инаку резултатот не значи ништо
Запишете ја работната состојба додека работи: адреси на тунелот, рути за клиентската подмрежа, NAT или правила за пренос, сокетот што слуша и sysctl за пренос. ip addr show wg0, ip route, nft list ruleset или iptables-save, ss -lunp и sysctl net.ipv4.ip_forward се доволни на повеќето домаќини.
Запишете како услугата е конфигурирана да стартува, не само дека работи. systemctl is-enabled wg-quick@wg0 и systemctl is-active wg-quick@wg0 одговараат на различни прашања, а при подигање е важна токму овозможената состојба, како што е опишано во systemctl(1). За OpenVPN проверете кој шаблон го користи домаќинот, бидејќи openvpn@server и openvpn-server@server се различни единици со различни стандардни вредности.
Извршете го рестартирањето и прочитајте го првиот неуспех
Рестартирајте намерно, во прозорец што сами сте го избрале, со отворена конзола или вонпојасна патека. Гледајте го редоследот на настаните, а не крајната состојба: домаќинот е достапен, единицата е активирана, интерфејсот е присутен, рутите се инсталирани, правилата на огнениот ѕид се присутни, слушачот е поврзан, клиентот е прифатен. Првиот чекор што не се случува е наодот; сето она што следи е шум.
Демонот може да биде активен додека тунелот е неупотреблив, и тоа е најчестиот лажен пролаз. Стартувањето може да заврши пред мрежата да биде онлајн ако единицата чека само network.target наместо network-online.target. Наведените датотеки како сертификати, клучеви или CRL може да бидат нечитливи во тој момент бидејќи монтирање или патека до тајни уште не е подготвена. Ниту еден од двата проблема не се појавува во systemctl status додека не го прочитате журналот на единицата.
Тестирајте од надвор од домаќинот. Клиент на истиот LAN може да успее преку рута што ниту еден оддалечен клиент никогаш не би ја користел, а SSH сесија до машината не докажува ништо за тунелот. Поврзете се, решете внатрешно име, достигнете го приватниот ресурс, потоа поврзете се уште еднаш за да потврдите дека состојбата на отповикување и клучевите уште важат.
Трите услови што ја одредуваат вашата поправка
Ако тунелот се врати но клиентите не достигнуваат ништо, неуспехот е во рутирањето или постојаноста на NAT. Ако клиентите не можат ниту ракување да завршат, неуспехот е во интерфејсот или во автентикацискиот материјал. Ако услугата никогаш не стартува, неуспехот е во датотеката на единицата или во нејзините зависности. Овие три гранки водат до различни поправки, затоа слепо рестартирање без основна состојба чини повеќе време отколку што заштедува.
Направете ја поправката таму каде што поставката е сопственост. Ставете пренос во sysctl drop-in, ставете NAT правила во множеството правила што се вчитува при подигање, овозможете ја единицата наместо да ја стартувате, и чувајте тајни на патека што постои пред единицата да стартува. Додавањето сон на единицата крие зависност наместо да ја објави.
Запишете го резултатот во runbook
Запишете што се врати само, што моравте да стартувате и колку траеше јазот. Вклучете ги точните наредби што ги користевте за проверка, за следната личност да го повтори тестот наместо да измисли нов. Ако некој чекор бараше рачна наредба, таа наредба припаѓа во конфигурацијата, не во runbook како постојан чекор.
Потоа закажете го следниот тест по следната промена на мрежниот стек на домаќинот, а не за календарски датум шест месеци подоцна. Режимот на неуспех од кој се штитите е привремена наредба што изгледаше постојана, и тие се појавуваат токму кога некој уредува правила на огнениот ѕид или преместува услуга во нова единица.