Full tunnel OpenVPN: legg til ein internettutgang på tenarsida

Ein klient autentiserer seg, får ei adresse frå puljen og når tenester på VPN-verten, men kvar offentleg destinasjon går ut på tid. Slik ser ein tunnel utan utgang ut, og slik blir det ståande til fire skilde ting er sanne. Klienten må godta ei standardrute, tenaren må vidaresenda, brannmuren må tillate gjennomgangen, og svara treng ein veg tilbake til puljen. Alle fire feila deler eitt symptom, så endre éin ting per forsøk og noter resultatet.

Skyv standardruta ut og stadfest kva klienten installerte

Lina på tenarsida er kort, og ho påverkar berre klientar som godtek pusha val. def1-forma installerer to halve standardruter i staden for å sletta den eksisterande standardruta, noko som held den noverande tilkoplinga i live og samstundes fangar kvar destinasjon.

push "redirect-gateway def1"

Etter at du har kopla til på nytt, les rutetabellen til klienten i staden for å stola på profilen. På Linux dukkar dei to /1-oppføringane opp ved sida av den opphavlege standardruta, og Windows viser det same paret som 0.0.0.0/1 og 128.0.0.0/1. Ein klient som ignorerer pusha val, eller ein som er konfigurert til å avvisa dei, held på si gamle standardrute og sender aldri internettrafikk inn i tunnelen. Avgjer det spørsmålet før du endrar noko på tenaren, for ingen regel på tenarsida kan kompensera.

Vidaresending er ei tenarinnstilling, ikkje ei VPN-innstilling

Les vidaresendingsflagget før du rører rutinga. Ein null der betyr at kjernen tek imot pakken til klienten og nektar å senda han vidare, noko som ser nøyaktig ut som ein brannmurblokkering frå den andre enden. Set verdien via konfigurasjonskatalogen til systemet slik at han overlever ein omstart.

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

Stadfest deretter at verten sjølv har ei fungerande rute til internettutgangen. Ei førespurnad frå skalet på tenaren beviser at oppstraumsvegen er brukande og seier absolutt ingenting om å vidaresenda pakken til ein klient, så handsam dei som to skilde testar. Viss tenaren ikkje når destinasjonen, hjelper ingen mengd vidaresendingskonfigurasjon.

Tillat nøyaktig den gjennomgangen du meiner, og ingenting anna

Vidaresende pakkar kryssar forward-vegen; trafikk adressert til VPN-verten sjølv kryssar input. Det er skilde avgjerder, og å opna input-vegen tillèt ikkje gjennomgang gjennom maskina. Å blanda dei er den vanlegaste årsaka til at ein brannmur ser ut til å tillata alt medan klientane framleis går ut på tid.

Ein minimal politikk godtek nye tilkoplingar frå puljen mot utgangsgrensesnittet og godtek svar som høyrer til etablerte straumar. Legg han i den regelsett-eigaren distribusjonen din brukar, i staden for å leggja til ein duplisert regel ved kvar oppstart; dupliserte reglar hopar seg opp og teljarane sluttar å bety noko.

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

Å setja kvar kjede til å godta får testen til å gå gjennom og fjernar grunnen til at brannmuren finst. Hald omfanget til puljen og utgangsgrensesnittet, og lat uvedkommande vidaresending vera.

Gje svara ein stad å gå

Puljeadresser er private, så ein offentleg tenar kan ikkje levera eit svar direkte til dei. Anten omset VPN-verten kjeldadressa på veg ut, eller ein eining oppstraums held ei rute tilbake til puljen.

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

Legg til nøyaktig eitt omsetjingslag. Ein andre NAT lenger oppstraums gøymer den første og gjer begge loggane nesten ubrukelege når noko seinare går i stykke. Viss ein ruter oppstraums alt ruter puljen tilbake, er omsetjing på verten overflødig, og returvegen avheng då av konfigurasjonen til den ruteren i staden for din.

Skyforekomstar legg til endå ei port, fordi nokre plattformer droppar pakkar der kjeldadressa ikkje er forekomsten si eiga, med mindre den kontrollen blir mjuka opp. Den innstillinga ligg utanfor gjesten og er lett å gløyma når ein lokal testmaskin verkar.

Bevis det frå klienten, ikkje frå skalet på tenaren

Start med ein numerisk IPv4-førespurnad, deretter eit namneoppslag, deretter applikasjonen. Ein ping beviser vidaresending og omsetjing;han beviser ingenting om namneoppslag, fordi DNS-val først trer i kraft når klientintegrasjonen installerer dei.

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

Noter endringane og angre-trinnet undervegs, slik at utgangspolitikken kan rullast tilbake med éi handling når ein test feilar. Denne oppskrifta dekkjer berre IPv4; kartlegg IPv6 separat før du hevdar at utrullinga ber all trafikk.