Täistunneli-OpenVPN: lisage serveripoolsele poolele interneti väljapääs

Klient autendib end, saab basseinist aadressi ja jõuab VPN-hostil olevate teenusteni, kuid iga avalik sihtkoht lõpeb aegumisega. Nii näeb välja väljapääsuta tunnel ja nii see jääb, kuni neli eraldiseisvat asja on tõsi. Klient peab nõustuma vaikimisi marsruudiga, server peab edasi suunama, tulemüür peab läbikäigu lubama ja vastused vajavad teed tagasi basseini. Kõigil neljal tõrkel on üks sümptom, seega muutke katse kohta üht asja ja märkige tulemus üles.

Lükake vaikimisi marsruut välja ja kontrollige, mida klient paigaldas

Serveripoolne rida on lühike ja see mõjutab ainult kliente, kes aktsepteerivad peale surutud valikuid. Vorm def1 paigaldab kaks pool-vaikimisi marsruuti, selle asemel et olemasolev vaikimisi marsruut kustutada, mis hoiab praeguse ühenduse elus ja püüab samal ajal iga sihtkoha.

push "redirect-gateway def1"

Pärast uuesti ühendamist lugege kliendi marsruutimistabelit, selle asemel et profiili usaldada. Linuxis ilmuvad kaks /1-kirjet algse vaikimisi marsruudi kõrvale ja Windows näitab sama paari kujul 0.0.0.0/1 ja 128.0.0.0/1. Klient, mis eirab peale surutud valikuid, või selline, mis on seadistatud neid tagasi lükkama, hoiab oma vana vaikimisi marsruuti ega saada kunagi internetiliiklust tunnelisse. Lahendage see küsimus enne, kui midagi serveris muudate, sest ükski serveripoolne reegel ei suuda seda kompenseerida.

Edasisuunamine on serveri seade, mitte VPN-i seade

Lugege edasisuunamise lippu enne, kui marsruutimist puudutate. Null seal tähendab, et kernel võtab kliendi paketi vastu ja keeldub seda edasi andmast, mis näeb täpselt välja nagu tulemüüri blokeering kaugemalt poolt. Määrake väärtus süsteemi konfiguratsioonikataloogi kaudu, et see taaskäivituse üle elaks.

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

Järgmisena kontrollige, et hostil endal oleks toimiv marsruut interneti väljapääsuni. Serveri kestast tehtud päring tõestab, et ülemine tee on kasutatav, ja ei ütle üldse midagi kliendi paketi edasisuunamise kohta, seega käsitlege neid kahe eraldi testina. Kui server ei jõua sihtkohta, ei aita ükski kogus edasisuunamise seadistust.

Lubage täpselt see läbikäik, mida kavatsete, ja mitte midagi muud

Edasisuunatud paketid läbivad forward-tee; VPN-hosti enda vastu suunatud liiklus läbib input-tee. Need on erinevad otsused ja input-tee avamine ei luba masinast läbi kulgeda. Nende segiajamine on kõige tavalisem põhjus, miks tulemüür näib lubavat kõike, samal ajal kui kliendid ikka aeguvad.

Minimaalne poliitika aktsepteerib uusi ühendusi basseinist väljundliidese suunas ja aktsepteerib vastuseid, mis kuuluvad loodud voogudele. Pange see sinna reeglistiku omanikku, mida teie distributsioon kasutab, selle asemel et igal alglaadimisel duplikaatreegel lisada; duplikaadid kuhjuvad ja loendurid kaotavad tähenduse.

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

Iga ahela aktsepteerimisele lülitamine laseb testil läbida ja eemaldab tulemüüri olemasolu põhjuse. Hoidke ulatus basseini ja väljundliidese juures ning jätke mitteseotud edasisuunamine puutumata.

Andke vastustele koht, kuhu minna

Basseini aadressid on privaatsed, seega avalik server ei saa vastust neile otse kohale toimetada. Kas VPN-host tõlgib väljumisel lähteaadressi või hoiab ülemine seade marsruuti tagasi basseini.

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

Lisage täpselt üks tõlkekiht. Teine NAT ülalpool varjab esimese ja muudab mõlemad logid hiljem millegi katkedes peaaegu kasutuks. Kui ülemine ruuter suunab basseini juba tagasi, on hostil tõlke lisamine üleliigne ja tagasitee sõltub siis selle ruuteri seadistusest, mitte teie omast.

Pilveinstantsid lisavad veel ühe värava, sest mõned platvormid viskavad pakette, mille lähteaadress ei ole instantsi oma, kui seda kontrolli ei leevendata. See seade asub külalisest väljaspool ja seda on lihtne unustada, kui kohalik testmasin töötab.

Tõestage seda kliendist, mitte serveri kestast

Alustage numbrilise IPv4-päringuga, seejärel nimeotsinguga, seejärel rakendusega. ping tõestab edasisuunamist ja tõlget;see ei tõesta nime lahendamise kohta midagi, sest DNS-valikud mõjuvad alles siis, kui kliendi integratsioon need paigaldab.

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

Märkige muudatused ja tagasivõtmise samm jooksvalt üles, et väljundpoliitika saaks testi ebaõnnestudes ühe toiminguga tagasi pöörata. See retsept katab ainult IPv4; kaardistage IPv6 eraldi, enne kui väidate, et juurutus kannab kogu liiklust.