Avalik prefiks läbi OpenVPN-i: paranda tagasitee

Vaata, kuidas tunnel tõuseb ja klient pingib vastaskülge, ning siis vastab avalik aadress, mis kuulub VPN-i taha, kuskilt mujalt või üldse mitte. See sümptom ei ole tavaliselt šifri ega sertifikaatidega mingis seoses. Pakkuja marsruuditud prefiks tarnitakse IP-marsruudina, ja selle läbi OpenVPN kandmine tähendab selle marsruudi kahes kihis taasesitamist ja lähteaadressi säilitamist tagasiteel. WAN-i sillutamine ei ole vajalik, ja aadressi liidesele lisamine ei loo ülemist marsruuti.

Prefiks tuleb esmalt teie poole marsruutida

Küsi pakkujalt, kuidas plokk tarnitakse. Prefiks, mis on marsruuditud sinu serveri põhiaadressile, on hoopis muu asi kui aadressid, mida pakkuja loodab WAN-segmendil otse kätte saada. Siin kirjeldatud lahendusega töötab ainult esimene mudel.

Kui pakkuja marsruudib 198.51.100.64/28 sinu sissepääsuseverile, saabuvad selle vahemiku paketid serverile ja jäävad sinna seisma, kui te neid edasi ei edasta. Kui pakkuja sillutab vahemiku hoopis sinu ülesvoolu liidesele, peab server selle jaoks ARP-ile vastama, mis on hoopis teine probleem.

Testi tarnemudelit enne, kui OpenVPN-i puudutad: pingi väljastpoolt mõnda ploki aadressi ja vaata, milline liides selle vastu võtab. Kui midagi ei saabu, ei aita ükski tunnelikonfiguratsioon. Kui aadress vastab otse WAN-il, sillutab pakkuja, mitte ei marsruudi, ja allpool kirjeldatud lahendus ei kehti.

Kaks marsruutimistasandit: tuuma marsruut ja iroute

OpenVPN vajab prefiksit kahes kohas. Tuum peab teadma, et prefiks kuulub tunneliseadmele, et edasisaadetud paketid siseneksid OpenVPN-i, mitte vaikemarsruudile. OpenVPN peab ka teadma, milline autenditud klient prefiksi omanik on, ja see on iroute-kirje kliendipõhises kataloogis.

Serveripoolne marsruut näeb välja selline, kusjuures prefiks ja mask peavad vastama eraldisele:

ip route add 198.51.100.64/28 dev tun0

Kliendipõhine konfiguratsioon määrab omanduse. Pane see CCD-faili, mis on nimetatud kliendi sertifikaadi üldnime järgi, ja kinnita, et just seda kataloogi server tegelikult loeb:

iroute 198.51.100.64 255.255.255.240

OpenVPN-i marsruuditud võrkude dokumentatsioon kirjeldab mõlemat tasandit ja seda, miks need on eraldi. Tuuma marsruut ilma iroute'ta saadab paketid tunnelisse ilma omanikuta ja OpenVPN viskab need ära. iroute ilma tuuma marsruudita jätab paketid serveri vaiketeekonnale. Mõlemad vead näevad kliendi poolelt välja nagu katkine tunnel.

Kus teenuse aadress asub

Delegeeritud prefiks ei ole sama asi kui tunneli enda aadressid. Nummerda lüli soovi korral privaatruumist ja paiguta avalik teenuseaadress sinna, kus teenus tegelikult töötab.

Linuxi kliendil, mis teenuse kohapeal lõpetab, piisab ühest hosti aadressist:

ip address add 198.51.100.70/32 dev lo

Kui prefiks marsruuditakse edasi VM-hostile või teise LAN-i, seadista selle asemel see allavoolu tee ja selle tagasimarsruut. Ploki iga aadressi VPN-kliendile määramine ei ole vajalik ja tekitab hiljem konflikte.

Hoia avalik lähteaadress tagasiteel

Vastus delegeeritud prefiksist peab tunnelist väljuma ja jõudma pakkuja marsruudini. Kui kaugem host saadab selle oma ISP kaudu, näeb lähteaadress võltsitud välja ja pakkuja või sihtkoht viskab selle ära. Lahendus on lähtepõhine reegel või eraldi marsruutimistabel, mitte laiem NAT. Ilma selleta töötab teenus tunneli partneri juurest ja ebaõnnestub kõikjal mujal.

Sissepääsuservers on lai masquerade-reegel tavaline süüdlane. See kirjutab avaliku lähteaadressi ümber serveri põhiaadressiks ja klient ei näe kunagi õiget:

iptables -t nat -S POSTROUTING

Piira NAT ainult nende privaatsete VPN-klientidega, kes seda vajavad, ja jäta delegeeritud prefiks tõlkimata. Seejärel kinnita, et server üldse edastab prefiksit, sest vaikimisi keelava edastusahela puhul visatakse see vaikselt ära.

Kontrolli mõlemat suunda enne, kui usaldad

Kontroll koosneb neljast vaatlusest, mitte ühest. Kinnita, et pakkuja marsruut saabub, tuum saadab prefiksi tunnelisse, OpenVPN omistab selle õigele kliendile ja vastus naaseb avaliku lähteaadressiga puutumatult. Igal vaatlusel on oma käsk, nii et tõrge osutab kihile, mitte kogu lahendusele. Käivita need selles järjekorras pärast igat konfiguratsioonimuudatust.

Küsi tuumalt, millist teed delegeeritud aadress võtab, ja vaatle tunnelit päringu ajal:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Vastassuuna filtreerimine võib õige marsruudi tühistada. Kontrolli kehtivat seadet tunnelil ja ülesvoolu liidesel ning pea meeles, et range režiim lükkab tagasi liikluse, mille lähteaadress ei vasta liidesele, millelt see saabus:

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

Lõpuks testi tõrkejuhtu. Peata tunnel ja kinnita, et avalik prefiks ei leki tavalise ülesvoolu liidese kaudu. VPN-i taastamine peaks teenuse tagasi tooma, laiendamata portisid, mida host avab.