OpenVPN med full tunnel: lägg till en internetutgång på serversidan

En klient autentiserar sig, får en adress från poolen och når tjänster på VPN-värden, men varje offentlig destination tar slut i en timeout. Så ser en tunnel utan utgång ut, och så förblir det tills fyra separata saker är sanna. Klienten måste acceptera en standardrutt, servern måste vidarebefordra, brandväggen måste tillåta genomfarten och svaren behöver en väg tillbaka till poolen. Alla fyra felen delar ett symptom, så ändra en sak per försök och notera resultatet.

Tryck ut standardrutten och bekräfta vad klienten installerade

Raden på serversidan är kort, och den påverkar bara klienter som accepterar pushade alternativ. def1-formen installerar två halva standardrutter i stället för att radera den befintliga standardrutten, vilket håller den nuvarande anslutningen vid liv och ändå fångar varje destination.

push "redirect-gateway def1"

När du har återanslutit läser du klientens routingtabell i stället för att lita på profilen. På Linux visas de två /1-posterna bredvid den ursprungliga standardrutten, och Windows visar samma par som 0.0.0.0/1 och 128.0.0.0/1. En klient som ignorerar pushade alternativ, eller en som är konfigurerad att avvisa dem, behåller sin gamla standardrutt och skickar aldrig internettrafik in i tunneln. Avgör den frågan innan du ändrar något på servern, för ingen regel på serversidan kan kompensera.

Vidarebefordran är en serverinställning, inte en VPN-inställning

Läs vidarebefordringsflaggan innan du rör routingen. En nolla där betyder att kärnan tar emot klientens paket och vägrar skicka det vidare, vilket ser precis ut som en brandväggsblockering från andra änden. Sätt värdet via systemets konfigurationskatalog så att det överlever en omstart.

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

Bekräfta sedan att värden själv har en fungerande rutt till internetutgången. En förfrågan från serverns skal bevisar att den uppströms vägen är användbar och säger absolut ingenting om att vidarebefordra en klients paket, så behandla dem som två separata test. Om servern inte når destinationen hjälper ingen mängd vidarebefordringskonfiguration.

Tillåt exakt den genomfart du avser, och inget annat

Vidarebefordrade paket korsar forward-vägen; trafik adresserad till VPN-värden själv korsar input. Det är olika beslut, och att öppna input-vägen tillåter inte genomfart genom maskinen. Att blanda ihop dem är den vanligaste orsaken till att en brandvägg verkar tillåta allt medan klienterna fortfarande får timeout.

En minimal policy accepterar nya anslutningar från poolen mot utgångsgränssnittet och accepterar svar som hör till etablerade flöden. Lägg den i den regeluppsättningsägare som din distribution använder, i stället för att lägga till en dubblerad regel vid varje uppstart; dubblerade regler hopar sig och räknarna slutar betyda något.

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

Att växla varje kedja till accept får testet att gå igenom och tar bort anledningen till att brandväggen finns. Håll omfånget till poolen och utgångsgränssnittet, och låt orelaterad vidarebefordran vara.

Ge svaren någonstans att ta vägen

Pooladresserna är privata, så en offentlig server kan inte leverera ett svar direkt till dem. Antingen översätter VPN-värden källadressen på väg ut, eller så har en enhet uppströms en rutt tillbaka till poolen.

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

Lägg till exakt ett översättningslager. En andra NAT längre uppströms döljer den första och gör båda loggarna nästan värdelösa när något går sönder senare. Om en router uppströms redan routar poolen tillbaka är översättning på värden överflödig, och returvägen beror då på den routerns konfiguration i stället för din.

Molninstanser lägger till ännu en port, eftersom vissa plattformar släpper paket vars källadress inte är instansens egen om inte den kontrollen mildras. Den inställningen ligger utanför gästen och är lätt att glömma när en lokal testmaskin fungerar.

Bevisa det från klienten, inte från serverns skal

Börja med en numerisk IPv4-förfrågan, sedan en namnsökning, sedan applikationen. En ping bevisar vidarebefordran och översättning;den bevisar ingenting om namnmatchning, eftersom DNS-alternativ bara träder i kraft när klientintegrationen installerar dem.

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

Anteckna ändringarna och återställningssteget medan du går, så att utgångspolicyn kan rullas tillbaka med en enda åtgärd när ett test misslyckas. Det här receptet täcker bara IPv4; inventera IPv6 separat innan du hävdar att distributionen bär all trafik.