route-gateway nėra redirect-gateway: kas iš tikrųjų keičiasi
Ši parinktis tik suteikia kitą šuolį maršrutams, kuriuos įdiegia OpenVPN. Jos pašalinimas neišjungia stumto viso tunelio, o pataisa priklauso peradresavimui.
Jūsų tunelis pakyla, privatus potinklis atsako, o įprastas naršymas vis tiek dingsta VPN viduje, nors kažkas ištrynė šliuzo eilutę iš profilio. Šis derinys yra neteisingos direktyvos redagavimo pirštų atspaudas. Pašalinta dalis klientui davė kitą šuolį maršrutams, kuriuos jis įdiegia; tai, kas toliau gaudė srautą, atėjo iš kitur ir buvo stumta serverio. Aprėptis ir kitas šuolis yra atskiri darbai, ir tik vienas jų nusprendžia, ar viešos paskirties vietos naudoja tunelį.
Pašalinta eilutė buvo kitas šuolis, o ne politikos jungiklis
Kiekvienam maršrutui, kurį įdiegia klientas, reikia šliuzo adreso, į kurį būtų galima nukreipti, o šliuzo direktyva yra to adreso šaltinis, kai maršrutas pats jo nenurodo. Ištrinkite ją ir tie maršrutai neturės prie ko prisitvirtinti, todėl jie arba nebus įdiegti, arba atsidurs kelyje, kuris niekur neveda. Privatus potinklis yra būtent tai, ką toks maršrutas nešė.
Tuo tarpu išlikęs elgesys turi kitą autorių: peradresavimo parinktis stumtame bloke, kuri pagal savo vėliavėles perkelia įprastą išeinantį srautą į tunelį. Šliuzo pašalinimas to neišjungia, nei susilpnina. Rezultatas yra blogiausia iš abiejų būsenų: viešas srautas vis dar gaudomas, o privati paskirtis, kuri pateisino tunelį, dabar nepasiekiama. Todėl ir antrasis pakeitimas, atliktas ta pačia dvasia, nieko nekeičia.
Keturi svertai, keturi skirtingi darbai
Šioje diskusijoje keturios direktyvos cituojamos pakaitomis, ir tik viena jų valdo aprėptį, tai yra kurios paskirties vietos apskritai eina per tunelį. Antroji nustato kitą šuolį, kurį naudoja maršrutai, trečioji įdiegia vieną priešdėlį, o ketvirtoji išmeta viską, ką stūmė serveris, įskaitant privačius maršrutus, kurių reikia diegimui. Lentelė juos rikiuoja pagal tai, ką administratorius bando pakeisti, o ne pagal pavadinimą, nes būtent pavadinimai ir sukelia sumaištį. Traktuokite juos kaip keturis atskirus sprendimus ir pasirinkite tą, kurį tikrai norite atšaukti.
Praktiškai visi keturi dažnai atkeliauja viename stumtame bloke, eilutė po eilutės, todėl atrodo kaip vienos nuostatos dalys. Tai ne, ir OpenVPN žinynas būtent todėl dokumentuoja juos kaip skirtingus mechanizmus. Išsiaiškinti, kurį sprendimą atšaukiate, yra darbas; pakeitimas yra viena eilutė.
| What you are trying to change | Directive that decides it | What it leaves alone |
|---|---|---|
| Which destinations use the tunnel | redirect-gateway | Per-prefix routes and resolver choice |
| The next hop a pushed route points at | route-gateway | Coverage of public destinations |
| One reachable prefix | route | Every other destination, default path included |
| All pushed routing and DNS at once | route-nopull | Nothing, which is the problem |
Filtruokite stumtą eilutę, palikite kitą šuolį
Jei aprėptis, kuriai prieštaraujate, ateina kaip stumta parinktis, siauras atsakymas yra ignoruoti tą parinktį pagal pavadinimą ir palikti likusį stumtą bloką nepaliestą. Parašyta kaip filtras, ji atrodo kaip žemiau esanti eilutė, ir jai vieta yra paveikto kliento profilyje, o ne serverio konfigūracijoje.
pull-filter ignore "redirect-gateway"Siaurumas ir yra esmė. Kadangi filtras lygina teksto priešdėlį, trumpesnis šablonas atitinka ir kito šuolio direktyvą, o tai nurengia būtent tą informaciją, nuo kurios priklauso privatūs maršrutai, ir pakartoja pradinę klaidą nauju pavidalu. Filtras taip pat veikia tik stumtas parinktis, todėl niekada neliečia lygiavertės eilutės, parašytos vietoje ar primestos tinklo tvarkyklės. Po to prisijunkite iš naujo, nes gyva sesija iš naujo neįvertina to, ką stūmė serveris.
Skaitykite paiešką, o ne lentelę
Persikrovę profilį, paklauskite branduolio, kur iš tikrųjų keliautų dvi paskirties vietos: viena privačiojo priešdėlio viduje, kita viešajame internete. Viso pagrindinės lentelės išdėstymo sunkiau skaityti ir lengviau perskaityti neteisingai, nes maršrutas gali egzistuoti ir vis tiek pralaimėti tikslesniam atitikimui. Maršrutizavimo pagal politiką atveju taisyklė, lentelė ir šaltinio adresas taip pat priklauso patikrai.
ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule showdef1 variantas vertas pažinties, nes palieka seną numatytąjį įrašą matomą, kol pora pusiau numatytųjų laimi paiešką. Todėl 0.0.0.0/0 eilutė išvestyje pati savaime nieko neįrodo. Paieška atsako į klausimą, į kurį sąrašas tik atrodo atsakantis.
DNS, IPv6 ir privatus maršrutas vis dar turi veikti
Vieno IPv4 peradresavimo atmetimas nieko nesako apie sprendėją, todėl stumta DNS parinktis gali toliau siųsti užklausas į tunelį, kol maršrutai atrodo teisingi. IPv6 numatytasis gali padaryti tą patį adresų šeimai, kurios IPv4 patikra niekada nelietė. Abu reikalauja aiškaus sprendimo, o ne prielaidos. Tada patvirtinkite, kad privati paslauga vis dar atsako, nes bendras tunelis, praradęs savo privatų maršrutą, nėra bendras tunelis, jis yra sulaužytas.
Vienas platesnis įrankis vertas įspėjimo: route-nopull išmeta kiekvieną stumtą maršrutą ir kiekvieną stumtą DNS parinktį, o tai tikrai sustabdo visą tunelį ir lygiai taip pat tikrai sugadina privačius maršrutus, nuo kurių priklauso diegimas, todėl tai yra daug didesnis kūjis nei pavadinimo filtras, nukreiptas į vieną parinktį. Po bet kurio pakeitimo patikrinkite privačią paskirtį, viešą paskirtį ir sprendėją, o užbaigtą rankos paspaudimą laikykite nieko kito, tik rankos paspaudimo, įrodymu.