Odjemalec se overi, prejme naslov iz bazena in doseže storitve na gostitelju VPN, a vsaka javna destinacija se konča s potekom časa. Tako je videti tunel brez izhoda in tako ostane, dokler niso izpolnjeni štirje ločeni pogoji. Odjemalec mora sprejeti privzeto pot, strežnik mora posredovati, požarni zid mora dovoliti tranzit, odgovori pa potrebujejo pot nazaj v bazen. Vse štiri napake imajo enak simptom, zato spreminjajte en element na poskus in zapišite rezultat.

Potisnite privzeto pot in preverite, kaj je odjemalec namestil

Vrstica na strani strežnika je kratka in vpliva le na odjemalce, ki sprejemajo potisnjene možnosti. Oblika def1 namesti dve pol-privzeti poti namesto brisanja obstoječe privzete, kar ohrani trenutno povezavo živo in hkrati zajame vsako destinacijo.

push "redirect-gateway def1"

Po ponovni povezavi preberite usmerjevalno tabelo odjemalca, namesto da bi zaupali profilu. V Linuxu se dva vnosa /1 pojavita ob prvotni privzeti poti, Windows pa prikaže isti par kot 0.0.0.0/1 in 128.0.0.0/1. Odjemalec, ki potisnjene možnosti ignorira, ali tisti, ki je nastavljen, da jih zavrne, obdrži staro privzeto pot in nikoli ne pošlje internetnega prometa v tunel. To vprašanje razrešite, preden na strežniku karkoli spremenite, ker nobeno pravilo na strani strežnika tega ne more nadomestiti.

Posredovanje je nastavitev strežnika, ne nastavitev VPN

Preberite zastavico posredovanja, preden se dotaknete usmerjanja. Ničla tam pomeni, da jedro prejme odjemalčev paket in ga zavrne posredovati naprej, kar je videti natanko kot blokada požarnega zidu z druge strani. Vrednost nastavite prek konfiguracijske mape sistema, da preživi ponovni zagon.

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

Nato preverite, ali ima gostitelj sam delujočo pot do internetnega izhoda. Zahteva iz lupine strežnika dokazuje, da je pot navzgor uporabna, in ne pove popolnoma ničesar o posredovanju odjemalčevega paketa, zato ju obravnavajte kot dva ločena testa. Če strežnik ne doseže cilja, nobena količina konfiguracije posredovanja ne bo pomagala.

Dovolite natanko tisti tranzit, ki ga nameravate, in nič drugega

Posredovani paketi prečkajo pot forward; promet, naslovljen na gostitelja VPN samega, prečka input. To so različne odločitve in odpiranje poti input ne dovoljuje tranzita skozi stroj. Njihovo mešanje je najpogostejši razlog, da se zdi, da požarni zid dovoli vse, medtem ko odjemalcem še vedno poteka čas.

Minimalna politika sprejme nove povezave iz bazena proti izhodnemu vmesniku in sprejme odgovore, ki pripadajo vzpostavljenim tokovom. Postavite jo k tistemu lastniku nabora pravil, ki ga uporablja vaša distribucija, namesto da bi pri vsakem zagonu dodali podvojeno pravilo; podvojena pravila se kopičijo in števci prenehajo kaj pomeniti.

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

Preklop vsake verige na sprejem poskrbi, da test uspe, in odpravi razlog za obstoj požarnega zidu. Obseg držite na bazenu in izhodnem vmesniku, nepovezano posredovanje pa pustite pri miru.

Dajte odgovorom kam iti

Naslovi bazena so zasebni, zato javni strežnik ne more dostaviti odgovora neposredno nanje. Ali gostitelj VPN pretvori izvorni naslov na izhodu, ali naprava višje drži pot nazaj v bazen.

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

Dodajte natanko eno plast pretvorbe. Drugi NAT višje skrije prvega in oba dnevnika naredi skoraj neuporabna, ko se pozneje kaj pokvari. Če usmerjevalnik višje bazen že usmerja nazaj, je dodajanje pretvorbe na gostitelju odveč, pot vrnitve pa je takrat odvisna od konfiguracije tega usmerjevalnika in ne od vaše.

Primeri v oblaku dodajo še ena vrata, ker nekatere platforme zavržejo pakete, katerih izvorni naslov ni naslov primerka, razen če se ta preveritev omili. Ta nastavitev je zunaj gosta in jo je lahko pozabiti, ko lokalni testni stroj deluje.

Dokažite to z odjemalca, ne iz lupine strežnika

Začnite s številčno zahtevo IPv4, nato z iskanjem imena, nato z aplikacijo. ping dokazuje posredovanje in pretvorbo;o razreševanju imen ne dokazuje ničesar, ker možnosti DNS začnejo veljati šele, ko jih namesti integracija odjemalca.

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

Sproti zapisujte spremembe in korak razveljavitve, da bo mogoče izhodno politiko razveljaviti z enim dejanjem, ko test ne uspe. Ta recept pokriva samo IPv4; IPv6 popišite ločeno, preden trdite, da uvajanje nosi ves promet.

Sorodni članki