Hvers vegna brýtur önnur VPN-göngin þau fyrstu?

Að setja upp annan VPN-biðlara til að ná einu viðskiptavina-neti er venjulega leiðin sem þetta byrjar á, og fyrstu göngin verða dimm á meðan báðir biðlarar tilkynna árangur. Sérhver biðlari setti upp sjálfgefna leið, önnur var nákvæmari, og kjarninn fylgir henni nú fyrir allt nema eigin ytri tengingu fyrstu gagnanna. Ekkert hrundi og ekkert snið er rangt. Ein leið kom í stað annarrar, og lausnin er að ákveða hvaða göng eiga að eiga sjálfgefnu leiðina.

Einkennið: seinni biðlarinn vinnur hljóðlega

OpenVPN: valkosturinn redirect-gateway def1 skrifar ekki yfir 0.0.0.0/0. Hann bætir við 0.0.0.0/1 og 128.0.0.0/1: saman þekja þær hvert IPv4-vistfang, og hvert forskeyti vinnur venjulega sjálfgefna leið að lengd. Upprunalega sjálfgefna leiðin verður áfram í töflunni og er ekki lengur notuð fyrir venjulega umferð, og hýsil-leið að VPN-þjóninum kemur í veg fyrir að göngin grípi eigin ytri pakka. Báðir biðlarar gera þetta, og seinni setur einfaldlega upp parið sitt síðar.

Þess vegna virðast fyrstu göngin dauð frekar en aftengd. Viðmótið er uppi, stjórnrásin lifir, og engin forritsumferð nær til þeirra lengur. Öfug kvörtunin á sér sama skort á push: sími sem tengist en sendir ekkert talar venjulega við þjón sem aldrei tilkynnti redirect-gateway, svo tækið heldur sínum eigin sjálfgefna og nær aðeins í laugina.

Taktu leiðarmynd fyrir og eftir að seinni biðlarinn tengist. Tvær hálfleðir sem birtast í töflunni eru öll breytingin, og þær útskýra báðar kvartanirnar. Ekkert annað í töflunni þarf að hreyfast til að einkennið birtist. Þess vegna endurheimtir það fyrstu göngin samstundis að fjarlægja seinni biðlarann.

Lestu hvaða göng vinna í raun

Ekki álykta sigurvegara af röðinni sem biðlararnir byrjuðu í né af tákni í kerfisbakkanum. Spurðu kjarnann hvaða leið hann myndi nota fyrir áfangastað utan beggja einkanetanna, og lestu viðmótið sem kemur til baka.

ip route show
ip route get 198.51.100.24
route print -4
Find-NetRoute -RemoteIPAddress 198.51.100.24

Fyrstu tvö eru Linux-svarið og síðustu tvö Windows-jafngildið. Keyrðu þau á meðan bæði göngin eru uppi, aftengdu svo annað og keyrðu þau aftur. Munurinn á tveimur úttökunum er staðreyndin sem þú þarft áður en þú velur lausn, og það tekur skemmri tíma en að lesa annál annars hvors biðlarans.

Skráðu niðurstöðuna, þar á meðal viðmótsnafn og forskeytið sem passaði. Miði sem segir að seinni VPN hafi brotið þau fyrstu er lýsing á einkenninu, ekki leiðaryrðing sem nokkur getur unnið eftir. Uppflettingin gerir hana að staðreynd sem næsti verkfræðingur getur endurtekið með einni skipun.

Windows: komdu í veg fyrir að eitt snið eigi sjálfgefnu leiðina

Windows geymir vistuð snið, og innbyggði biðlarinn leyfir einu að ráðast af öðru svo það fyrsta komi upp sjálfkrafa þegar annað hringir. Sniðið sem tengdist síðast hefur tilhneigingu til að halda sjálfgefnu leiðinni, svo hagnýti eigandinn er síðasta hringingin frekar en sú fyrsta. Gefðu hverju sniði eigin push-leiðir og kveiktu á split tunneling fyrir það sem á ekki að eiga sjálfgefnu leiðina.

