Meerdere OpenVPN-remotes: failoverlijst, geen linkbundeling

Twee remote-regels in één profiel lijken een tweede rijstrook; ze zijn een tweede poging. Als het eerste endpoint stopt met antwoorden, gaat de client verder en wordt de sessie niet breder. Noem de lijst vroeg failover, anders draai je aan de verkeerde knop.

Wat een remote-lijst je oplevert

Behandel het profiel als een geordende set pogingen, niet als een pool van capaciteit. Elke vermelding krijgt zijn beurt om de tunnel op te zetten, en de sessie leeft op degene die antwoordde. Een langere lijst verbetert je kansen om te verbinden, niet de grootte van de pijp.

Echte aggregatie is een andere machine. Eén stroom over meerdere paden verdelen vereist software aan beide uiteinden om het verkeer te splitsen en in volgorde weer samen te voegen.

Een leverancier die snellere tunnels uit meer servers belooft, verkoopt dat tweede model, niet een langere lijst. Als de client endpoints alleen om de beurt probeert, veranderen vijf vermeldingen je kansen en niets anders. Let op een storing: de sessie valt weg en komt elders terug, wat het log als een nieuw endpoint toont, nooit als een bredere pijp.

Blokken die instellingen bij één endpoint houden

Een gewone remote-regel draagt een adres, en soms een poort en protocol. Als een endpoint een proxy nodig heeft, of een transport dat de rest van het bestand niet gebruikt, zet die instellingen dan in een verbindingsblok dat ze bij het endpoint houdt. Inline-blokken werken ook in één .ovpn-bestand, en zo worden de meeste profielen geleverd.

Alles buiten een blok geldt als standaard voor vermeldingen die het niet overschrijven. Daarom gedragen één gebouwd blok en vier gewone remotes zich op manieren die de adressenlijst niet kan verklaren.

Een blok verwijderen dat je niet herkent is niet cosmetisch. Het endpoint waar het bij hoorde valt terug op de standaardwaarden van het bestand, die een ander transport kunnen zijn dan waarop het luistert. Verwijder de verkeerde wikkel en één vermelding faalt terwijl de rest werkt, dus het lijkt een slechte server in plaats van een kapot profiel. Lees elke remote met zijn transport, poort en proxy voordat je bewerkt.

Volgorde van nieuwe pogingen en de prijs van remote-random

De volgorde is belangrijk omdat elke dode vermelding tijd kost voordat de volgende poging komt. Zet het endpoint dat je wilt vooraan en behandel de rest als gerangschikte terugvalopties.

remote-random husselt de startvolgorde, wat de belasting over gelijkwaardige servers spreidt en tegenwerkt wanneer één endpoint duidelijk primair is. Hoe dan ook, log het endpoint dat de client koos; de profielnaam zegt niets als een verbinding traag aanvoelt. De linkregel uit een uitgebreid log greppen laat zien waar de sessie landde.

Operators mengen breekt de vertrouwensverklaring

Een profiel is ook een bewering over identiteit: deze adressen zijn de dienst die je wilde bereiken, en het vastgezette certificaat hoort erbij. Gratis openbare servers in dat bestand gooien breekt de bewering: hun certificaten en het jouwe beschrijven verschillende diensten. Het gebruikelijke resultaat is een identiteitsfout, of inloggegevens die worden aangeboden aan een host buiten het netwerk van je provider. Houd alternatieven binnen de set die je operator distribueert, met bijpassende inloggegevens en vertrouwensmateriaal.

Als je endpoints van twee providers nodig hebt, is dat routing, geen profielbewerking. Los het boven de tunnel op, waar je kunt zeggen welk verkeer welk pad neemt.

Test elke vermelding in plaats van aan te nemen

Na een goedgekeurde profielupdate verbind je bewust met elk vereist endpoint en bevestigt welke transport omhoogkwam. Een uitgebreide run maakt dat zichtbaar. Start openvpn --config office.ovpn --verb 4 en lees de linkregel voor het adres dat je verwachtte. Controleer daarna de bronnen achter de tunnel; een vermelding kan de handshake voltooien en je alsnog nergens heen routeren.

Failover heeft zijn eigen test nodig in plaats van hoop. Blokkeer het eerste endpoint in een lab, start de client en meet hoe lang het duurt om verder te gaan. Een lange lijst achter een trage eerste vermelding is slechter dan een korte die goed begint.

Controleer de lijst opnieuw telkens wanneer de operator die wijzigt. Een geïmporteerde set is alleen nuttig zolang de vermeldingen bestaan en het transport spreken dat je blokken beschrijven. De OpenVPN 2.6-handleiding behandelt hier de richtlijnen remote, connection en random-order, en dat is de versie die je controleert als de syntaxis twijfelachtig is.