Viešasis prefiksas per OpenVPN: pataisyti grįžtamąjį kelią

Stebėkite, kaip tunelis pakyla ir klientas pingina kitą pusę, o tada viešasis adresas, priklausantis už VPN, atsako iš kitur arba visai neatsako. Šis simptomas paprastai neturi nieko bendra su šifru ar sertifikatais. Teikėjo maršrutizuotas prefiksas pristatomas kaip IP maršrutas, o pernešti jį per OpenVPN reiškia atkurti tą maršrutą dviem lygmenimis ir išsaugoti šaltinio adresą grįžtamajame kelyje. WAN tiltu daryti nereikia, o adreso pridėjimas prie sąsajos nesukuria viršutinio maršruto.

Prefiksas pirmiausia turi būti maršrutizuotas jums

Paklauskite teikėjo, kaip pristatomas blokas. Prefiksas, maršrutizuotas į pagrindinį jūsų serverio adresą, yra kas kita nei adresai, kuriuos teikėjas tikisi pasiekti tiesiogiai WAN segmente. Su čia aprašytu dizainu veikia tik pirmasis modelis.

Jei teikėjas maršrutizuoja 198.51.100.64/28 į jūsų įėjimo serverį, to diapazono paketai atkeliauja į serverį ir ten sustoja, nebent juos persiunčiate. Jei teikėjas vietoj to tiltu sujungia diapazoną su jūsų uplink, serveris turi atsakyti į ARP už jį, o tai kita problema.

Išbandykite pristatymo modelį prieš liesdami OpenVPN: iš išorės pinginkite adresą bloke ir stebėkite, kuri sąsaja jį priima. Jei nieko neatkeliauja, jokia tunelio konfigūracija nepadės. Jei adresas atsako tiesiogiai WAN tinkle, teikėjas tiltu jungia, o ne maršrutizuoja, ir toliau aprašytas dizainas netaikomas.

Du maršrutizavimo lygmenys: branduolio maršrutas ir iroute

OpenVPN reikia prefikso dviejose vietose. Branduolys turi žinoti, kad prefiksas priklauso tunelio įrenginiui, kad persiunčiami paketai patektų į OpenVPN, o ne į numatytąjį maršrutą. OpenVPN taip pat turi žinoti, kuris autentifikuotas klientas valdo prefiksą, ir tai yra iroute įrašas klientui skiriamame kataloge.

Serverio pusės maršrutas atrodo taip, o prefiksas ir kaukė turi atitikti paskirstymą:

ip route add 198.51.100.64/28 dev tun0

Klientui skiriama konfigūracija priskiria nuosavybę. Įdėkite ją į CCD failą, pavadintą pagal kliento sertifikato bendrąjį vardą, ir patvirtinkite, kad būtent tą katalogą serveris iš tikrųjų skaito:

iroute 198.51.100.64 255.255.255.240

OpenVPN dokumentacija apie maršrutizuotus tinklus aprašo abu lygmenis ir kodėl jie atskirti. Branduolio maršrutas be iroute siunčia paketus į tunelį be savininko, ir OpenVPN juos meta. iroute be branduolio maršruto palieka paketus numatytajame serverio kelyje. Abi klaidos iš kliento pusės atrodo kaip sulaužytas tunelis.

Kur gyvena paslaugos adresas

Deleguotas prefiksas nėra tas pats kaip paties tunelio adresai. Jei norite, numeruokite jungtį iš privačios erdvės ir padėkite viešąjį paslaugos adresą ten, kur paslauga iš tikrųjų veikia.

Linux kliente, kuris paslaugą užbaigia vietoje, pakanka vieno hosto adreso:

ip address add 198.51.100.70/32 dev lo

Jei prefiksas toliau maršrutizuojamas į VM hostą ar kitą LAN, vietoj to sukonfigūruokite tą pasroviui einantį kelią ir jo grįžtamąjį maršrutą. Kiekvieno adreso bloke priskyrimas VPN klientui nereikalingas ir vėliau sukelia konfliktus.

Išsaugokite viešąjį šaltinį grįžtamajame kelyje

Atsakymas iš deleguoto prefikso turi išeiti per tunelį ir pasiekti teikėjo maršrutą. Jei nuotolinis hostas jį siunčia per savo ISP, šaltinio adresas atrodo suklastotas, o teikėjas ar paskirties vieta jį meta. Sprendimas yra taisyklė, pagrįsta šaltiniu, arba atskira maršrutizavimo lentelė, o ne platesnis NAT. Be jo paslauga veikia iš tunelio partnerio ir nepavyksta visur kitur.

Įėjimo serveryje plati masquerade taisyklė yra įprastas kaltininkas. Ji perrašo viešąjį šaltinį į pagrindinį serverio adresą, o klientas niekada nemato tikrojo:

iptables -t nat -S POSTROUTING

Apribokite NAT tiems privatiems VPN klientams, kuriems jo reikia, ir palikite deleguotą prefiksą neišverstą. Tada patvirtinkite, kad serveris apskritai persiunčia prefiksą, nes persiuntimo grandinė su numatytuoju draudimu jį tyliai meta.

Patikrinkite abi kryptis prieš juo pasitikėdami

Patikra yra keturi stebėjimai, o ne vienas. Patvirtinkite, kad atkeliauja teikėjo maršrutas, branduolys siunčia prefiksą į tunelį, OpenVPN jį priskiria tinkamam klientui, o atsakymas grįžta su nepažeistu viešuoju šaltiniu. Kiekvienas stebėjimas turi savo komandą, todėl gedimas nurodo sluoksnį, o ne visą dizainą. Vykdykite juos šia tvarka po kiekvieno konfigūracijos pakeitimo.

Paklauskite branduolio, kokį kelią pasirenka deleguotas adresas, ir stebėkite tunelį, kol vyksta užklausa:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Atvirkštinio kelio filtravimas gali panaikinti teisingą maršrutą. Patikrinkite efektyvų nustatymą tunelyje ir uplink, ir atminkite, kad griežtas režimas atmeta srautą, kurio šaltinis neatitinka sąsajos, per kurią jis atkeliavo:

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

Galiausiai išbandykite gedimo atvejį. Sustabdykite tunelį ir patvirtinkite, kad viešasis prefiksas neprateka per įprastą uplink. VPN atkūrimas turėtų grąžinti paslaugą nepadidinus, kuriuos portus hostas atidaro.