Set-VpnConnection -Name "Contoso" -SplitTunneling $true
rasdial Contoso

Split tunneling breytir þessu: aðeins forskeyti sem þjónninn ýtir lenda í töflunni, sem lætur fyrstu göngin halda sjálfgefnu leiðinni. Hönnunin mistekst samt ef báðir þjónar ýta sjálfgefinni leið, því þá vinnur síðasta tengingin og engin stilling á biðlarahlið breytir því. Lagaðu push á þjónahlið eða sættu þig við einn eiganda.

Snið sem forrit kveikja á eru annar eiginleiki og vert að þekkja: Windows-snið getur byrjað þegar nefnd keyrsluskrá ræsist, og umferðarsíur ákveða hvað það ber. Þetta er sniðsstilling en ekki eldveggjarregla, og leysir annað vandamál en átök sjálfgefnu leiðarinnar.

Linux: haltu seinni göngunum utan aðaltöflunnar

Að keyra tvö openvpn --config-tilvik á einni vél setur báða biðlara í sömu töflu, og þrír valkostir aðskilja þá með vaxandi einangrun. Léttasti er að stöðva seinni biðlarann alfarið frá því að breyta töflunni, með route-nopull og skýrum leiðum, eða route-up skriftu sem setur upp aðeins það sem þú ætlar. Þá ber seinni göngin nákvæmlega þau forskeyti sem þú nefnir og ekkert annað. Þá ákveður þú hvaða forskeyti fara hvert í stað þess að uppgötva það síðar.

Stefnuleiðsla er millivalkosturinn. Regla velur sér töflu fyrir eitt upprunavistfang eða eldveggjarmerki, og sú tafla ber leiðir seinni gagnanna. Andhverf leiðarsía er gildran hér, því svar sem kemur á annað viðmót en taflan myndi velja er hent, svo athugaðu stillinguna rp_filter áður en þú ályktar að göngin séu brotin.

ip rule add from 10.44.7.0/24 table 100
ip route add default dev tun1 table 100
sysctl net.ipv4.conf.all.rp_filter

Netnafnrými eru þyngsti og hreinasti valkosturinn. Ræstu seinni biðlarann inni í ip netns, gefðu honum veth-par og farðu inn í það nafnrými til að nota hann. Truflun hverfur því hvert nafnrými á eigin töflur í stað þess að deila einni, sem er þess virði að setja upp þegar bæði göngin verða að vera uppi í vikur.

Eftir forriti, og keðjun sem sérstakt vandamál

Stundum á aðeins eitt forrit að nota seinni göngin. Á Linux nær stefnuleiðsla eftir notanda, cgroup eða porti þeirri niðurstöðu, og hægt er að festa einn áfangastað við viðmót án þess að snerta sjálfgefnu leiðina yfirleitt. Forrit sem festir sokkinn sinn við eitt viðmót ráðfærir sig aldrei við leiðartöfluna, svo ræsir getur haldið áfram að nota líkamlega millistykkið þar til vistfang er valið í eigin stillingum.

Keðjun er önnur aðgerð en að keyra tvö göng hlið við hlið. Að keðja A yfir B þýðir að vistfang innri þjónsins verður að vera aðgengilegt innan frá ytri göngunum. Ytri biðlarinn má heldur ekki taka dulrituðum pökkum innri biðlarans sem leka. Einn biðlari í sýndarvél er grófa en áreiðanlega útgáfan; báðir á einum hýsli krefjast leiðarvinnunnar hér að ofan auk ytri slóðar að innri þjóninum sem fer aldrei inn í innri göngin.

Skrifaðu niður eiganda sjálfgefnu leiðarinnar, lista yfir forskeyti sem hvert göng ber og DNS-slóðina. Þessar þrjár staðreyndir gera næsta atvik að uppflettingu í stað rannsóknar.