Odjemalci VPN se povežejo, a nimajo interneta: trije manjkajoči deli

Odjemalec dobi naslov, strežnik odgovarja na ping, in vsaka stran vseeno poteče. Večina ljudi na tej točki začne urejati profil odjemalca, kar je običajno zapravljen trud: ko je predor vzpostavljen, se mora strežnik obnašati kot usmerjevalnik. Trije pogoji morajo veljati hkrati, preden paket odide in se vrne odgovor, in simptom je enak, kateri koli manjka.

Zakaj delujoč predor še vedno nima izhoda

Jedro mora posredovati pakete med vmesniki, kar je v večini distribucij Linuxa privzeto izklopljeno. Promet je treba prevesti na naslov, na katerega lahko odgovori zunanji svet, razen če vsak nadrejeni usmerjevalnik že pozna povratno pot v podomrežje predora. Pot posredovanja požarnega zidu mora dovoljevati promet v obe smeri, vključno z odgovori.

Vsakega od teh je mogoče popraviti ločeno, in prav v tem je past. Vklop posredovanja brez pravila prevajanja pusti pakete, da odhajajo z zasebnim virom in brez povratne poti. Dodajanje prevajanja brez pravila posredovanja pusti jedro, da paket zavrže korak pozneje.

Zato preizkusite tri plasti namesto odjemalca in spreminjajte eno naenkrat, da bo rezultat kaj pomenil.

Posredovanje je stikalo jedra, ki ga morate trajno nastaviti

Pred spremembo preverite trenutno vrednost, nato jo nastavite in potrdite, da je sprememba začela veljati.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

Prvi ukaz sporoči trenutno vrednost, drugi jo nastavi med delovanjem, tretji pa dokaže, da je pisanje uspelo. Vrednost med delovanjem izgine ob naslednjem zagonu, zato se delujoča seja lahko po vzdrževanju zlomi brez kakršne koli spremembe konfiguracije.

Nastavite jo trajno v datoteki pod /etc/sysctl.d/, nato uporabite to datoteko, namesto da bi znova zagnali, da bi izvedeli. V FreeBSD je ustreznica net.inet.ip.forwarding, za trajnost pa gateway_enable=YES v rc.conf. Naprava, ki poroča o izklopljenem posredovanju, pojasni cel razred poročil „paketi pridejo in nič se ne vrne”. Nastavitev preverite tudi po vsaki nadgradnji, ker lahko ponovno zgrajeno jedro ali zamenjana slika naprave to ponastavi, ne da bi komu povedali.

Izberite masquerade ali en fiksen naslov prevajanja

Pri dinamičnem zunanjem naslovu je masquerading najpreprostejša pravilna oblika. Kot vir navedite podomrežje predora, kot izhod pa zunanji vmesnik.

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

Pri statičnem javnem naslovu je prevajanje vira na točno ta naslov bolj predvidljivo in lažje za revizijo.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

Druga oblika nosi past vzdrževanja: trdo zapisan naslov, ki se pozneje spremeni, ohranja predor delujoč, medtem ko se dostop do interneta tiho ustavi. Bodisi uporabite masquerade bodisi posodobite pravilo vsakič, ko vas ponudnik premakne. Tudi vmesnik je pomemben, ker mora usmerjevalnik, ki si deli lasten nadrejeni predor, prevajati skozi ta predor in ne skozi fizični WAN.

Filtrira tabela je tretja vrata

Posredovanje in prevajanje sta lahko oba pravilna, paket pa vseeno umre v filtirni tabeli. ufw je pogost krivec: njegova politika posredovanja je dobavljena kot DROP, preostala nastavitev pa je lahko videti popolnoma pravilna, medtem ko ta ena nastavitev ubija promet. Dvigniti jo je zavestna varnostna odločitev, ne potrditveno polje.

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Prvo pravilo dovoljuje nov promet iz predora navzven, drugo pa samo odgovore nazaj. Oba zožite na podomrežje predora in predvideni cilj, ker splošno dovoljenje na vmesniku predora spremeni VPN v odprto izhodno točko za vsakogar, ki se lahko overi.

Premoščen predor potrebuje drugačen odgovor. Naslov pripada mostu, ne fizičnemu vratom, zato podreditev vmesnika odstrani naslov, ki ga je imel prej, in gostitelj se zdi nedosegljiv, dokler sam most ne dobi naslova, kar lahko zagotovi dhclient br0. Ta okvara je videti kot težava VPN, v resnici pa je težava drugega sloja. Preverite lastni naslov mostu, preden se dotaknete požarnega zidu, ker sprememba filtra ne more popraviti gostitelja, ki nima več naslova, s katerega bi pošiljal.

Kam pogledati, ko se stran nikoli ne naloži

Pingajte naslov predora strežnika, da dokažete, da predor obstaja. Nato zaženite traceroute z odjemalca na javni naslov in preberite, kje se ustavi: na strežniku paket prispe, a ni posredovan ali preveden; za strežnikom je težava višje in zunaj vaših rok.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

Prvi ukaz dokaže, da predor nosi promet do samega strežnika, drugi pa pokaže, kako daleč paket pride navzven. Sled, ki se konča na naslovu predora, kaže na posredovanje ali prevajanje na strežniku, medtem ko sled, ki se ustavi en skok pozneje, kaže na ponudnika ali povratno pot nadrejenega usmerjevalnika.

Na strežniku opazujte zunanji vmesnik, medtem ko odjemalec nalaga stran. Promet, ki odhaja z zasebnim izvornim naslovom, pomeni, da manjka prevajanje, popolna odsotnost odgovora pa pomeni, da ga pot posredovanja ali nadrejena povratna pot zavrže.

Če morajo oddaljeni odjemalci doseči tudi gostitelje v LAN-u strežnika, si zapomnite, da LAN potrebuje povratno pot v podomrežje predora. To je usmerjanje in ne prevajanje, in to je korak, ki se najpogosteje pozabi, ko pot v internet končno deluje.