Povezani na OpenVPN, ali ništa se ne učitava: prolazak sa strane klijenta

Prozor klijenta kaže Connected, adresa tunela je tu, a preglednik se još vrti. Ta kombinacija je normalna, jer uspješan handshake dokazuje samo da je tunel izgrađen; ona ne govori ništa o tome hoće li poslužitelj prosljeđivati vaše pakete, prepisivati njihov izvor ili odgovarati na vaše DNS upite. Većina ljudi griješi tako što prvo otvori konfiguraciju poslužitelja. Umjesto toga krenite od klijenta prema van, jer svaki korak ispod kaže vrijedi li sljedeći uopće provjeravati.

Počnite na klijentu i idite prema van

Izvedite tri testa ovim redom i zapišite gdje prvi pada. Pingajte adresu tunela na poslužitelju, što dokazuje da sam tunel prenosi promet. Pingajte javnu adresu po broju, što dokazuje prosljeđivanje i prevođenje bez uključivanja razrješavanja imena. Zatim pokušajte razriješiti ime hosta, što je jedini test koji pokreće DNS. Svaki rezultat uklanja cijeli sloj iz sumnje.

Ne preskačite na treći test zato što se preglednik čini bržim. Neuspjelo učitavanje stranice pokriva sva tri sloja odjednom, i upravo tako ljudi počnu i onda ponovno grade tunel koji radi. Stranica koja pada ne kaže vam koji se od tri sloja slomio.

Dva snimanja pokazuju gdje se paketi zaustavljaju

Dok s klijenta ide ping na javnu adresu, napravite jedno snimanje na sučelju tunela i jedno na uzlaznom vodu koji bi trebao dosezati internet. Pokrenite oba istovremeno kako bi se vremenske oznake poklopile.

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

Ako se zahtjevi pojavljuju na tunelu i nikada na uzlaznom vodu, poslužitelj ih je odbacio između tunela i žice, a uzrok je prosljeđivanje ili politika vatrozida za prosljeđivanje, a ne NAT. Ako se pojavljuju na oba, poslužitelj je odradio svoj dio, a odgovor nedostaje dalje, što upućuje na prevođenje, filtar uzvodno ili ograničenje od davatelja usluga.

Naziv uzlaznog voda uzmite iz tablice usmjeravanja, a ne iz tutorijala. Cloud slike i preimenovani adapteri rijetko se poklapaju s primjerom sučelja u vodiču, a snimanje na pogrešnom uređaju izgleda točno kao poslužitelj koji ne prosljeđuje:

ip -4 route get 9.9.9.9

Polje dev u tom izlazu naziv je koji će NAT pravilo kasnije trebati, pa ga zadržite.

Prosljeđivanje je prekidač u jezgru i politika vatrozida

Jezgro mora uopće pristati na prosljeđivanje. Pročitajte trenutnu vrijednost, a zatim postavku učinite trajnom umjesto da je upišete samo u jezgro koje radi:

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

Prosljeđivanje je samo pola posla. Na hostu s UFW politika prosljeđivanja postavlja se u /etc/default/ufw i mora biti ACCEPT prije nego reload stupi na snagu. Zadano odbacivanje na putu prosljeđivanja ostavlja handshake potpuno zdravim, dok tiho odbacuje svaki paket koji pokuša izaći kroz tunel, što je upravo simptom s kojim ste počeli.

Hostovi koji izravno upravljaju nftablesom imaju isto pitanje u drugoj sintaksi. Gledajte brojače na lancu prosljeđivanja dok traje test s klijenta, jer lanac koji se konzultira i lanac koji odbacuje u konfiguracijskoj datoteci izgledaju jednako.

Imenujte stvarno izlazno sučelje u NAT pravilu

Prevođenje izvora pripada sučelju koje doista napušta host, uz pool koji poslužitelj dodjeljuje. Obje polovice tog pravila moraju opisivati stvarnost i nijedna nije neobavezna.

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

Klasična greška je pravilo kopirano iz vodiča koje kaže -o eth0 na računalu čiji se adapter zove drugačije. Pravilo se instalira bez upozorenja, ne poklapa se ni s čim, a klijent i dalje nema internet. Pool je druga polovica iste greške: ako poslužitelj dijeli 10.44.0.0/24, a pravilo pokriva 10.8.0.0/24, ništa se nikada neće poklopiti.

Gledajte brojače umjesto da vjerujete tekstu pravila. Popis izvještava pakete po pravilu, a pravilo koje se nikad ne poklapa ostaje na nuli koliko god ispravno izgledalo. Dajte mu minutu stvarnog prometa s klijenta prije nego što išta zaključite iz tog broja:

iptables -t nat -L POSTROUTING -v -n

Nulti broj paketa nakon stvarnog testa s klijenta znači da je poklapanje pogrešno, a ne da je tunel slomljen. Kad se poklopi, spremite skup pravila da preživi ponovno pokretanje; popravak koji živi samo u povijesti ljuske nestaje pri prvom restartu.

Ako je poslužitelj i cloud NAT instanca, platforma također ima riječ. Instanca koja prevodi adrese obično treba isključenu provjeru izvora i odredišta gdje davatelj nudi tu postavku, a sam VPN port mora biti dostupan izvana.

DNS je drugi kvar iza prvoga

Ping po adresi koji radi dok imena padaju problem je razrješivača, i ima svoj uzrok. Klijent koji zadržava svoj lokalni razrješivač šalje te upite u puni tunel i čeka odgovor koji nikada ne dolazi, jer je lokalni razrješivač sada na pogrešnoj strani rute.

Pošaljite razrješivač s poslužitelja kako bi klijent znao gdje pitati. Dva unosa daju klijentu rezervu ako prvi nije dosežan, a oba bi trebala biti razrješivači koje tunel doista dopušta.

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Windows klijenti tada se ipak mogu vratiti na lokalni razrješivač, a upravo to block-outside-dns postoji da spriječi, uz cijenu gubitka imena koja samo lokalna mreža može razriješiti. Linux klijenti sa systemd-resolved često ignoriraju poslani razrješivač ako ga skripta ne instalira, pa provjerite resolvectl status za uređaj tunela prije nego zaključite da je slanje ignorirano.

Završite prolazak onako kako ga korisnik doživljava. Učitajte stvarnu stranicu s klijenta, potvrdite adresu s koje izlazi, ponovno pokrenite poslužitelj, spojite se i ponovite tri testa. Samo taj drugi prolaz dokazuje da su spremljena pravila, politika vatrozida i poslani razrješivač svi zajedno preživjeli.