Vad som faktiskt händer när du startar en VPN i Linux
Att starta en VPN i Linux skapar ett gränssnitt, installerar rutter och ändrar resolvern. Att veta vilken tjänst som äger varje steg förklarar de flesta installationsfel.
Tryck på anslut och tre saker ändras på en Linux-maskin: ett gränssnitt dyker upp, rutter installeras och resolvern börjar svara annorlunda. De flesta installationsfel kommer av att en av de tre sker utan de andra, eller av att två program är oense om vem som äger dem. Att förstå ordningen förklarar felet snabbare än att läsa en klients loggutdata.
Ett gränssnitt dyker upp innan något fungerar
En tunnelklient öppnar ett virtuellt gränssnitt och lämnar paket till det. En TUN-enhet bär IP-paket, vilket är vad en routad VPN behöver; en TAP-enhet bär Ethernet-ramar, vilket är vad en bryggad design behöver. Kernelmodulen tillhandahåller enheten, och klienten äger den så länge sessionen varar.
Att gränssnittet kommer upp är inte samma sak som att tunneln fungerar. Det kan finnas med en adress medan motparten är onåbar, och därför är gränssnittslistan den första kontrollen och inte den sista. En enhet som rapporterar sig uppe beskriver kernalens syn på en virtuell länk, inte motpartens vilja att svara.
Låt det medföljande gränssnittsläget vara. Att ändra en TUN-profil till TAP gör inte en routad server bryggad, och det ger oftast en anslutning som etableras och inte vidarebefordrar något.
Rutter installeras av den som äger tunneln
Rutter är den andra ändringen, och deras ägarskap betyder mer än innehållet. En NetworkManager-profil, en systemd-enhet och en handstartad klient kan alla installera rutter, och när två av dem gör det samtidigt uppstår en tabell som ingen senare kan förklara.
ip -br addr show ip route show ip -6 route show
En fulltunnelprofil ersätter standardrutten; en deltunnelprofil lägger till mer specifika rutter och lämnar standardrutten ifred. Båda är normala, och det andra är anledningen till att radering av en standardrutt är ett dåligt första test på en maskin du administrerar på distans. Att ta bort den är också det snabbaste sättet att förlora sessionen du använder för att åtgärda problemet.
Läs tabellen i stället för att anta. En mer specifik rutt eller en policyregel kan skicka trafik in i tunneln medan standardrutten fortfarande pekar på det fysiska gränssnittet, vilket ser motsägelsefullt ut tills du läser hela tabellen. Den kombinationen är normal för deltunnel och förvirrande för alla som förväntar sig att en rad beskriver designen. Leta efter rutten som matchar din faktiska destination, inte den som matchar diagrammet.
Resolvern byter händer
DNS är den tredje ändringen och den som mest sannolikt hanteras någonstans där du inte har tittat. På en stationär dator kan NetworkManager skicka resolverinställningar per anslutning. På ett system med systemd-resolved tillämpas inställningarna per länk och /etc/resolv.conf kan vara en stub eller en symbolisk länk i stället för en fil du borde redigera.
resolvectl status readlink -f /etc/resolv.conf cat /etc/resolv.conf
Om en manuell ändring av resolverfilen försvinner efter en återanslutning är det signalen att hitta komponenten som underhåller den och ändra profilen i stället. Att redigera den genererade filen är en ändring som en återanslutning kommer att radera.
Privata namn behöver vanligtvis den interna resolvern och de sökdomäner som operatören tillhandahöll. Att ersätta med en offentlig resolver kan förstöra just den resurs som VPN:en finns för att nå, och symptomet ser ut som ett routingfel och inte ett DNS-fel. Testa namnet och adressen var för sig, för att den ena fungerar och den andra misslyckas säger exakt var du ska titta. Den enda jämförelsen sparar en timmes ruttfelsökning.
En hanterare per anslutning
Profilformatet avgör vilket program som kan använda det. En OpenVPN-profil kräver OpenVPN eller ett kompatibelt plugin, och en WireGuard-konfiguration har sitt eget format med motpartens nycklar och tillåtna prefix. En importdialog översätter inte det ena till det andra, vad filändelsen än antyder.
Välj en hanterare och låt den äga anslutningen. Att resa samma tunnel genom två verktyg gör rutttabellen och återanslutningsbeteendet tvetydigt, och den andra som startar vinner oftast på sätt som är svåra att återskapa.
Installera paketen som din distribution stöder och skaffa profilen från operatören. Behandla den som en inloggningsuppgift, eftersom den vanligtvis innehåller en privat nyckel eller motsvarande material, och förvara den där resten av dina hemligheter bor. En profil som lämnats i en nedladdningsmapp är en nyckel som lämnats på ett skrivbord.
Vad du ska kontrollera när den är uppe men inte fungerar
Med gränssnittet uppe och klienten som rapporterar framgång, arbeta utåt: väljer rutttabellen tunneln för destinationen, svarar resolvern för det privata namnet, och har den andra sidan en returväg. Var och en har sitt eget kommando och sin egen ägare.
nmcli connection show --active nmcli device status wg show
nmcli-referensen dokumenterar status- och anslutningskommandona om du behöver hela uppsättningen. Det som spelar roll här är skillnaden mellan att en profil är aktiv och att en enhet bär trafik, eftersom de två kan vara oense.
Anslut igen en gång genom samma hanterare innan du kallar installationen klar, och kontrollera att DNS fortfarande fungerar efter en frånkoppling. En konfiguration som bara fungerar fram till den första nätverksändringen är inte klar, den fungerar bara i stunden.