Wie bezit het adres, de route, DNS en de firewall op een Linux-VPN?

Twee scripts die vechten om dezelfde route is de gebruikelijke vorm van een Linux-VPN-probleem dat als routeringsfout wordt geregistreerd. Eén component maakt het tunnelapparaat, een ander voegt een standaardroute toe, een derde herschrijft de resolverconfiguratie en een vierde herlaadt firewallregels. Elk van hen kan het werk van een ander ongedaan maken, en de winnaar is simpelweg degene die als laatste draaide. De vraag die het beantwoorden waard is, is niet welk pakket je moet installeren, maar welke component bevoegd is voor elk stukje toestand.

Schrijf die kaart één keer op, en de meeste herverbindingsfouten houden op mysterieus te zijn. Vier objecten doen ertoe: het apparaat en zijn adressen, de routes en beleidsregels, de DNS-configuratie en de firewall.

Het apparaat en zijn adressen

Een tunnelapparaat wordt gemaakt door een beheerder die het profiel kent, of door een daemon die iemand met de hand heeft gestart. Beide opstellingen werken op zichzelf; ze mengen niet. Als NetworkManager het profiel bezit, laat het dan ook het apparaat bezitten, en start geen onbeheerd OpenVPN-proces tegen dezelfde tunnelnaam.

Noteer wie het apparaat verwijdert als de sessie eindigt. Een apparaat dat zijn sessie overleeft, is de meest voorkomende bron van verouderde adressen en van de verwarring die daarop volgt.

Routes en beleidsregels

Juist op de routes richten eigendomsconflicten zichtbare schade aan. Een verbindingsbeheerder installeert een standaardroute voor de tunnel plus een specifiekere route voor het externe netwerk; een handgeschreven script voegt daarna zijn eigen standaard toe met een andere metriek en wint of verliest stil, afhankelijk van de timing. Bepaal welke vermeldingen aan de verbinding gebonden zijn, welke permanent beleid zijn en welke component ze na een herverbinding vernieuwt. Houd daarna de andere componenten buiten die tabel.

Beleidsregels verdienen dezelfde helderheid, want een regel die naar een tabel wijst die niemand vult, produceert een zwart gat dat er precies uitziet als een dode tunnel. Als een regel bestaat om verkeer ergens heen te dwingen, moet de tabel die hij selecteert door dezelfde eigenaar worden onderhouden.

DNS is altijd een aparte eigenaar

Een resolver-daemon draait als zijn eigen proces onder zijn eigen identiteit, dus erft hij niet per ongeluk de routeringsbeslissingen van de tunnel. Wanneer de VPN DNS-servers pusht, moet iets dat vertalen naar een configuratie per verbinding die de resolver respecteert, en iets moet die daarna weer weghalen.

De mythe hier is dat het schrijven van een nameserver in het profiel verandert waar zoekopdrachten heen gaan. Het verandert wat de resolver wordt verteld, niet welke socket de resolver stroomopwaarts gebruikt. Test met een query plus een routeopzoeking in plaats van het bestand te vertrouwen.

De firewalltoestand, en wie die herstelt

Firewallregels zijn het object dat het vaakst wordt overschreven op een VPN-host. Een beheerder kan per verbinding NAT- of forwardingregels toevoegen, terwijl een firewalldienst bij het opstarten een opgeslagen regelset herlaadt en die wist. Kies één autoriteit voor beleid en maak de andere daarvan een consument, of accepteer dat een herstart het gedrag stil verandert. Aan de verbinding gebonden uitzonderingen horen in een bestand dat dezelfde eigenaar laadt, niet in een iptables-commando dat tijdens het oplossen van problemen wordt getypt.

Als regels een herverbinding moeten overleven, zeg dat dan expliciet. Als dat niet hoeft, zeg dat ook, want de volgende engineer gaat uit van het meest gemakkelijke antwoord.

Levenscyclus: opstart, herverbinding, afbraak

Geef elk van die drie momenten een eigenaar. Bepaal bij het opstarten wat de randvoorwaarden voorbereidt en in welke volgorde. Onthoud bij een zachte herstart dat het apparaat kan overleven terwijl de sessietoestand dat niet doet, dus moet een validator draaien in plaats van een maker. Verwijder bij afbraak alleen wat deze verbinding heeft gemaakt, want elke route resetten of de hele firewall leegmaken is niet hetzelfde als één tunnel uit dienst nemen.

Voor observatie toont ip monitor link address route kernelwijzigingen terwijl ze gebeuren, maar het rapporteert gebeurtenissen in plaats van bedoelingen: een verwijderde route zegt niets over welk proces die verwijderde. Koppel het aan de eigendomskaart, en een verwarrende afsluiting wordt een korte lijst kandidaten.

Uitzonderingen hebben ook een prijs. Een hele apparaatklasse als onbeheerd markeren om een conflict te ontlopen, geeft die toestand aan niemand, wat een beslissing is en geen correctie.