Ég var með rannsóknarstöð sem tók við göngum frá fjarlægum stað og hringdi líka út í net birgja. Útgöngusniðið hafði virkað í vikur. Eftir að inngönguþjóninum var bætt við tengdist útgöngusniðið og hætti síðan að senda umferð innan nokkurra sekúndna, eða neitaði að ræsa með villu um að heimilisfangið sé þegar í notkun. Stillingarskrárnar höfðu ekki breyst; hýslin fengu einfaldlega annað OpenVPN-ferli með sína eigin skoðun á gáttum og leiðum.

Bilanin er ekki tilviljun og hún er ekki auðkenningarvandamál. Tveir dæmonar á einni vél keppa um sama staðbundna sokk og sömu leiðartöflu, og sá sem ræsir eða tengist aftur síðastur vinnur venjulega. Að vita hvor þessara tveggja árekstra þú hefur ræður því hvar á að líta fyrst.

Lestu einkennið afturábak

Byrjaðu á því hvenær göngin deyja. Bindivilla við ræsingu bendir á hlustunarhliðina: eitthvað á þegar gáttina, og OpenVPN neitar að ræsa frekar en að deila henni. Göng sem koma upp og þagna síðan benda á leiðakerfið, því leið sem hitt tilvikið setti upp getur dregið pakka ytri tengingarinnar af leið sinni.

Bæði tilvikin framkalla sama kvörtun notandans, þess vegna laga endurtekningarlotur og vaktaforskoðanir ekkert. Þær tengja biðlarann aftur í sama árekstur. Fyrsta gagnlega spurningin er hvort ferlið keyri enn þegar umferðin stöðvast.

Einn sokk og eitt tæki fyrir hvert tilvik

Hlustandi þjónn bindur gátt sína; útgangsbiðlari þarf líka staðbundna gátt fyrir hjúpaða umferð sína. Þegar báðir lifa á sama hýsli getur sjálfgefið hegðun biðlarans rekist á gátt þjónsins. Hægt er að festa staðbundna gátt biðlarans, og sleppa má bindingu þar sem mótaðilinn þarf ekki fasta upphafsgátt:

lport 1195
nobind
dev tun1

Þessar tölur eru dæmi, ekki krafa. Það sem skiptir máli er að biðlarinn hætti að keppa um gátt þjónsins og að hvert tilvik fái sér göngutæki. Tveir dæmonar sem deila tun0 skrifa yfir tækjastöðu hvors annars jafnvel þótt gáttir þeirra séu ólíkar, svo eitt tæki á hver göng er ekki valkvætt.

nobind tilheyrir biðlarahliðinni. Þjónn verður samt að binda og hlusta, svo ekki afrita línuna í stillingar þjónsins, og ekki slökkva á bindingu á biðlara sem mótaðilinn síar á fasta upphafsgátt.

Veldu einn eiganda fyrir sjálfgefnu leiðina

Aðeins ein tenging getur sett upp sjálfgefna leið. Ef bæði sniðin beina allri umferð, kemur önnur tengingin í stað þeirrar fyrri hljóðlaust, og sú fyrri virðist bila. Annaðhvort heldur þú útgöngugöngunum skipt og ýtir aðeins forskeytum birgjans, eða gefur þeim sérstaka leiðartöflu.

ip rule add from 10.9.0.2 table 120
ip route add default dev tun1 table 120
ip route get 10.9.0.2

Heimilisföngin og töflunúmerið hér að ofan eru staðgenglar. Strax eftir að reglunni er bætt við, staðfestu að heimilisfang VPN-þjónsins sjálfs leysist enn í gegnum venjulegu töfluna; tafla sem grípur ytri flutning brýtur göngin sem henni var ætlað að verja, og endurtengingarlotan sem fylgir lítur út eins og óáreiðanlegur veitandi.

Fyrir uppsetningu sem verður að standast endurtengingar og endurræsingar er netnafnrými traustari mörkin. Annar biðlarinn keyrir innan síns eigin nafnrýmis með sínum eigin tengi og leiðum, og aðeins þjónusturnar sem verða að fara yfir eru afhjúpaðar. Hýslin halda einni sjálfgefinni leið, og endurtenging nafnrýmis getur ekki endurskrifað hana.

Staðfestu með töflunni, ekki stöðulínunni

Biðlari sem tilkynnir að hann sé tengdur sannar aðeins stjórnrás sína. Skráðu leiðastöðuna fyrir og eftir hverja tengingu, spurðu síðan kjarnann hvaða tæki raunverulegur áfangastaður myndi nota:

ip route show
ip route get 10.40.0.20
ss -lunp | grep 1194

Ef valið tæki fyrir heimilisfang birgjans breytist þegar önnur göngin ræsa, hefur þú leiðaráreksturinn. Ef bæði ferlin birtast á sömu staðbundnu gátt, hefur þú sokkann. Að laga það fyrra án hins síðara færir bilunina bara á næstu endurtengingu.

Skrifaðu gáttirnar, tækin, töflurnar og eiganda leiðarinnar í runbook hýslanna. Annars mun næsta manneskja sem bætir við þriðju göngunum enduruppgötva sama árekstur, og eina sýnilega sönnunin verður tenging sem virkar þar til dæmon einhvers annars endurræsir.

Tengdir greinar