Waarom ’n OpenVPN UDP-antwoord van die verkeerde adres vertrek

OpenVPN-kliënt skakel een adres, die bediener antwoord vanaf ’n ander een, en die tonnel kom nooit op nie. Die bedienerlog wys die pakkie kom in en ’n opname wys ’n antwoord wat uitgaan, so die fout word aan die kliënt toegeskryf. Op ’n gasheer met verskeie koppelvlakke, of verskeie adresse op een koppelvlak, stem die twee kante eenvoudig nie saam oor watter adres in gebruik is nie. Die antwoord is geldig op die IP-laag, tog verwerp baie kliënte ’n datagram waarvan die bron nie die adres is wat hulle gekontak het nie.

Wat die kliënt sien wanneer die bron verander

’n UDP-sokket wat nie aan ’n spesifieke plaaslike adres gebind is nie, het geen vaste bron nie, so die kern kies een wanneer dit stuur. Daardie keuse kom van ’n roetesoektog na die kliënt se adres, en die bron word die adres van die koppelvlak wat die soektog kies. Op ’n masjien met een koppelvlak is die keuse onsigbaar; op ’n gasheer met ’n bestuursadres, ’n openbare adres en ’n sekondêre adres op dieselfde netwerkkaart, hang dit van roetemetrieke en -beleid af. Beleidsroetering maak die wanverhouding meer waarskynlik eerder as minder, want ’n reël kan ’n opstroomverbinding kies wat die kliënt nooit bereik het nie. ’n Verstekroete wat van een verskaffer geleer is, plus ’n bronreël wat na ’n ander wys, is genoeg om dit te veroorsaak.

Kliënte wat antwoorde filtereer, en verbindingnasporing wat die presiese vier-tupel en bron verwag, sal die antwoord laat val sonder ’n nuttige boodskap. Die tonnel hou dan op met reageer asof niks aangekom het nie, en daarom word dit verkeerdelik as ’n kliëntkant-vuurmuurprobleem beskou. ’n Opname wat net op die bediener geneem is, bevestig die fout eerder as om dit te verduidelik, want die antwoord vertrek inderdaad. Vergelyk die antwoord se bron met die adres wat die kliënt geskakel het voordat jy enigiets anders verander.

Wat die multihome-opsie werklik doen

Die richtlijn word as multihome in ’n konfigurasielêer geskryf en as --multihome op die opdragreël, en dit laat ’n UDP-bediener antwoord vanaf die adres wat die kliënt se pakkie bereik het. Die kern lewer die oorspronklike bestemmingsadres as bykomende data by ontvangs, en OpenVPN gebruik daardie waarde as die bron vir die antwoord. ’n Bediener wat op ’n wildcard-adres luister, local 0.0.0.0 vir IPv4 of sy IPv6-ekwivalent, gedra hom dan asof elke kliënt ’n toegewyde luisteraar bereik het. Kliënte wat deur die openbare adres ingekom het, kry antwoorde vanaf die openbare adres, en kliënte op ’n interne adres kry antwoorde vanaf daardie een. Niks anders in die pakkiepad beweeg nie: die roete, die filterreëls en die tonnelkonfigurasie bly presies soos dit was.

Daardie laaste eienskap is waarom die opsie veilig is om by ’n andersins werkende bediener te voeg, en ook waarom dit nie ’n filter kan herstel wat net een adres toelaat nie. Die pakkie moet steeds op die pad wat dit volg aanvaar word, so die bronregstelling verander die antwoord se oorsprong en niks meer nie. Dit is ook net vir UDP: ’n TCP-luisteraar het nie hierdie probleem in dieselfde vorm nie, want die verbinding word deur die vier-tupel geïdentifiseer eerder as deur die antwoord se bronadres.

Wanneer ’n vaste plaaslike adres die verkeerde verstek is

Voordat jy na die opsie gryp, kyk of die bediener een spesifieke plaaslike adres bind, want ’n gebinde luisteraar antwoord altyd vanaf daardie adres. Dit is korrek vir ’n ontplooiing met een koppelvlak en verkeerd sodra kliënte wettig meer as een adres gebruik. As die binding doelbewus was, besluit of die bediener hoegenaamd verkeer op bykomende adresse moet aanvaar. Om die binding te verwyder verhoog die blootstelling, so die toegelate koppelvlakke en bronnetwerke moet deur die diens en die filter afgedwing word, nie net deur die bindadres nie.

Die OpenVPN-verwysing beperk die opsie tot UDP-bedieners, noem die ekstra verwerking in die pakkiepad, en teken aan watter platforms dit ondersteun. Bevestig dit op die geïnstalleerde weergawe voordat jy daarom beplan. Waar dit nie ondersteun word nie, is die binding van die spesifieke adres of die regstelling van die retourroetering die alternatief, en albei is smaller veranderinge as wat dit op die oog af lyk. Wildcard-luistering het ook gevolge buite antwoorde: ’n bediener op alle adresse is bereikbaar vanaf elke netwerk waaraan die gasheer gekoppel is, wat dalk nie die blootstelling is wat iemand bedoel het nie.

Bewys die antwoord se bron van buite

Toets van buite die bediener, en teken die presiese adres en vervoer wat die kliënt gebruik het aan voordat jy enigiets opneem. Die drie ondersoeke hieronder antwoord drie verskillende vrae, en die volgorde maak saak.

tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20

Die opname wys die bronadres op die antwoord, wat die feit is waarom hierdie hele artikel draai. Die sokketlys wys wat die bediener werklik gebind het, want ’n wildcard-luisteraar en ’n spesifieke een lyk identies in ’n konfigurasielêer en gedra hulle anders op die draad. Die roetesoektog wys die bron wat die kern vir daardie vloei sou kies, wat die opname verklaar voordat jy enigiets verander. Herhaal al drie vir IPv4 en IPv6 afsonderlik, want hulle is afsonderlike luisteraars en afsonderlike soektogte, en ’n wildcard-inskrywing vir een familie sê niks oor die ander nie.

Roetering, ontdekking en filterering bly apart

Om die antwoord se bron te bewaar, installeer nie ’n uitgaande roete nie, werk nie dinamiese DNS op nie en maak nie dat een adresfamilie die ander aanvaar nie. Op ’n bediener met verskeie opstroomverbindings moet die retourpad vir elke bron doelbewus ooreengekom word, anders verlaat antwoorde ’n koppelvlak wat die kliënt se filter nooit toegelaat het nie. Net so moet ’n nuwe adres ná ’n voorvoegselverandering kliënte deur ontdekking en die ondersteunde herverbindingsvloei bereik, nie deur die ou rekord nie.

Laat bedieneridentiteitskontroles en sertifikaatverifikasie presies soos dit is, want ’n veranderde adres regverdig nie die aanvaarding van ’n ongeverifieerde eweknie nie. As die antwoord nou vanaf die bedoelde bron vertrek en die tonnel steeds misluk, beskou die bronprobleem as opgelos en gaan aan. Die volgende fout wat waargeneem word, behoort aan roetering, filterering of verifikasie, en om die luisteraar weer te verander sal dit nie bereik nie. Skryf die antwoord se bron in die kaartjie langs die adres wat die kliënt geskakel het, sodat die volgende persoon dieselfde feit met een opdrag kan nagaan.