OpenVPN-tsjinner en -klant op ien host: wêrom klanten ôffalle

Foegje in klantprofyl ta oan in masine dêr't al in VPN-tsjinner op draait, en de oarspronklike tsjinst is it earste slachtoffer. De nije tunnel kin nea ta stân komme, of hy komt omheech wylst de besteande klanten fan 'e tsjinner stilwei gjin antwurden mear krije. Twa botsingen smeie beide resultaten: in tunnelpool dy't al yn gebrûk is, en in standertrûte dy't troch de nije klientside ynstallearre wurdt en de hiele tabel beslacht. Gjin fan beide jout in OpenVPN-flaterberjocht, en dêrom wurdt it falen as in tsjinnerprobleem lêzen.

Ien masine, twa rollen, en twa ûnferienbere antwurden oer wêr't antwurden hinne moatte.

Deselde pool, twa tsjinners: wa't wint

Elk tsjinner-exemplaar hat in eigen tunnelsubnet nedich. In rigel lykas server 10.8.0.0 255.255.255.0 yn 'e twadde konfiguraasje kopiearje jout twa eksimplaren itselde foarheaksel, en de útkomst is óf in wegering om te starten óf in stille striid wêryn't klanten fan de iene tsjinner adressen krije dy't de oare ek as syn eigen beskôget. Ferskillende UDP-poarten en ferskillende apparaatnammen helpe net, want gjin fan beide rekket de adresromte. Feroarje de twadde pool, en feroarje dy oeral dêr't de rûtes him neame.

List op wat libben is foar't jo bewurkje: ip -4 addr show listet de tunnelapparaten op, ss -lunp listet de harkers op, en systemctl list-units neamt de ienheden. Ien eachopslach op 'e tunneladressen beslist oft de pools botskje.

Wat it klantprofyl oan 'e tabel taheakket

De klientside skriuwt rûtes sa gau as er ferbynt. redirect-gateway def1 spjaltet de standertrûte yn 0.0.0.0/1 plus 128.0.0.0/1, beide troch it nije apparaat rûte, tegearre mei in hostrûte nei de fiere tsjinner dy't bewust oan 'e fysike ynterface fêstset is. Dy fêstsetting bestiet sadat de tunnel in paad foar syn eigen ferfier hâldt. Al it oare, ynklusyf de antwurden dy't de pleatslike tsjinner syn eigen klanten skuldich is, folget no de nije standert en ferlit troch de fiere keppeling.

Dat de twadde botsing is gjin brutsen tunnel. It is in wurkjende tunnel op 'e ferkearde plak yn 'e tabel.

Trije manieren om de rollen skieden te hâlden

De minst yngeande oplossing hâldt de standertrûte bûten it klantprofyl: route-nopull plus eksplisite route-rigels foar de fiere foarheaksels, sadat de pleatslike tabel allinnich feroaret dêr't jo it fregen. De folgjende stap is in beliedsregel dy't it pleatslike tunnelsubnet frijstelt, wêrtroch't antwurden oan pleatslike klanten ferlitte op 'e ynterface dêr't se oankamen, sels as der in standertrûte bestiet. It meast trochgeande is in aparte netwurknammeromte foar de klantrol, dy't de dielde tabel hielendal fuorthellet en in twadde rûte-kontekst kostet om te ûnderhâlden.

Hokker paad jo ek kieze, de útsûndering moat it pleatslike tunnelsubnet neame, net it LAN. It antwurd dat de pleatslike tsjinner stjoert hat in tunneladres as bestimming, dus in útsûndering yn 'e foarm fan in LAN past der nea op.

Hokker fan 'e twa eksimplaren is skuldich

Stopje it klanteksimplaar en test de oarspronklike klanten opnij. Direkt herstel betsjut rûte, net de tsjinner. Bring de klant werom en folgje ien antwurd mei ip route get dêr't sawol in boarne- as in bestimmingsadres oan jûn is, wat it paad lit sjen dat de kernel kieze soe, en besjoch dan de ynterface dy't pakketten echt brûke mei tcpdump -ni any port 1194. It statusbestân fan de tsjinner, dat elke pear sekonden skreaun wurdt fia de status-direktive, befettet de list fan ferbûne klanten en byte-tellers foar beide rjochtingen.

Lês dy tellers tsjin inoar. Ferkear dat fuortgiet en nea weromkomt is in rûte-antwurd ynstee fan in hânskoddingprobleem.