OpenVPN-bediener en -kliënt op een gasheer: waarom kliënte wegval

Voeg 'n kliëntprofiel by 'n masjien wat reeds 'n VPN-bediener laat loop, en die oorspronklike diens is die eerste slagoffer. Die nuwe tonnel vestig dalk nooit, of dit kom op terwyl die bediener se bestaande kliënte stilweg ophou om antwoorde te kry. Twee botsings lewer albei uitkomste: 'n tonnelpoel wat reeds in gebruik is, en 'n verstekroete wat deur die nuwe kliënthelfte geïnstalleer word en die hele tabel dek. Nie een lewer 'n OpenVPN-foutboodskap nie, en daarom word die faling as 'n bedienerprobleem gelees.

Een masjien, twee rolle, en twee onversoenbare antwoorde oor waarheen antwoorde moet gaan.

Dieselfde poel, twee bedieners: wie wen

Elke bedienerinstansie het sy eie tonnel-subnet nodig. Om 'n reël soos server 10.8.0.0 255.255.255.0 in die tweede konfigurasie te kopieer, gee twee instansies dieselfde voorvoegsel, en die uitkoms is óf 'n weiering om te begin óf 'n stille stryd waarin kliënte van een bediener adresse kry wat die ander ook as syne beskou. Verskillende UDP-poorte en verskillende toestelname help nie, want nie een raak die adresruimte nie. Verander die tweede poel, en verander dit oral waar die roetes dit noem.

Berei 'n lys voor van wat lewendig is voordat jy wysig: ip -4 addr show lys die tonneltoestelle, ss -lunp lys die luisteraars, en systemctl list-units noem die eenhede. Een blik op die tonneladresse beslis of die poele bots.

Wat die kliëntprofiel by die tabel voeg

Die kliënthelfte skryf roetes sodra dit verbind. redirect-gateway def1 splits die verstekroete in 0.0.0.0/1 plus 128.0.0.0/1, albei deur die nuwe toestel gerouteer, saam met 'n gasheerroete na die verre bediener wat doelbewus aan die fisiese koppelvlak vasgepen is. Daardie pen bestaan sodat die tonnel 'n pad vir sy eie vervoer behou. Alles anders, insluitend die antwoorde wat die plaaslike bediener aan sy eie kliënte verskuldig is, volg nou die nuwe verstek en verlaat deur die afgeleë skakel.

Die tweede botsing is dus nie 'n stukkende tonnel nie. Dit is 'n werkende tonnel op die verkeerde plek in die tabel.

Drie maniere om die rolle apart te hou

Die minste ingrypende oplossing hou die verstekroete uit die kliëntprofiel: route-nopull plus eksplisiete route-reëls vir die afgeleë voorvoegsels, sodat die plaaslike tabel net verander waar jy gevra het. Die volgende stap is 'n beleidsreël wat die plaaslike tonnel-subnet vrystel, sodat antwoorde aan plaaslike kliënte op die koppelvlak verlaat waarop hulle aangekom het, selfs terwyl 'n verstekroete bestaan. Die deeglikste is 'n aparte netwerknaamruimte vir die kliëntrol, wat die gedeelde tabel heeltemal verwyder en 'n tweede roeteringskonteks kos om te onderhou.

Watter pad jy ook al kies, die uitsondering moet die plaaslike tonnel-subnet noem, nie die LAN nie. Die antwoord wat die plaaslike bediener stuur, het 'n tonneladres as bestemming, so 'n LAN-vormige uitsondering pas nooit daarop nie.

Watter van die twee instansies is skuldig

Stop die kliëntinstansie en toets die oorspronklike kliënte weer. Onmiddellike herstel beteken roetering, nie die bediener nie. Bring die kliënt terug en volg 'n enkele antwoord met ip route get waaraan beide 'n bron- en 'n bestemmingsadres gegee is, wat die pad wys wat die kernel sou kies, en kyk dan na die koppelvlak wat pakkette werklik gebruik met tcpdump -ni any port 1194. Die bediener se statuslêer, elke paar sekondes geskryf deur die status-direktief, dra die lys van verbonde kliënte en greptellers vir albei rigtings.

Lees daardie tellers teen mekaar. Verkeer wat vertrek en nooit terugkom nie, is 'n roeteringsantwoord eerder as 'n handdrukprobleem.