OpenVPN-þjónn og biðlari á sama hýsli: hvers vegna biðlarar detta út

Bættu biðlarasniði við vél sem þegar keyrir VPN-þjón og upprunalega þjónustan verður fyrsta fórnarlambið. Nýja göngin myndast kannski aldrei, eða þau koma upp á meðan núverandi biðlarar þjónsins hætta hljóðlaust að fá svör. Tvö árekstrar framleiða bæði úrslitin: laug ganga sem er þegar í notkun, og sjálfgefin leið sem nýi biðlarahlutinn setur upp og nær yfir alla töfluna. Hvorki gefur OpenVPN-villuskilaboð, og þess vegna er bilunin lesin sem vandamál þjónsins.

Ein vél, tvö hlutverk og tvö ósamrýmanleg svör um hvert svörin eigi að fara.

Sama laug, tveir þjónar: hver vinnur

Hvert þjónstilvik þarf sitt eigið gönguundirnet. Að afrita línu eins og server 10.8.0.0 255.255.255.0 inn í seinni stillinguna gefur tveimur tilvikum sama forskeytið, og útkoman er annað hvort synjun á að ræsa eða hljóðlát keppni þar sem biðlarar annars þjónsins fá netföng sem hinn telur sig líka eiga. Mismunandi UDP-gáttir og mismunandi tækjanöfn hjálpa ekki, því hvorki snertir netfangarýmið. Breyttu seinni lauginni og breyttu henni alls staðar þar sem leiðirnar nefna hana.

Listaðu hvað er lifandi áður en þú breytir: ip -4 addr show listar göngutækin, ss -lunp listar hlustendur og systemctl list-units nefnir einingarnar. Eitt augnaráð á göngunetföngin ræður því hvort laugin rekast á.

Hvað biðlarasniðið bætir við töfluna

Biðlarahlutinn skrifar leiðir um leið og hann tengist. redirect-gateway def1 skiptir sjálfgefnu leiðinni í 0.0.0.0/1 plús 128.0.0.0/1, báðar leiðaðar í gegnum nýja tækið, ásamt hýsilleið að fjarlæga þjóninum sem er vísvitandi fest við líkamlega tengið. Sú festing er til svo göngin haldi leið fyrir eigin flutning. Allt annað, þar á meðal svörin sem staðbundni þjónninn skuldar eigin biðlurum, fylgir nú nýju sjálfgefnu leiðinni og fer út um fjartengingu.

Svo seinni áreksturinn er ekki brotin göng. Það eru vinnandi göng á röngum stað í töflunni.

Þrjár leiðir til að halda hlutverkunum aðskildum

Minnst íþyngjandi lagfæringin heldur sjálfgefnu leiðinni utan biðlarasniðsins: route-nopull plús skýrar route-línur fyrir fjarlægu forskeytin, svo staðbundna taflan breytist aðeins þar sem þú baðst um það. Næsta skref er stefnuregla sem undanþiggur staðbundna gönguundirnetið og leyfir svörum til staðbundinna biðlara að fara út um tengið sem þau komu á, jafnvel þótt sjálfgefnu leiðin sé til staðar. Ítarlegast er sérstakt netnafnsrými fyrir biðlarahlutverkið, sem fjarlægir sameiginlegu töfluna algjörlega og kostar annað leiðarvalssamhengi til að viðhalda.

Hvaða leið sem þú velur verður undanþágan að nefna staðbundið gönguundirnet, ekki LAN. Svarið sem staðbundni þjónninn sendir hefur göngunetfang sem áfangastað, svo undanþága í LAN-lagi passar aldrei við það.

Hvort tilvikið er sekkt

Stöðvaðu biðlaratilvikið og prófaðu upprunalegu biðlarana aftur. Tafarlaus bati þýðir leiðarval, ekki þjónninn. Komdu biðlaranum aftur og rekjaðu eitt svar með ip route get sem fær bæði upprunanetfang og áfangastað, sem sýnir leiðina sem kjarninn myndi velja, og fylgstu svo með tenginu sem pakkarnir nota í raun með tcpdump -ni any port 1194. Stöðuskrá þjónsins, sem er skrifuð á nokkurra sekúndna fresti í gegnum status tilskipunina, inniheldur lista yfir tengda biðlara og bætateljara í báðar áttir.

Lestu þessa teljara hvern á móti öðrum. Umferð sem fer út og kemur aldrei til baka er svar um leiðarval en ekki handabandsvandamál.