Förskapad tun i OpenVPN: jämförelse av de två ägarmodellerna

Någon skapade tun1 i förväg, profilen säger dev tun1, och anslutningen kopplas fortfarande inte. Att namnet finns på värden säger nästan ingenting, eftersom kopplingen beror på namnutrymmet, enhetstypen, vem som äger länken och vad daemonen får göra. Återanvändning av en enhet tvingar också fram ett beslut som standardkonfigurationen döljer: vilken komponent som skriver adresserna och rutterna. Felmoderna för de två uppläggen skiljer sig mycket mer än konfigurationsraderna, så bestäm innan du redigerar en profil.

Ett namn är inte en koppling

dev tun1 begär OpenVPN om det namngivna gränssnittet, och traditionella byggen i användarutrymmet försöker öppna det. Om namnet inte följer det vanliga tun- eller tapmönstret behöver profilen också en matchande dev-type, eftersom typen aldrig härleds från en sträng. En TAP-enhet är inte en TUN-enhet med en annan etikett: att koppla den felaktiga misslyckas antingen direkt eller skapar en länk som bär ramar som ingen förväntar sig. Kontrollera typen före allt annat, eftersom varje senare kontroll förutsätter att båda sidor är överens om den. Därifrån, bekräfta att processen faktiskt kan öppna enheten, inte bara se den.

dev tun1
dev-type tun

Nätverksgränssnittet och /dev/net/tun är olika objekt: det ena är en länk inuti ett namnutrymme, det andra är teckenenheten som ett program i användarutrymmet använder för att koppla sig. Linux TUN/TAP-dokumentationen beskriver den kopplingsvägen och ägarreglerna för beständiga enheter. Ett root-skal som kan köra ip link bevisar bara att skalet har privilegier, inte att daemonen har dem. Ägarskapet av enhetsnoden, tjänstens förmågeuppsättning och användaren den kör som måste alla stämma innan öppningen lyckas.

En enhet som finns och inte kan öppnas är ett ägarproblem, inte ett routingproblem. Behandla det som det när du felsöker, annars går eftermiddagen åt att läsa routingtabeller som aldrig var problemet.

Vem konfigurerar länken: två ägarmodeller

I den första modellen konfigurerar OpenVPN adresser och rutter som en del av att resa anslutningen. Det är standardbeteendet och det enklaste att resonera kring, eftersom en enda komponent skapar tillståndet och tar bort det igen. I den andra modellen äger en extern hanterare gränssnittet, och ifconfig-noexec hindrar OpenVPN från att köra sina adresskonfigurationskommandon och lämnar parametrarna till skript. Hanteraren måste då själv tillämpa rätt lokal konfiguration och peer-konfiguration, vilket är mer arbete än namnet på alternativet antyder. Att välja mellan de två är en fråga om vem som får ändra länken medan den är uppe.

ifconfig-noexec täcker bara adresser: routingtabellen lämnas orörd, och rutkonfigurationen tillhör route-noexec. Behandla de två direktiven som separata kontroller med separata ägare, eftersom att sätta den ena och anta den andra är en vanlig källa till halvkonfigurerade länkar. Välj exakt en ägare per lager, adresser på ett ställe och rutter på ett ställe. En nätverkshanterare och en VPN-hjälpare som båda skriver adresser är hur en frånkoppling raderar tillstånd som den andra sidan fortfarande är beroende av.

Inspektera enheten från namnutrymmet som betyder något

Inspektera enheten från namnutrymmet där VPN-processen kör, inte från det där ditt skal råkar vara. De två kommandona nedan svarar på olika frågor, och skillnaden syns när en värd ser ett gränssnitt som en container inte ser. Kör dem i angiven ordning, eftersom det andra bara är meningsfullt när du vet om länken finns överhuvudtaget.

ip -details link show dev tun1
ip tuntap show

Det första kommandot skriver ut länken som kärnan ser den, inklusive flaggor och gränssnittstyp, och så bekräftar du att detta är enheten du menade. Det andra listar beständiga tun/tap-poster, som finns utan att någon process håller dem. Ett gränssnitt som väntar på sin avsedda ägare är en annan situation än en levande tunnel kopplad till en annan VPN, och bara det andra förklarar varför din egen koppling misslyckas. Hitta processen som håller enheten innan du ändrar något, eftersom en beständig post och ett upptaget gränssnitt har olika lösningar.

Stöd för flera köer är ett specifikt drivrutinsarrangemang med egna krav, inte ett tillstånd för orelaterade processer att dela ett gränssnitt. En levande session från en annan ägare är ett samordningsproblem, och ingen profiländring löser det.

Två slags beständighet

Kärnans beständighet och persist-tun beskriver livslängder som är lätta att blanda ihop och dyra att förväxla. En beständig enhet finns oberoende av varje process, så den överlever ett stopp och kan återanvändas av nästa start. persist-tun behåller resurser genom stödda mjuka omstarter inom en enda OpenVPN-process, en mycket kortare horisont. Ingen av dem lovar att ett stopp av tjänsten lämnar rutter och adresser på plats, och ett gränssnitt som förblir synligt är inte bevis på en fungerande krypterad session.

Bekräfta också backend, eftersom ett förskapat gränssnitt inte säger något om vilken implementering som öppnar det. Community-byggen med den direkta datavägen kommer att försöka använda den, om inte designen säger annat. Där versionen stöder brytaren väljer disable-dco i stället användarutrymmesvägen; äldre motorer och andra klienter har ingen sådan direktiv, så håll versionsvillkoret bredvid alternativet i stället för att anta att det gäller.

Vad som går sönder när bara uppstarten testas

Ett ägaravtal kan klara det första testet och misslyckas med det sista, vilket gör uppstarten till en dålig kontroll på egen hand. Titta i stället på två övergångar: en mjuk omstart, och ett fullständigt stopp följt av en start.

systemctl status openvpn-client@lab
ip -details link show dev tun1

Uppstarten är det enkla fallet: enheten kommer upp, länken visas och statusutdata namnger profilen som laddades. Kopplingen är ögonblicket då daemonen öppnar enheten, så kör länkkontrollen efter att enheten rapporterar att den är aktiv, inte före. Om länken finns medan statusen fortfarande aktiveras, tittar du på en beständig enhet som ingen ännu har kopplat sig till, inte en fungerande tunnel. Släpp igenom verklig trafik via länken innan du går vidare, eftersom ett kopplat gränssnitt utan användbar rutt fortfarande är ett fel.

kill -SIGHUP $(pidof openvpn)
journalctl -u openvpn-client@lab -n 40
systemctl stop openvpn-client@lab
ip -details link show dev tun1

En mjuk omstart bör lämna sessionen användbar och resurserna intakta, och det är det arbete persist-tun utför. Ett fullständigt stopp är platsen där en extern hanterare avslöjar sig: om länken eller dess adresser överlever stoppet äger någon annan dem, och det är antingen tillståndet du dokumenterade eller felet du just hittade. Anteckna båda observationerna bredvid profilen, så att nästa ändring börjar från bevis och inte från ett diagram.