VPN toimii vain kirjautumisen jälkeen avainrenkaan takia

Komento toimii, kun olet kirjautunut sisään, joten laitat sen käynnistysskriptiin ja lähdet kotiin. Seuraavana aamuna kone on verkossa ja tunneli ei. Myytti on, että toimiva kutsu on toimiva palvelu. Käytännössä ero on yleensä toinen kahdesta asiasta: profiili kuuluu käyttäjäistuntoosi eikä järjestelmään, tai salaisuuden avaa jokin, joka on olemassa vasta kirjautumisesi jälkeen. Molemmat toimivat täydellisesti manuaalisessa testissä ja epäonnistuvat juuri sillä hetkellä, kun kukaan ei katso.

Miksi kirjautuminen saa sen toimimaan

Graafinen kirjautuminen käynnistää istuntoväylän ja salaisuuspalvelun agentin, ja siellä monet työpöytäkeskeiset asiakkaat pitävät profiilin salasanaa tai yksityisen avaimen salasanaa. Kirjautumisen jälkeen käyttäjänäsi ajettava aktivointi voi pyytää salaisuuden siltä agentilta ja onnistua. Samalla aktivoinnilla, jonka käynnistysyksikkö suorittaa, ei ole istuntoa, väylää eikä agenttia, joten haku epäonnistuu tai estyy kehotteessa, jota kukaan ei näe.

Aja sama profiili ennen kirjautumista ja sen jälkeen, niin saat yhdestä kokoonpanosta kaksi eri tulosta. Se on tunnistetietoriippuvuuden, ei rikkoutuneen tunnelin, allekirjoitus, ja se selittää, miksi päätteessä tehty manuaalinen testi todistaa vähemmän kuin näyttää. Tunneli on kunnossa; puuttuu se, mikä avaa sen salaisuuden.

Päätä, mikä omistaja käynnistää tunnelin

Tuettuja malleja on kaksi, ja niiden sekoittaminen on toinen tapa, jolla tämä epäonnistuu. NetworkManager voi aktivoida järjestelmätason yhteyden, mikä sopii, kun kone jo keskittää verkkonsa sinne. Vaihtoehtoisesti oma systemd-yksikkö ajaa VPN:n suoraan ja omistaa rajapinnan itse.

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

Älä aja molempia omistajia yhtä kokoonpanoa vastaan. Jos NetworkManager hallinnoi rajapintaa ja yksikkö nostaa sitä myös, ne taistelevat reiteistä ja DNS:stä, ja syntyvä tila riippuu siitä, kumpi valmistui viimeksi.

Laita salaisuus sinne, missä palvelu voi lukea sen

Taustapalvelu ei voi vastata kehotteeseen. Varmennekohtaiset salasanat, tilien salasanat ja viitatut todennustiedostot tarvitsevat kaikki sellaisen tallennusjärjestelyn, johon yksikkö pääsee ilman ihmistä, joka kuuluu palvelua ajavalle tilille ja jota kaikki muut eivät voi lukea.

Houkkueleva oikotie on tehdä tiedostosta kaikkien luettava, kunnes käyttöoikeusvirhe katoaa. Se vaihtaa käynnistysvirheen pitkäaikaiseen tunnistetietojen paljastumiseen, ja se on sellainen muutos, jonka pariin kukaan ei palaa. Käytä mekanismia, johon käyttöönotto jo luottaa: rajoitettu tunnistetietotiedosto, tiedosto-oikeuksilla suojattu salaamaton avain tai järjestelmätason yhteys omalla salaisuustallennuksellaan.

Testaa tapahtuma, joka todella tapahtuu

Palvelun käynnistäminen käsin kirjautumisen jälkeen ei testaa juuri mitään. Käynnistä uudelleen tai poista graafinen kirjautuminen käytöstä yhden syklin ajaksi ja katso, kuinka yksikkö nousee itsestään. Se on ainoa testi, joka harjoittaa samanaikaisesti tunnistetietojen saatavuutta, verkon valmiutta ja yksiköiden järjestystä. Se on myös testi, joka toistaa käyttäjän raportoiman vian, mitä manuaalinen käynnistys ei koskaan tee.

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

Järjestys on yhtä tärkeä kuin tunnistetiedot. Yksikkö, joka käynnistyy ennen kuin alla oleva yhteys on määritetty, antaa periksi, ja jotkut jakelut eroavat siinä, odottavatko ne yhteyttä. Jos yksikkö ilmoittaa käynnistyksessä virheen mutta onnistuu, kun se käynnistetään käsin kolmekymmentä sekuntia myöhemmin, olet löytänyt järjestysongelman etkä salaisuusongelmaa.

Tarkista reitit ja DNS, ei vain rajapinta

Olemassa oleva rajapinta ei ole toimiva tunneli. Valvomattoman käynnistyksen jälkeen tarkista reitit, selvittimen tila ja yksi kohde osoitteen perusteella ennen nimen tarkistamista. Tarkista sitten sovellus, jota varten tunneli on olemassa.

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'

Jos osoite toimii ja nimi ei, jäljellä oleva ongelma on DNS-käytäntö eikä tunneli. Kirjaa, mikä omistaja käynnistää palvelun ja missä salaisuus asuu, koska seuraava tämän koneen uudelleenkäynnistäjä tarvitsee molemmat tiedot.