Povezani z OpenVPN, a nič se ne naloži: pot od odjemalca navzven

Okno odjemalca piše Connected, naslov predora je tam, brskalnik pa se še vedno vrti. Ta kombinacija je običajna, ker uspešen rokovanje dokazuje samo, da je bil predor zgrajen; ne pove nič o tem, ali bo strežnik posredoval vaše pakete, prepisal njihov vir ali odgovoril na vaše poizvedbe DNS. Napaka, ki jo naredi večina, je, da najprej odpre konfiguracijo strežnika. Namesto tega delajte od odjemalca navzven, ker vsak korak spodaj pove, ali je naslednjega sploh vredno preveriti.

Začnite pri odjemalcu in pojdite navzven

Izvedite tri preizkuse v tem vrstnem redu in zapišite, kje prvi spodleti. Pingajte naslov predora na strežniku, kar dokazuje, da predor sam prenaša promet. Pingajte javni naslov po številki, kar dokazuje posredovanje in prevajanje brez vključevanja razreševanja imen. Nato poskusite razrešiti ime gostitelja, kar je edini preizkus, ki uporablja DNS. Vsak rezultat odstrani celotno plast iz suma.

Ne skočite na tretji preizkus, ker se brskalnik zdi hitrejši. Neuspešno nalaganje strani pokrije vse tri plasti hkrati, in prav tam ljudje začnejo in nato znova zgradijo predor, ki je deloval. Stran, ki spodleti, ne pove, katera od treh plasti se je zlomila.

Dva zajema pokažeta, kje se paketi ustavijo

Medtem ko z odjemalca teče ping na javni naslov, naredite en zajem na vmesniku predora in enega na zgornji povezavi, ki naj bi dosegla internet. Zaženite oba hkrati, da se časovni žigi ujemajo.

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

Če se zahteve pojavijo na predoru in nikoli na zgornji povezavi, jih je strežnik zavrgel med predorom in kablom, vzrok pa je posredovanje ali požarna politika za posredovanje, ne NAT. Če se pojavijo na obeh, je strežnik opravil svoj del, odgovor pa manjka dlje zunaj, kar kaže na prevajanje, filter višje ali omejitev ponudnika.

Ime zgornje povezave vzemite iz usmerjevalne tabele, ne iz vadnice. Oblaki in preimenovani vmesniki se redko ujemajo z vzorčnim vmesnikom v priročniku, zajem na napačni napravi pa je videti natanko kot strežnik, ki ne posreduje:

ip -4 route get 9.9.9.9

Polje dev v tem izpisu je ime, ki ga bo pravilo NAT potrebovalo pozneje, zato ga obdržite.

Posredovanje je stikalo v jedru in požarna politika

Jedro mora sploh privoliti v posredovanje. Preberite trenutno vrednost in nato nastavitev naredite trajno, namesto da bi jo zapisali le v delujoče jedro:

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

Posredovanje je le polovica. Na gostitelju z UFW se požarna politika posredovanja nastavi v /etc/default/ufw in mora biti ACCEPT, preden ponovno nalaganje začne veljati. Privzeto zavračanje na poti posredovanja pusti rokovanje popolnoma zdravo, a tiho zavrže vsak paket, ki poskuša oditi skozi predor, in to je natanko simptom, s katerim ste začeli.

Gostitelji, ki nftables upravljajo neposredno, imajo isto vprašanje v drugi sintaksi. Opazujte števce na verigi posredovanja, medtem ko teče preizkus z odjemalca, ker sta veriga, po kateri se sprašuje, in veriga, ki zavrača, v konfiguracijski datoteki videti enako.

V pravilu NAT poimenujte pravi izhodni vmesnik

Prevajanje vira sodi na vmesnik, ki gostitelja resnično zapusti, s skladom, ki ga strežnik razdeli. Obe polovici tega pravila morata opisovati resničnost in nobena ni izbirna.

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

Klasičen neuspeh je pravilo, kopirano iz priročnika, ki pravi -o eth0 na stroju, katerega vmesnik se imenuje drugače. Pravilo se namesti brez opozorila, ne ujame ničesar, odjemalec pa še vedno nima interneta. Sklad je druga polovica iste napake: če strežnik razdeli 10.44.0.0/24 in pravilo pokriva 10.8.0.0/24, se ne bo nikoli nič ujemalo.

Opazujte števce, namesto da bi zaupali besedilu pravila. Seznam poroča pakete na pravilo, pravilo, ki se nikoli ne ujame, pa ostane na ničli, ne glede na to, kako pravilno je videti. Dajte mu minuto resničnega prometa odjemalca, preden iz te številke kaj sklepate:

iptables -t nat -L POSTROUTING -v -n

Ničelno število paketov po resničnem preizkusu odjemalca pomeni, da je ujemanje napačno, ne da je predor pokvarjen. Ko se ujame, shranite nabor pravil, da preživi ponovni zagon; popravek, ki živi le v zgodovini vaše lupine, izgine ob prvem ponovnem zagonu.

Če je strežnik tudi oblačna instanca NAT, ima tudi platforma besedo. Instanca, ki prevaja naslove, običajno potrebuje izklopljeno preverjanje vira in cilja tam, kjer ponudnik to nastavitev ponuja, sam vrata VPN pa morajo biti dosegljiva od zunaj.

DNS je druga okvara za prvo

Ping po naslovu, ki deluje, medtem ko imena spodletijo, je težava razreševalnika, in ima svoj vzrok. Odjemalec, ki obdrži svoj krajevni razreševalnik, te poizvedbe pošlje v polni predor in čaka na odgovor, ki nikoli ne pride, ker je krajevni razreševalnik zdaj na napačni strani poti.

Potisnite razreševalnik s strežnika, da bo odjemalec vedel, kje vprašati. Dva vnosa dajeta odjemalcu rezervo, če prvi ni dosegljiv, in oba bi morala biti razreševalnika, ki jima predor resnično dovoli.

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

Odjemalci Windows lahko nato vseeno padejo nazaj na krajevni razreševalnik, in prav to naj bi block-outside-dns preprečil, za ceno izgube imen, ki jih zna razrešiti le krajevno omrežje. Odjemalci Linux s systemd-resolved pogosto prezrejo potisnjen razreševalnik, če ga skript ne namesti, zato pred zaključkom, da je bilo potiskanje prezrto, preverite resolvectl status za napravo predora.

Pot zaključite tako, kot jo doživi uporabnik. Naložite resnično stran z odjemalca, potrdite naslov, s katerega odide, znova zaženite strežnik, znova se povežite in ponovite tri preizkuse. Samo ta drugi krog dokazuje, da so shranjena pravila, požarna politika in potisnjen razreševalnik vsi skupaj preživeli.