Openbaar prefix via OpenVPN: de retourroute repareren

Kijk hoe de tunnel opkomt en de client de andere kant pingt, en dan antwoordt een openbaar adres dat achter de VPN hoort ergens anders vandaan, of helemaal niet. Dat symptoom heeft meestal niets met het cijfer of de certificaten te maken. Een door de provider gerouteerd prefix wordt als IP-route geleverd, en het over OpenVPN dragen betekent die route op twee niveaus nabootsen en het bronadres op de retourroute behouden. De WAN overbruggen is niet nodig, en het adres aan een interface toevoegen maakt de upstream-route niet.

Het prefix moet eerst naar jou gerouteerd worden

Vraag de provider hoe het blok wordt geleverd. Een prefix dat naar het hoofdadres van je server wordt gerouteerd is iets anders dan adressen die de provider direct op een WAN-segment verwacht te bereiken. Alleen het eerste model werkt met het ontwerp hier.

Als de provider 198.51.100.64/28 naar je ingangsserver routeert, komen pakketten voor dat bereik bij de server aan en stoppen daar, tenzij je ze doorstuurt. Als de provider het bereik in plaats daarvan naar je uplink overbrugt, moet de server er ARP voor beantwoorden, wat een ander probleem is.

Test het leveringsmodel voordat je OpenVPN aanraakt: ping van buitenaf een adres in het blok en kijk welke interface het ontvangt. Als er niets aankomt, helpt geen enkele tunnelconfiguratie. Als het adres direct op de WAN antwoordt, overbrugt de provider in plaats van te routeren, en het ontwerp hieronder is niet van toepassing.

Twee routeringsniveaus: kernelroute en iroute

OpenVPN heeft het prefix op twee plaatsen nodig. De kernel moet weten dat het prefix bij het tunnelapparaat hoort, zodat doorgestuurde pakketten OpenVPN binnenkomen in plaats van de standaardroute. OpenVPN moet ook weten welke geauthenticeerde client het prefix bezit, en dat is de iroute-regel in de clientspecifieke map.

De route aan de serverkant ziet er zo uit, waarbij prefix en masker bij de toewijzing moeten passen:

ip route add 198.51.100.64/28 dev tun0

De clientspecifieke configuratie wijst eigendom toe. Zet die in het CCD-bestand dat vernoemd is naar de common name van het clientcertificaat, en bevestig dat die map de map is die de server echt leest:

iroute 198.51.100.64 255.255.255.240

De OpenVPN-documentatie over gerouteerde netwerken beschrijft beide niveaus en waarom ze gescheiden zijn. Een kernelroute zonder iroute stuurt pakketten zonder eigenaar de tunnel in, en OpenVPN gooit ze weg. Een iroute zonder de kernelroute laat pakketten op het standaardpad van de server. Beide fouten zien er vanaf de clientkant uit als een kapotte tunnel.

Waar het serviceadres woont

Het gedelegeerde prefix is niet hetzelfde als de eigen adressen van de tunnel. Nummer de link gerust uit de privéruimte, en plaats het openbare serviceadres waar de dienst echt draait.

Op een Linux-client die de dienst lokaal beëindigt, is één hostadres genoeg:

ip address add 198.51.100.70/32 dev lo

Als het prefix verder naar een VM-host of een ander LAN wordt gerouteerd, configureer dan in plaats daarvan dat downstreampad en de retourroute ervan. Het is niet nodig elk adres in het blok aan de VPN-client toe te wijzen, en het veroorzaakt later conflicten.

Behoud de openbare bron op de retourroute

Een antwoord uit het gedelegeerde prefix moet door de tunnel naar buiten en de route van de provider bereiken. Als de externe host het via zijn eigen ISP verstuurt, lijkt het bronadres vervalst, en de provider of de bestemming gooit het weg. De oplossing is een op de bron gebaseerde regel of een aparte routeringstabel, geen bredere NAT. Zonder die werkt de dienst vanaf de tunnelpartner en faalt hij vanaf elke andere plek.

Op de ingangsserver is een brede masquerade-regel de gebruikelijke schuldige. Die herschrijft de openbare bron naar het hoofdadres van de server, en de client ziet de echte nooit:

iptables -t nat -S POSTROUTING

Beperk NAT tot de private VPN-clients die het nodig hebben en laat het gedelegeerde prefix onvertaald. Bevestig dan dat de server het prefix überhaupt doorstuurt, want een doorstuurketen met standaard weigeren gooit het stil weg.

Verifieer beide richtingen voordat je erop vertrouwt

Verificatie is vier observaties, niet één. Bevestig dat de route van de provider aankomt, dat de kernel het prefix de tunnel in stuurt, dat OpenVPN het aan de juiste client toewijst, en dat het antwoord terugkomt met de openbare bron intact. Elke observatie heeft zijn eigen commando, dus een fout wijst op een laag in plaats van het hele ontwerp. Voer ze in die volgorde uit na elke configuratiewijziging.

Vraag de kernel welk pad een gedelegeerd adres neemt, en kijk naar de tunnel terwijl een verzoek loopt:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Reverse-path filtering kan een correcte route ongedaan maken. Controleer de effectieve instelling op de tunnel en op de uplink, en onthoud dat een strikte modus verkeer weigert waarvan de bron niet past bij de interface waarop het aankwam:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

Test tot slot het foutgeval. Stop de tunnel en bevestig dat het openbare prefix niet via de gewone uplink lekt. Het herstellen van de VPN zou de dienst terug moeten brengen zonder te verbreden welke poorten de host blootstelt.