Að stafla öðrum OpenVPN biðli á eina Linux vél mistekst á öðrum af tveimur stöðum. Annaðhvort nær innri biðillinn ekki eigin netþjóni því ytri göngin hafa gripið þá flutningsleið, eða annar biðillinn skrifar yfir leiðatöfluna og fyrstu göngin hætta að virka. Bæði vandamálin eru í leiðavalinu, ekki í dulkóðuninni, og bæði eru leyst áður en nýju göngin flytja nokkra forritsumferð. Vistföngin hér eru til skýringar: tun0 eru ytri göngin, 203.0.113.9 er innri netþjónninn og TCP 9999 er flæðið sem verður að nota innri slóðina.

Tvær bilanir, ein leiðatafla

Innri biðill opnar UDP samband við netþjóninn sinn, og það samband fylgir núverandi leiðatöflu eins og hvert annað. Ef ytri göngin eiga þegar sjálfgefnu leiðina fara handabandspakkarnir inn í ytri göngin. Það virkar aðeins þegar ytri netþjónninn nær til innri netþjónsins og hinum megin er samþykkt að flytja flæðið; annars stöðvast handabandið og biðillinn reynir aftur.

Seinna bilunin kemur frá push frá netþjóninum. Venjulegt push er redirect-gateway def1, sem setur upp 0.0.0.0/1 og 128.0.0.0/1 í stað þess að skipta út sjálfgefnu leiðinni. Tveir biðlar sem hvor setur upp sitt eigið /1 par rekast því saman, og nýjasta parið vinnur fyrir nánast hvert áfangastað. Leitaðu að þessum tveimur forskeytum í töflunni þegar göng deyja eftir að sá seinni tengist, því sjálfgefna leiðin kann að hafa aldrei breyst.

Merktu flæðið og gefðu því töflu

Beindu völdu umferðinni með því að merkja hana í mangle töflunni og para merkið í stefnureglu. Reglan vísar á sérstaka töflu þar sem sjálfgefna leiðin er innri tækið, svo aðeins merktir pakkar fara innri slóðina.

iptables -t mangle -A PREROUTING -p tcp -m multiport --dport 9999 -j MARK --set-mark 0x9999
ip rule add fwmark 0x9999 table 200 pref 1000
ip route add default dev tun1 table 200

Flest bilana í þessu reglusetti koma frá tveimur mistökum. Merkjagildið sem eldveggurinn setur og gildið sem reglan parar verða að vera eins, því misræmi gefur hvorki villu né áhrif. Og PREROUTING sér aðeins pakka sem koma að utan, svo tenging sem hefst á þessari vél þarf OUTPUT reglu með sama pari áður en hún er merkt yfirleitt.

Taktu eignarhald leiðarinnar af öðrum biðlinum

Tveir valkostir koma í veg fyrir að annar biðillinn breyti töflunni, og þeir verka á mismunandi stöðum. route-nopull hunsar pushuðu leiðarvalkostina, svo ekkert er sett upp. route-noexec tekur pushuðu valkostina inn í umhverfi biðilsins en lætur töflubreytinguna eftir hook, og það er það sem þú vilt þegar þú þarft að sjá hvað netþjónninn bauð.

Hookið keyrir með pushuðu gildin í umhverfi sínu, og það á aðeins að bæta við færslunum sem þú samþykktir. Gerðu það idempotent: tæmdu töfluna sem það á áður en þú byggir upp aftur, og ekki gera ráð fyrir að fyrri keyrsla hafi skilið eftir hreint ástand. Endurtenging kallar á hookið aftur, og hook sem bætir við án þess að hreinsa safnar tvíteknum leiðum.

Veldu einn eiganda og skrifaðu hann niður. Prófíll sem stillir báða valkostina, eða hook sem keppir við handvirkt skript, framleiðir töflu sem enginn getur útskýrt síðar.

Festu bæði netþjónsvistföngin

Innri netþjónninn þarf hýsil-leið í gegnum ytra tækið áður en innri biðillinn tengist. Sú færsla heldur innri flutningnum inni í ytri göngunum í stað þess að láta hann fylgja sjálfgefnu leiðinni.

ip route add 203.0.113.9/32 dev tun0
ip route get 203.0.113.9

Bættu einnig samsvarandi hýsil-leið fyrir ytri netþjóninn í aðaltöfluna, annars getur endurtenging beint flutningi ytri biðilsins sjálfs inn í eigin göng. Röðin er ekki valkvæð: bættu þessum færslum við eftir að viðkomandi tengi er til, sem þýðir hook eða skript sem keyrir eftir tengingu. Leið sem vísar á tæki sem er niðri er fjarlægð eða hunsuð, svo færsla sem skrifuð er við ræsingu lifir ekki röðina sem þú gerðir ráð fyrir.

Athugaðu uppflettinguna í stað þess að lesa alla töfluna. Úttak leiðaruppflettingarinnar nefnir tækið og upprunavistfangið sem kjarninn mun nota, og það er einmitt það sem biðillinn fær þegar hann opnar sambandið sitt.

Prófaðu keðjuna og gerðu bilunina sýnilega

Gríptu á ytra tenginu á meðan innri biðillinn tengist. Innra handabandið á að birtast sem dulkóðuð sending inni í ytri göngunum; ef það birtist sem venjulegt UDP til 203.0.113.9 vantar hýsil-leiðina og keðjan var aldrei byggð.

Keðja sem fellur hljóðlaust aftur á líkamlegu uppstreymistenginguna er versta útkoman, því ástand tengisins tilkynnir ekkert og innri umferðin fer út frá röngu upprunavistfangi. Ef annar biðillinn getur tengst aftur beint þegar ytri göngin falla, slökktu á þeirri slóð eða bundu hana við ytra tengið svo bilunin verði sýnileg.

Ljúktu með tveimur flæðum og einum regludumpi: merkt tenging og ómerkt ættu að fara mismunandi slóðir, og ip rule show ætti að lista forgangið sem þú ætlaðir. Ef bæði flæðin fara sömu slóð, er merkið ekki sett þar sem þú heldur.

Tengdir greinar