Javna predpona skozi OpenVPN: popravite povratno pot

Opazujte, kako tunel vstane in odjemalec pinga drugo stran, nato pa javni naslov, ki pripada za VPN, odgovori od drugod, ali pa sploh ne. Ta simptom običajno nima nič skupnega s šifro ali s certifikati. Predpona, ki jo usmerja ponudnik, se dostavi kot pot IP, in prenašanje čez OpenVPN pomeni poustvariti to pot na dveh ravneh in ohraniti izvorni naslov na povratni poti. Premostitev WAN ni potrebna, in dodajanje naslova na vmesnik ne ustvari nadrejene poti.

Predpona mora biti najprej usmerjena k vam

Vprašajte ponudnika, kako se blok dostavi. Predpona, usmerjena na glavni naslov vašega strežnika, je nekaj drugega kot naslovi, ki jih ponudnik pričakuje doseči neposredno na segmentu WAN. S to zasnovo deluje samo prvi model.

Če ponudnik usmeri 198.51.100.64/28 na vaš vstopni strežnik, paketi za to območje prispejo na strežnik in se tam ustavijo, razen če jih posredujete. Če ponudnik območje namesto tega premosti na vaš uplink, mora strežnik odgovoriti na ARP zanj, kar je druga težava.

Preizkusite model dostave, preden se dotaknete OpenVPN: od zunaj pingajte naslov v bloku in poglejte, kateri vmesnik ga sprejme. Če ne pride nič, nobena konfiguracija tunela ne bo pomagala. Če naslov odgovori neposredno na WAN, ponudnik premosti namesto usmerja, in spodnja zasnova ne velja.

Dve ravni usmerjanja: pot v jedru in iroute

OpenVPN potrebuje predpono na dveh mestih. Jedro mora vedeti, da predpona pripada tunelski napravi, da posredovani paketi vstopijo v OpenVPN namesto v privzeto pot. OpenVPN mora tudi vedeti, kateri overjeni odjemalec ima predpono, in to je vnos iroute v imeniku, specifičnem za odjemalca.

Pot na strani strežnika je videti takole, pri čemer se morata predpona in maska ujemati z dodelitvijo:

ip route add 198.51.100.64/28 dev tun0

Konfiguracija, specifična za odjemalca, dodeli lastništvo. Vstavite jo v datoteko CCD, poimenovano po splošnem imenu odjemalčevega potrdila, in potrdite, da je ta imenik tisti, ki ga strežnik dejansko bere:

iroute 198.51.100.64 255.255.255.240

Dokumentacija OpenVPN o usmerjenih omrežjih opisuje obe ravni in zakaj sta ločeni. Pot v jedru brez iroute pošilja pakete v tunel brez lastnika, in OpenVPN jih zavrže. iroute brez poti v jedru pusti pakete na privzeti poti strežnika. Obe napaki sta z odjemalčeve strani videti kot pokvarjen tunel.

Kje živi naslov storitve

Delegirana predpona ni isto kot lastni naslovi tunela. Povezavo oštevilčite iz zasebnega prostora, če želite, in javni naslov storitve postavite tja, kjer storitev dejansko teče.

Na odjemalcu Linux, ki storitev zaključi lokalno, zadošča en naslov gostitelja:

ip address add 198.51.100.70/32 dev lo

Če se predpona usmerja naprej na gostitelja VM ali drugo omrežje LAN, namesto tega konfigurirajte to pot navzdol in njeno povratno pot. Dodeljevanje vsakega naslova v bloku odjemalcu VPN ni potrebno in pozneje ustvari konflikte.

Ohranite javni izvor na povratni poti

Odgovor iz delegirane predpone mora zapustiti tunel in doseči pot ponudnika. Če ga oddaljeni gostitelj pošlje prek lastnega ISP, je izvorni naslov videti ponarejen, in ponudnik ali cilj ga zavrže. Rešitev je pravilo, ki temelji na izvoru, ali namenska usmerjevalna tabela, ne širši NAT. Brez nje storitev deluje od partnerja tunela in odpove povsod drugod.

Na vstopnem strežniku je široko pravilo masquerade običajni krivec. Prepisuje javni izvor na glavni naslov strežnika, in odjemalec nikoli ne vidi pravega:

iptables -t nat -S POSTROUTING

Omejite NAT na zasebne odjemalce VPN, ki ga potrebujejo, in delegirano predpono pustite neprevedeno. Nato potrdite, da strežnik predpono sploh posreduje, saj posredovalna veriga s privzeto zavrnitvijo tiho zavrže.

Preverite obe smeri, preden mu zaupate

Preverjanje so štiri opažanja, ne eno. Potrdite, da pot ponudnika prispe, jedro pošlje predpono v tunel, OpenVPN jo pripiše pravemu odjemalcu in odgovor se vrne z nepoškodovanim javnim izvorom. Vsako opažanje ima svoj ukaz, zato napaka kaže na plast, ne na celotno zasnovo. Izvajajte jih v tem vrstnem redu po vsaki spremembi konfiguracije.

Vprašajte jedro, katero pot vzame delegirani naslov, in opazujte tunel, medtem ko teče zahteva:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Filtriranje povratne poti lahko razveljavi pravilno pot. Preverite dejansko nastavitev na tunelu in na uplinku, in zapomnite si, da strogi način zavrne promet, katerega izvor se ne ujema z vmesnikom, po katerem je prispel:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

Nazadnje preizkusite primer okvare. Ustavite tunel in potrdite, da javna predpona ne uhaja po običajnem uplinku. Obnovitev VPN bi morala vrniti storitev, ne da bi razširila, katere vrata gostitelj izpostavi.