Twee VPN-hops op één Pi: welke route draagt welke peer

Twee tunneladressen op een klein bordje lijken een fout, en de reflex is er één te verwijderen. Die reflex breekt wat hij had moeten opruimen. Een host met twee hops houdt één adres per aansluiting, en elk adres wordt door een andere route gekozen. De vraag die het waard is om te stellen is welke route welke drager voor welke bestemming kiest, niet hoeveel adressen er bestaan.

Drie bestemmingen die verschillende dragers nodig hebben

Een keten van twee hops is drie gestapelde bestemmingsklassen, en elk wordt door een andere aansluiting gedragen. De buitenste peer moet via de fysieke link worden bereikt. De binnenste peer moet via de buitenste tunnel worden bereikt. De bestemming van de afgedekte toepassing moet via de binnenste tunnel worden bereikt, waarvan het eigen transport door de buitenste wordt gedragen.

Vul de rijen in met de echte adressen van de lezer voordat je een route aanraakt, want de tabel is alleen nuttig als hij concreet is. Een werkende keten voldoet tegelijk aan alle vier rijen, en een half werkende keten voldoet meestal aan één ervan met de verkeerde drager. Juist het lezen van de verkeerde rij als de fout maakt van een routeringsprobleem een hele middag aanpassingen.

Adressen hebben rollen, geen aantal

Linux staat meerdere adressen op één interface en meerdere tunnels op één host toe, dus een aantal zegt niets over correctheid. Wat telt is welk adres bij welke aansluiting hoort, en of de route voor een bepaalde peer de aansluiting kiest die je bedoelde. Drie weergaven beantwoorden dat vanuit drie richtingen, en ze zijn elke keer de moeite waard in dezelfde volgorde te lezen.

De adressenlijst laat zien wat bestaat en welke aansluiting het bezit. De routetabel beantwoordt de dragervraag voor gewoon bestemmingsverkeer. De beleidsweergave beantwoordt die opnieuw voor verkeer dat op bron of markering is geselecteerd, wat de normale opstelling is wanneer twee clients één host delen.

ip -4 addr show
ip -4 route show table all
ip rule show

Een adres verwijderen omdat de lijst lang lijkt, kan een deel van het pad wegnemen, en een route verwijderen omdat die overbodig lijkt doet hetzelfde stiller. Geen van beide geeft een fout; de peer stopt gewoon met antwoorden op het pad dat je bedoelde terwijl hij via een ander bereikbaar blijft. Een toepassing die het uitgangsadres van de binnenste peer meldt, bewijst niet dat het verkeer de buitenste tunnel is overgestoken, omdat directe toegang dezelfde waarneming oplevert. Juist die kloof tussen een waarneming en een bewijs is de reden dat de drager op de routeringslaag wordt gecontroleerd.

Activeringsvolgorde verslaat een vaste wachttijd

Als de binnenste client afhankelijk is van een adres of een route die de buitenste client levert, moet de activering op die bron wachten in plaats van op een vertraging. Een vaste wachttijd werkt tot de dag dat de buitenste tunnel traag is, en dan faalt hij af en toe op een manier die niemand kan reproduceren. Volgorde op basis van afhankelijkheden haalt de gok weg en kost niets meer dan het één keer beschrijven van de afhankelijkheid. Ook interfacenamen zijn geen volgordemechanisme.

De kernel geeft namen zoals tun0 en tun1 in aanmaakvolgorde, en die volgorde kan veranderen tussen herstarts of herverbindingen. Bind de configuratie aan een identiteit die de tooling levert, of aan een naam die je bewust toekent. Een naam die je kiest is een contract; een naam die de kernel kiest is een toeval.

Houd het transport van elke client buiten de toepassingsroute van de andere, en wees precies over wat de routeringsopties van OpenVPN 2.6 werkelijk beloven. Het gedocumenteerde standaard-doorverwijzingsmechanisme houdt een client in staat zijn eigen externe peer te bereiken via de gateway die al bestond, wat één specifieke recursielus doorbreekt. Het maakt één client niet tot de drager van een andere, dus de rest van de keten blijft jouw ontwerp. Waar de keten een beleid nodig heeft in plaats van een route, schrijf een expliciete bron- of markeringsregel en test die met het verkeer dat erbij moet passen.

Wat er gebeurt als de buitenste hop sterft

Voordat de keten als compleet telt, beslis je wat er gebeurt als de buitenste hop verdwijnt. Het transport van de binnenste client sterft mee, en de volgende stap is een beleidsvraag in plaats van een technische: falen, opnieuw proberen of direct opnieuw verbinden via de fysiske link. Dat derde resultaat is het resultaat om over na te denken. Het verandert stilletjes een ontwerp met twee hops in een ontwerp met één hop op het moment dat de gebruiker gelooft dat de dekking nog intact is.

Als twee hops verplicht zijn, mag de binnenste client geen direct pad kunnen opzetten wanneer de buitenste weg is, en de manier om dat te weten is de buitenste hop breken en kijken wat de binnenste doet. Een goedgekeurde terugval is een legitiem antwoord, maar hij moet worden opgeschreven, getest en gecommuniceerd. Een terugval die niemand heeft gedocumenteerd is tijdens een incidentreview niet te onderscheiden van een lek.

DNS en de andere adresfamilie horen bij dezelfde beslissing. Een lokaal gegenereerde opzoeking volgt het beleid van de host zelf en niet dat van een doorgestuurde client, dus de resolver die voor doorgestuurd verkeer werkt is misschien niet degene die de host zelf gebruikt.

Accepteer elke laag in de volgorde waarin je hem hebt gebouwd

Test in de volgorde waarin de keten is gebouwd: eerst de buitenste tunnel alleen, dan het transport van de binnenste client door de buitenste tunnel, dan de toepassing door de binnenste tunnel. Elke acceptatie moet een nieuwe verbinding zijn in plaats van een pagina die al open was. Breek en herstel daarna elke laag afzonderlijk en kijk wat de volgende doet.

Het terugvalresultaat is hier de meest waardevolle waarneming, en degene die een openbare IP-pagina nooit laat zien. Bewaar de paden van de peers, de adressen die ze gebruiken en dat resultaat naast de configuratie, want het gelukkige pad is niet het deel dat later ter discussie staat.