OpenVPN redirect-gateway: wat elke vlag aan die roetes doen

Maak verbinding met redirect-gateway in die profiel, en jou masjien se standaardroete kan verdwyn, in twee verdeel, of presies bly waar dit was, afhangend van vlae wat niemand twee keer lees nie. Die opsie verander net die routeringstoestand en niks anders nie, so die enigste betroubare bewys van wat dit gedoen het, is die tabel wat die kliënt daarna geïnstalleer het. Wat volg, is die tabel ná 'n verbinding, die roete wat die tonnel self lewendig hou, en die IPv6-verkeer wat die richtlijn nooit beweer dit dek nie. Elke stap is 'n opdrag wat jy op die kliënt kan uitvoer terwyl die tonnel aan is.

Wat elke vlag aan die standaardroete doen

Sonder enige vlag verwyder die opsie die gewone standaardroete en plaas die tonnel in sy plek, so die ou poort verdwyn uit die tabel terwyl die verbinding aan is. Voeg def1 by en daardie standaard bly gelys, met twee nouer roetes wat die werk eerder doen. Voeg bypass-dhcp by en die DHCP-roete oorleef ook, wat saak maak op 'n netwerk waar die kliënt nog die plaaslike DHCP-bediener moet bereik. Die vlaglys op die OpenVPN 2.6-handleidingblad is kort genoeg om een keer te lees, en elke inskrywing verander watter roetes uiteindelik in die tabel beland.

'n Gepusde opsie gedra hom dieselfde sodra dit aankom, so die kliëntprofiel kan glad niks bevat nie terwyl die tabel heeltemal omgelei lyk. Dit is normaal: die bediener het die vlae gestuur, die kliënt het dit toegepas, en die plaaslike lêer het nooit die richtlijn genoem nie. Wanneer 'n pus niks blyk te doen nie, kontroleer die kliëntkant-filter wat opgetrekte opsies aanvaar of verwerp, want 'n verworpe opsie lewer aan geen van die twee kante 'n fout nie.

def1 wen deur spesifisiteit sonder om aan jou standaard te raak

Twee half-standaardroetes dek saam die IPv4-ruimte, 0.0.0.0/1 en 128.0.0.0/1. Elkeen is meer spesifiek as 0.0.0.0/0, so 'n opsoek verkies hulle terwyl die werklike standaard in die tabel bly vir enigiets wat die mins spesifieke passing vra.

Lees die tabel eerder as die profiel, want net die tabel wys in watter van daardie gevalle jy is. Twee reëls is genoeg om hulle te onderskei:

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

Let op die koppelvlak en die maatstaf op elke reël, nie net die bestemming nie. 'n Standaard wat na die tonnel wys en 'n paar half-standaarde wat na die tonnel wys, beskryf dieselfde bedoeling en faal anders wanneer die tonnel val, want die terugval bestaan in een geval nog. Teken albei velde in die veranderingsnota aan. 'n Oorlewende terugval is soms wat 'n afgeleë sessie lank genoeg aan die lewe hou om die tonnel te herstel, en dit is ook wat verkeer lek wanneer die bedoeling 'n vol tonnel was.

Hou die tonnel se eindpunt bereikbaar

Die kliënt het 'n roete na die verre kant van die tonnel nodig wat nie self deur die tonnel loop nie. OpenVPN installeer daardie gasheerroete voordat dit enigiets anders verander, en 'n handmatige roetewysiging of 'n tweede VPN-kliënt kan dit wegneem. Die simptoom daarna is 'n verbinding wat sê dit is verbind en dan niks deurlaat nie.

Vra die kernel watter koppelvlak dit vir die eindpuntadres sou gebruik terwyl die tonnel aan is. Die antwoord moet die fisiese koppelvlak en sy poort noem, nooit tun0 nie:

ip route get 198.51.100.20

As daardie opsoek die tonneltoestel teruggee, dra die tonnel sy eie vervoer en sal dit ineenstort sodra 'n pakkie moet uitgaan. Plaaslike voorvoegsels, 'n tweede adapter en beleidsroutering maak hier nog saak, en daarom kan 'n omleiding wat op 'n skoon skootrekenaar werk, faal op 'n gasheer met 'n bestuurskoppelvlak en twee standaarde. Die profiel kry gewoonlik die skuld vir wat die adresplan gedoen het.

IPv6-verkeer bly sy eie tabel gebruik

Om IPv4 om te lei laat IPv6 alleen, en die twee families word deur verskillende vlae verander. Op 'n dubbelstapel-gasheer met 'n werkende v6-standaard kan v4-verkeer heeltemal binne die tonnel sit terwyl elke v6-geskikte bestemming oor die fisiese skakel uitgaan. 'n Gasheer wat in een tabel reg lyk, lek in die ander.

Kontroleer die v6-tabel ná die verbinding in plaas daarvan om aan te neem die tonnel het dit gedek. Die richtlijn dra adresfamilie-vlae juis om hierdie rede, en 'n profiel wat hulle weglaat, erf wat die platform by verstek doen:

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

Bewys watter koppelvlak 'n toepassing gebruik

'n Verbinde toestand is nie 'n blok nie, en 'n roeteverandering is nie 'n doodskakelaar nie. As direkte verkeer moet stop wanneer die tonnel faal, woon daardie beleid in die vuurmuur en het dit sy eie toets nodig.

Toets die pad wat 'n toepassing werklik volg eerder as die pad wat die profiel beskryf. Vra eers die roete, en bind dan 'n versoek om die beurt aan elke koppelvlak en vergelyk wat die verre kant rapporteer:

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

As albei versoeke dieselfde adres teruggee, gebruik die toepassing nie die tonnel nie, al sê die routeringstabel dat dit moet. As net die versoek wat aan die tonnel gebind is, slaag, word die fisiese pad vir daardie bestemming gefiltreer en doen die tonnel wat jy gevra het. Skryf die vlae, die geïnstalleerde roetes, die eindpuntopsoek en albei uitgangsresultate in die veranderingsrekord, sodat die volgende persoon feite erf in plaas van 'n skermkiekie.