OpenVPN-kliënt staak wanneer sy bediener op dieselfde gasheer loop

Ek het ’n laboratoriummasjien gehad wat ’n tonnel van ’n afgeleë terrein aanvaar het en ook na ’n verskaffernetwerk uitgebel het. Die uitgaande profiel het weke lank gewerk. Nadat die inkomende bediener bygevoeg is, het die uitgaande een gekonnekteer en dan binne sekondes opgehou om verkeer deur te stuur, of geweier om te begin met ’n adres-in-gebruik-fout. Die konfigurasielêers het nie verander nie; die gasheer het bloot ’n tweede OpenVPN-proses bygekry met sy eie mening oor poorte en roetes.

Die fout is nie willekeurig nie, en dit is nie ’n verifikasieprobleem nie. Twee daemons op een masjien kompeteer om dieselfde plaaslike sok en dieselfde roetetabel, en die een wat laaste begin of weer koppel, wen gewoonlik. Om te weet watter van dié twee botsings jy het, bepaal waar jy eerste moet kyk.

Lees die simptoom agterstevoor

Begin by wanneer die tonnel sterf. ’n Bindfout by die begin wys na die luisterkant: iets besit reeds daardie poort, en OpenVPN weier om te begin eerder as om dit te deel. ’n Tonnel wat opkom en dan stil word, wys na roetering, want ’n roete wat deur die ander instansie ingestel is, kan die buitenste verbinding se pakkette van hul pad af trek.

Albei gevalle lewer dieselfde gebruikersklag, en daarom los herprobeerlusse en waghonde-skrifte niks op nie. Hulle koppel die kliënt weer in dieselfde konflik in. Die nuttige eerste vraag is of die proses nog loop wanneer die verkeer stop.

Een sok en een toestel per instansie

’n Luisterende bediener bind sy poort; ’n uitgaande kliënt het ook ’n plaaslike poort vir sy ingekapselde verkeer nodig. Wanneer albei op dieselfde gasheer woon, kan die verstek kliëntgedrag met die bediener se poort bots. Die kliënt se plaaslike poort kan vasgepen word, en binding kan oorgeslaan word waar die eweknie nie ’n vaste bronpoort nodig het nie:

lport 1195
nobind
dev tun1

Daardie getalle is voorbeelde, nie ’n vereiste nie. Wat saak maak, is dat die kliënt ophou om om die bediener se poort mee te ding en dat elke instansie ’n aparte tonneltoestel kry. Twee daemons wat tun0 deel, oorskryf mekaar se toesteltoestand selfs wanneer hul poorte verskil, so een toestel per tonnel is nie opsioneel nie.

nobind hoort by die kliëntkant. ’n Bediener moet steeds bind en luister, so moenie die reël in die bedienerkonfigurasie kopieer nie, en moenie binding op ’n kliënt afskakel wie se eweknie op ’n vaste bronpoort filter nie.

Kies een eienaar vir die verstekroete

Slegs een verbinding kan ’n verstekroete installeer. As albei profiele alle verkeer herlei, vervang die tweede koneksie die eerste stilweg, en die eerste lyk of dit breek. Hou óf die uitgaande tonnel gesplit en stuur net die verskaffer-prefikse, óf gee dit ’n aparte roetetabel.

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

Die adresse en tabelnommer hierbo is plekhouers. Bevestig dadelik nadat die reël bygevoeg is dat die VPN-bediener se eie adres steeds deur die normale tabel opgelos word; ’n tabel wat die buitenste vervoer vasvang, breek die tonnel wat dit moes beskerm, en die herkoppelings-lus wat volg, lyk soos ’n onbetroubare verskaffer.

Vir ’n opstelling wat herkoppelings en herstarte moet oorleef, is ’n netwerknaamruimte die stewiger grens. Die tweede kliënt loop binne sy eie naamruimte met sy eie interfaces en roetes, en net die dienste wat moet oorkruis, word blootgestel. Die gasheer hou een verstekroete, en ’n naamruimte-herkoppeling kan dit nie herskryf nie.

Verifieer met die tabel, nie die statuslyn nie

’n Kliënt wat aanmeld dat hy gekoppel is, bewys net sy beheerkanaal. Neem die roeteringstoestand voor en na elke koneksie vas en vra dan die kernel watter toestel ’n werklike bestemming sou gebruik:

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

As die gekose toestel vir die verskafferadres verander wanneer die tweede tonnel begin, het jy die roetebotsing. As albei prosesse teen dieselfde plaaslike poort verskyn, het jy die sokbotsing. Om die eerste sonder die tweede reg te maak, skuif net die fout na die volgende herkoppeling.

Skryf die poorte, toestelle, tabelle en roeteeienaar in die gasheer se runbook. Die volgende persoon wat ’n derde tonnel byvoeg, sal andersins dieselfde botsing herontdek, en die enigste sigbare bewys sal ’n verbinding wees wat werk totdat iemand anders se daemon herbegin.