Volledige tunnel OpenVPN: een internetuitgang aan de serverkant

Een client authenticeert, ontvangt een adres uit de pool en bereikt diensten op de VPN-host, maar elke publieke bestemming loopt in een time-out. Zo ziet een tunnel zonder uitgang eruit, en zo blijft het tot vier afzonderlijke dingen waar zijn. De client moet een standaardroute accepteren, de server moet doorsturen, de firewall moet de doorgang toestaan, en antwoorden hebben een pad terug naar de pool nodig. Alle vier de fouten delen één symptoom, dus wijzig per poging één item en noteer het resultaat.

Duw de standaardroute en controleer wat de client heeft geïnstalleerd

De regel aan de serverkant is kort, en hij beïnvloedt alleen clients die gepushte opties accepteren. De def1-vorm installeert twee halve standaardroutes in plaats van de bestaande standaardroute te verwijderen, waardoor de huidige verbinding in leven blijft en toch elke bestemming wordt vastgelegd.

push "redirect-gateway def1"

Lees na het opnieuw verbinden de routingtabel van de client in plaats van het profiel te vertrouwen. Op Linux verschijnen de twee /1-vermeldingen naast de oorspronkelijke standaardroute, en Windows toont hetzelfde paar als 0.0.0.0/1 en 128.0.0.0/1. Een client die gepushte opties negeert, of die is geconfigureerd ze te weigeren, houdt zijn oude standaardroute en stuurt nooit internetverkeer de tunnel in. Beslis die vraag voordat je iets op de server wijzigt, want geen enkele regel aan de serverkant kan dat compenseren.

Doorsturen is een serverinstelling, geen VPN-instelling

Lees de doorstuurvlag voordat je de routing aanraakt. Een nul daar betekent dat de kernel het pakket van de client ontvangt en weigert het door te geven, wat er precies uitziet als een firewallblokkade van de andere kant. Stel de waarde in via de configuratiemap van het systeem zodat die een herstart overleeft.

sysctl net.ipv4.ip_forward
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-vpn-forward.conf
sudo sysctl --system

Controleer vervolgens of de host zelf een werkende route naar de internetuitgang heeft. Een verzoek vanuit de shell van de server bewijst dat het bovenliggende pad bruikbaar is en zegt helemaal niets over het doorsturen van een pakket van een client, dus behandel ze als twee aparte tests. Als de server de bestemming niet bereikt, helpt geen enkele hoeveelheid doorstuurconfiguratie.

Sta precies de doorgang toe die je bedoelt, en niets anders

Doorgestuurde pakketten passeren het forward-pad; verkeer dat aan de VPN-host zelf is geadresseerd, passeert input. Dat zijn verschillende beslissingen, en het input-pad openen staat geen doorgang door de machine toe. Ze door elkaar halen is de meest voorkomende reden dat een firewall alles lijkt toe te staan terwijl clients nog steeds in een time-out lopen.

Een minimaal beleid accepteert nieuwe verbindingen van de pool naar de uitgangsinterface en accepteert antwoorden die bij gevestigde stromen horen. Zet het in de regelset-eigenaar die jouw distributie gebruikt, in plaats van bij elke boot een dubbele regel toe te voegen; dubbele regels stapelen zich op en de tellers betekenen niets meer.

sudo iptables -A FORWARD -i tun0 -o eth0 -s 10.90.0.0/24 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Elke keten op accept zetten laat de test slagen en haalt de reden weg waarom de firewall bestaat. Houd de scope bij de pool en de uitgangsinterface, en laat ongerelateerd doorsturen met rust.

Geef de antwoorden een plek om naartoe te gaan

Pooladressen zijn privé, dus een publieke server kan er niet rechtstreeks een antwoord aan afleveren. Ofwel vertaalt de VPN-host het bronadres op weg naar buiten, ofwel houdt een apparaat stroomopwaarts een route terug naar de pool.

sudo iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o eth0 -j MASQUERADE

Voeg precies één vertaallaag toe. Een tweede NAT verder stroomopwaarts verbergt de eerste en maakt beide logboeken bijna nutteloos wanneer er later iets stukgaat. Als een router stroomopwaarts de pool al terugrouteert, is vertaling op de host overbodig, en het retourpad hangt dan af van de configuratie van die router in plaats van de jouwe.

Cloud-instanties voegen nog een poort toe, omdat sommige platforms pakketten laten vallen waarvan het bronadres niet dat van de instantie is, tenzij die controle wordt versoepeld. Die instelling staat buiten de gast en is makkelijk te vergeten wanneer een lokale testmachine werkt.

Bewijs het vanaf de client, niet vanuit de shell van de server

Begin met een numeriek IPv4-verzoek, dan een naamzoekopdracht, dan de toepassing. Een ping bewijst doorsturen en vertaling;hij bewijst niets over naamresolutie, omdat DNS-opties pas werken wanneer de clientintegratie ze installeert.

curl -4 -m 5 http://198.51.100.10/
dig +short example.com

Noteer de wijzigingen en de ongedaanmakingsstap terwijl je bezig bent, zodat het uitgangsbeleid met één actie kan worden teruggedraaid wanneer een test mislukt. Dit recept dekt alleen IPv4; inventariseer IPv6 apart voordat je beweert dat de uitrol al het verkeer draagt.