Full tunnel OpenVPN: legg til en internettutgang på serversiden

En klient autentiserer seg, mottar en adresse fra puljen og når tjenester på VPN-verten, men hver offentlig destinasjon går ut på tid. Slik ser en tunnel uten utgang ut, og slik blir det stående til fire atskilte ting er sanne. Klienten må godta en standardrute, serveren må videresende, brannmuren må tillate gjennomgangen, og svar trenger en vei tilbake til puljen. Alle fire feilene deler ett symptom, så endre én ting per forsøk og noter resultatet.

Skyv standardruten ut og bekreft hva klienten installerte

Linjen på serversiden er kort, og den påvirker bare klienter som godtar push-ede alternativer. def1-formen installerer to halve standardruter i stedet for å slette den eksisterende standardruten, noe som holder den nåværende forbindelsen i live samtidig som hver destinasjon fortsatt fanges opp.

push "redirect-gateway def1"

Etter at du har koblet til på nytt, les klientens rutetabell i stedet for å stole på profilen. På Linux vises de to /1-oppføringene ved siden av den opprinnelige standardruten, og Windows viser det samme paret som 0.0.0.0/1 og 128.0.0.0/1. En klient som ignorerer push-ede alternativer, eller en som er konfigurert til å avvise dem, beholder sin gamle standardrute og sender aldri internettrafikk inn i tunnelen. Avgjør det spørsmålet før du endrer noe på serveren, for ingen regel på serversiden kan kompensere.

Videresending er en serverinnstilling, ikke en VPN-innstilling

Les videresendingsflagget før du rører rutingen. En null der betyr at kjernen mottar klientens pakke og nekter å sende den videre, noe som ser nøyaktig ut som en brannmurblokkering fra den andre enden. Sett verdien via systemets konfigurasjonskatalog slik at den overlever 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

Bekreft deretter at verten selv har en fungerende rute til internettutgangen. En forespørsel fra serverens skall beviser at oppstrømsveien er brukbar og sier absolutt ingenting om å videresende en klients pakke, så behandle dem som to separate tester. Hvis serveren ikke når destinasjonen, hjelper ingen mengde videresendingskonfigurasjon.

Tillat nøyaktig den gjennomgangen du mener, og ingenting annet

Videresendte pakker krysser forward-veien; trafikk adressert til VPN-verten selv krysser input. Det er forskjellige beslutninger, og å åpne input-veien tillater ikke gjennomgang gjennom maskinen. Å blande dem er den vanligste årsaken til at en brannmur ser ut til å tillate alt mens klientene fortsatt går ut på tid.

En minimal policy godtar nye tilkoblinger fra puljen mot utgangsgrensesnittet og godtar svar som hører til etablerte strømmer. Legg den i den regelsett-eieren distribusjonen din bruker, i stedet for å legge til en duplisert regel ved hver oppstart; dupliserte regler hoper seg opp og tellerne slutter å bety noe.

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

Å sette hver kjede til godta får testen til å bestå og fjerner grunnen til at brannmuren finnes. Hold omfanget til puljen og utgangsgrensesnittet, og la uvedkommende videresending være.

Gi svarene et sted å gå

Puljeadresser er private, så en offentlig server kan ikke levere et svar direkte til dem. Enten oversetter VPN-verten kildeadressen på vei ut, eller en enhet oppstrøms har en rute tilbake til puljen.

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

Legg til nøyaktig ett oversettelseslag. En andre NAT lenger oppstrøms skjuler den første og gjør begge loggene nesten ubrukelige når noe senere går i stykker. Hvis en ruter oppstrøms allerede ruter puljen tilbake, er oversettelse på verten overflødig, og returveien avhenger da av den ruterens konfigurasjon i stedet for din.

Skyforekomster legger til enda en port, fordi noen plattformer dropper pakker der kildeadressen ikke er forekomstens egen, med mindre den kontrollen lempes. Den innstillingen ligger utenfor gjesten og er lett å glemme når en lokal testmaskin virker.

Bevis det fra klienten, ikke fra serverens skall

Start med en numerisk IPv4-forespørsel, deretter et navneoppslag, deretter applikasjonen. En ping beviser videresending og oversettelse;den beviser ingenting om navneoppslag, fordi DNS-alternativer først trer i kraft når klientintegrasjonen installerer dem.

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

Noter endringene og angre-trinnet underveis, slik at utgangspolicyen kan rulles tilbake med én handling når en test feiler. Denne oppskriften dekker bare IPv4; kartlegg IPv6 separat før du hevder at utrullingen bærer all trafikk.