Voltonnel-OpenVPN: voeg ’n internetuitgang aan die bedienerkant by

’n Kliënt verifieer, ontvang ’n adres uit die poel en bereik dienste op die VPN-gasheer, maar elke publieke bestemming val op ’n tydbeperking. Dit is hoe ’n tonnel sonder uitgang lyk, en dit bly so totdat vier afsonderlike dinge waar is. Die kliënt moet ’n verstekroete aanvaar, die bediener moet aanstuur, die brandmuur moet die deurgang toelaat, en antwoorde het ’n pad terug na die poel nodig. Al vier foute deel een simptoom, so verander een item per poging en teken die resultaat aan.

Stoot die verstekroete en bevestig wat die kliënt geïnstalleer het

Die reël aan die bedienerkant is kort, en dit raak net kliënte wat gestootte opsies aanvaar. Die def1-vorm installeer twee half-verstekroetes in plaas daarvan om die bestaande verstek te skrap, wat die huidige verbinding lewendig hou terwyl elke bestemming steeds vasgevang word.

push "redirect-gateway def1"

Lees die kliënt se roetertabel nadat jy weer verbind het, eerder as om die profiel te vertrou. Op Linux verskyn die twee /1-inskrywings langs die oorspronklike verstek, en Windows wys dieselfde paar as 0.0.0.0/1 en 128.0.0.0/1. ’n Kliënt wat gestootte opsies ignoreer, of een wat ingestel is om hulle te weier, hou sy ou verstek en stuur nooit internetverkeer in die tonnel in nie. Beslis daardie vraag voordat jy enigiets op die bediener verander, want geen reël aan die bedienerkant kan dit vergoed nie.

Aanstuur is ’n bedienerinstelling, nie ’n VPN-instelling nie

Lees die aanstuurvlag voordat jy aan roetering raak. ’n Nul daar beteken die kern ontvang die kliënt se pakket en weier om dit verder te stuur, wat presies soos ’n brandmuurblok van die ander kant lyk. Stel die waarde deur die stelsel se konfigurasiegids sodat dit ’n herlaai oorleef.

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

Bevestig daarna dat die gasheer self ’n werkende roete na die internetuitgang het. ’n Versoek uit die bediener se dop bewys die opstroompad is bruikbaar en sê glad niks oor die aanstuur van ’n kliënt se pakket nie, so hanteer dit as twee afsonderlike toetse. As die bediener nie die bestemming kan bereik nie, sal geen hoeveelheid aanstuurkonfigurasie help nie.

Laat net die deurgang toe wat jy bedoel

Doorgestuurde pakkette kruis die aanstuurpad; verkeer wat aan die VPN-gasheer self gerig is, kruis insette. Dit is afsonderlike besluite, en om die insetpad oop te maak laat nie deurgang deur die masjien toe nie. Om hulle te verwar is die algemeenste rede waarom ’n brandmuur lyk of dit alles toelaat terwyl kliënte steeds op ’n tydbeperking val.

’n Minimale beleid aanvaar nuwe verbindings van die poel na die uitgangskoppelvlak en aanvaar antwoorde wat aan gevestigde vloei behoort. Sit dit in watter reëlversameling-eienaar jou verspreiding ook al gebruik, eerder as om by elke selflaai ’n duplikaatreël by te voeg; duplikaatreëls hoop op en die tellers beteken niks meer nie.

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

Om elke ketting na aanvaar te skakel laat die toets slaag en verwyder die rede waarom die brandmuur bestaan. Hou die omvang by die poel en die uitgangskoppelvlak, en los onverwante aanstuur alleen.

Gee die antwoorde ’n plek om heen te gaan

Poeladresse is privaat, so ’n publieke bediener kan nie ’n antwoord direk daarheen lewer nie. Óf die VPN-gasheer vertaal die bronadres op pad uit, óf ’n toestel stroomop het ’n roete terug na die poel.

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

Voeg presies een vertaallaag by. ’n Tweede NAT verder stroomop verberg die eerste en maak albei logboeke byna nutteloos wanneer iets later breek. As ’n opstroomroeteerder die poel reeds terugroeteer, is vertaling op die gasheer oorbodig, en die terugpad hang dan van daardie roeteerder se konfigurasie af eerder as van joune.

Wolkgevalle voeg nog een hek by, want sommige platforms laat pakkette val waarvan die bronadres nie die geval se eie is nie, tensy daardie kontrole verslap word. Daardie instelling sit buite die gas en is maklik om te vergeet wanneer ’n plaaslike toetsmasjien werk.

Bewys dit vanaf die kliënt, nie vanaf die bediener se dop nie

Begin met ’n numeriese IPv4-versoek, dan ’n naamsoektog, dan die toepassing. ’n Ping bewys aanstuur en vertaling; dit bewys niks oor naamoplossing nie, want DNS-opsies werk eers wanneer die kliëntintegrasie hulle installeer.

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

Teken die veranderinge en die onttrekstap aan soos jy werk, sodat die uitgangsbeleid in een aksie teruggerol kan word wanneer ’n toets misluk. Hierdie resep dek slegs IPv4; inventariseer IPv6 afsonderlik voordat jy beweer die ontplooiing dra alle verkeer.