OpenVPN redirect-gateway: ką kiekviena vėliava daro maršrutams

Prisijunkite su redirect-gateway profilyje, ir jūsų kompiuterio numatytasis maršrutas gali išnykti, suskilti į du arba likti tiksliai ten, kur buvo, priklausomai nuo vėliavų, kurių niekas neskaito du kartus. Parinktis keičia tik maršrutizavimo būseną ir nieko daugiau, todėl vienintelis patikimas įrodymas, ką ji padarė, yra lentelė, kurią klientas įdiegė po to. Toliau pateikiama lentelė po prisijungimo, maršrutas, kuris palaiko gyvą patį tunelį, ir IPv6 srautas, kurio direktyva niekada neteigia apimanti. Kiekvienas žingsnis yra komanda, kurią galite paleisti kliente, kol tunelis veikia.

Ką kiekviena vėliava daro numatytajam maršrutui

Be jokios vėliavos parinktis pašalina įprastą numatytąjį maršrutą ir į jo vietą įdeda tunelį, todėl senasis šliuzas išnyksta iš lentelės, kol ryšys veikia. Pridėkite def1 ir tas numatytasis lieka sąraše, o darbą atlieka du siauresni maršrutai. Pridėkite bypass-dhcp ir DHCP maršrutas taip pat išlieka, o tai svarbu tinkle, kuriame klientas dar turi pasiekti vietinį DHCP serverį. Vėliavų sąrašas OpenVPN 2.6 vadovo puslapyje pakankamai trumpas, kad būtų perskaitytas vieną kartą, ir kiekvienas įrašas keičia, kurie maršrutai patenka į lentelę.

Stumiama parinktis elgiasi taip pat, kai atvyksta, todėl kliento profilyje gali nieko nebti, o lentelė atrodo visiškai peradresuota. Tai normalu: serveris išsiuntė vėliavas, klientas jas pritaikė, o vietinis failas niekada nepaminėjo direktyvos. Kai stūmimas atrodo nieko nedarantis, patikrinkite kliento pusės filtrą, kuris priima arba atmeta ištrauktas parinktis, nes atmesta parinktis nesukelia klaidos nė vienoje pusėje.

def1 laimi specifiškumu neliesdamas jūsų numatytojo maršruto

Du pusiau numatytieji maršrutai kartu apima IPv4 erdvę, 0.0.0.0/1 ir 128.0.0.0/1. Kiekvienas yra konkretesnis už 0.0.0.0/0, todėl paieška teikia jiems pirmenybę, o tikrasis numatytasis lieka lentelėje viskam, kas prašo mažiausiai konkretaus atitikmens.

Skaitykite lentelę, o ne profilį, nes tik lentelė parodo, kuriuo iš tų atvejų esate. Dviejų eilučių pakanka jiems atskirti:

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

Atkreipkite dėmesį į sąsają ir metriką kiekvienoje eilutėje, ne tik į paskirties vietą. Numatytasis, nukreiptas į tunelį, ir pora pusiau numatytųjų, nukreiptų į tunelį, apibūdina tą patį ketinimą ir nepavyksta skirtingai, kai tunelis krenta, nes vienu atveju atsarginis kelias dar egzistuoja. Užrašykite abu laukus pakeitimo pastaboje. Išlikęs atsarginis kelias kartais palaiko nuotolinę sesiją pakankamai ilgai, kad būtų galima sutaisyti tunelį, ir jis taip pat nutekina srautą, kai ketinimas buvo visas tunelis.

Išlaikykite tunelio galinį tašką pasiekiamą

Klientui reikia maršruto į tolimą tunelio galą, kuris pats neina per tunelį. OpenVPN įdiegia tą prieglobos maršrutą prieš ką nors kita keisdamas, o rankinis maršruto keitimas ar antras VPN klientas gali jį pašalinti. Po to simptomas yra ryšys, kuris praneša esąs prisijungęs ir tada nieko nepraleidžia.

Paklauskite branduolio, kurią sąsają jis naudotų galinio taško adresui, kol tunelis veikia. Atsakyme turi būti nurodyta fizinė sąsaja ir jos šliuzas, niekada tun0:

ip route get 198.51.100.20

Jei ši paieška grąžina tunelio įrenginį, tunelis veža savo transportą ir sugrius, kai tik paketui reikės išeiti. Vietiniai prefiksai, antras adapteris ir politikos pagrindu veikiantis maršrutizavimas čia vis dar svarbūs, todėl peradresavimas, veikiantis švariame nešiojamajame, gali nepavykti pagrindiniame kompiuteryje su valdymo sąsaja ir dviem numatytaisiais. Paprastai kaltinamas profilis dėl to, ką padarė adresų planas.

IPv6 srautas ir toliau naudoja savo lentelę

IPv4 peradresavimas palieka IPv6 ramybėje, o abi šeimos keičiamos skirtingomis vėliavomis. Dvejopo kamino kompiuteryje su veikiančiu v6 numatytuoju maršrutu v4 srautas gali visiškai sėdėti tunelio viduje, o kiekviena v6 galinti paskirties vieta išeina fizine jungtimi. Kompiuteris, kuris vienoje lentelėje atrodo teisingai, kitoje nutekina.

Po prisijungimo patikrinkite v6 lentelę, o ne manykite, kad tunelis ją apėmė. Direktyva neša adresų šeimos vėliavas būtent dėl šios priežasties, o profilis, kuris jų neįrašo, paveldi tai, ką platforma daro pagal numatytuosius nustatymus:

ip -6 route show default
ip -6 route get 2001:db8::10

Įrodykite, kurią sąsają naudoja programa

Prisijungusi būsena nėra blokavimas, o maršruto pakeitimas nėra avarinis jungiklis. Jei tiesioginis srautas turi sustoti, kai tunelis sugenda, ta politika gyvena ugniasienėje ir jai reikia atskiro bandymo.

Bandykite kelią, kurį programa iš tikrųjų nueina, o ne kelią, kurį aprašo profilis. Pirmiausia paklauskite maršruto, tada pakaitomis susiekite užklausą su kiekviena sąsaja ir palyginkite, ką praneša tolimoji pusė:

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

Jei abi užklausos grąžina tą patį adresą, programa nenaudoja tunelio, nors maršrutizavimo lentelė sako, kad turėtų. Jei pavyksta tik su tuneliu susieta užklausa, fizinis kelias šiai paskirčiai filtruojamas ir tunelis daro tai, ko paprašėte. Įrašykite vėliavas, įdiegtus maršrutus, galinio taško paiešką ir abu išėjimo rezultatus į pakeitimų žurnalą, kad kitas žmogus paveldėtų faktus, o ne ekrano kopiją.