Eweknie-adres verander midde-in die sessie: wat OpenVPN se float doen

Die skootrekenaar skuif van kantoor-Wi-Fi na 'n selfoon-hotspot, die tonnel bly nog 'n paar sekondes regop, en dan stop die verkeer terwyl die koppelvlak steeds voorgee dat dit verbind is. Op die bediener bly die statuslys die ou publieke adres wys. Dit is die situasie waarvoor float bestaan, en dit is ook die situasie waarin mense verwag dat dit veel meer doen as wat dit doen. Om die grens reg te kry, verander 'n verwarrende stilstand in óf 'n eenreël-konfigurasiewysiging óf 'n heeltemal ander ondersoek.

Wat float verslap, en wat dit nooit verslap nie

Normaalweg bly 'n sessie praat met die buitenste adres en poort waarmee dit begin het, en pakkette wat van elders aankom, word geïgnoreer. Die float-opsie verwyder daardie streng binding sodra die eweknie homself reeds bewys het, sodat 'n veranderde bronkartering dieselfde sessie kan voortsit in plaas daarvan om laat vaar te word. Niks aan die kriptografiese kontroles verander nie: sleutels, sertifikate en enige HMAC-beskerming bly presies soos gekonfigureer.

Dit is 'n besluit per pakket, nie 'n beleid oor wie mag koppel nie. 'n Onbekende masjien wat 'n pakket vanaf 'n nuwe adres stuur, het niks bewys nie, en sy pakket word weggegooi soos enige ander ongeoutentiseerde verkeer. Slegs verkeer wat die sessie se eie verifikasie slaag, kan die aangetekende eweknie-adres verskuif, en daarom is dit veilig om float aan te laat in omgewings waar kliënte rondswerf.

Dit sê ook niks oor die binneste tonnel nie. 'n Verskuiwde buitenste adres hertoeken nie 'n tonneladres nie, verander nie die poel nie en gee nie die eweknie toegang tot iets nuuts nie. Binne die tonnel geld dieselfde identiteit en dieselfde gestuurde roetes voor en ná die skuif. 'n Swerftog heronderhandel ook nie die datakanaal nie, so die onderhandelde syfer en sleutels hou aan.

Die pakket wat 'n sessie verskuif, moet authentiseer

Begin 'n sessie op die gewone manier teen die gekonfigureerde remote, en float hanteer wat gebeur wanneer die kartering verander. 'n Mobiele operateur wat midde-in die vloei hernommer, 'n NAT-hek wat sy poortkartering herskryf, of 'n skootrekenaar wat opvoer skakel, lewer almal dieselfde vorm: geoutentiseerde pakkette vanaf 'n nuwe tuple, wat aankom op 'n sessie wat nog in die oue glo.

Wanneer iemand vra of float werk, is die nuttige bewyse 'n voltooide handdruk gevolg deur 'n bronverandering wat aanvaar is, nie 'n logreël oor die adres alleen nie. Korreleer die ou en nuwe buitenste adresse met die sessie wat aan die lewe gebly het, en bevestig dan dat verkeer werklik deur die tonnel aangehou het.

As die sessie sterf in plaas daarvan om te skuif, het die pakket wat van die nuwe adres aangekom het waarskynlik misluk om te authentiseer of het glad nie aangekom nie. Albei gevalle lyk identies van die kliënt se kant. Op die bediener vertel 'n opname op die publieke koppelvlak jou watter een jy het voordat jy aan enige konfigurasie raak.

Ontdekking is 'n heeltemal aparte meganisme

float los nie name op 'n tydhouer op nie en volg nie 'n dinamiese DNS-rekord nie. As die bediener se gasheernaam begin oplos na 'n nuwe adres, het 'n ledige kliënt geen rede om dit raak te sien nie en geen pakket van die nuwe eindpunt om te authentiseer nie. Daardie probleem hoort by herverbindingslogika, by die kliënt se eie herprobeergedrag en by DNS, nie by float nie.

Om die opsie nog 'n keer by te voeg, kan nie vergoed vir geen roete na die nuwe adres nie. Dit help ook nie wanneer die eweknie stil is nie, want 'n stille eweknie stuur nooit die geoutentiseerde pakket wat iets sou verskuif nie.

Die onderliggende brandmuur het ook 'n sê. 'n Reël wat slegs die ou buitenste eindpunt toelaat, blokkeer die veranderde adres voordat OpenVPN dit ooit sien, en geen mate van kliëntkonfigurasie maak dit reg nie. Hersien die lewensiklus van toegelate adresse as 'n eie taak; om die reël na enige bron te verbreed, ruil 'n klein probleem vir 'n groot een.

Wanneer NetworkManager die profiel besit

'n Opdragreëlprofiel en 'n ingevoerde verbinding is aparte konfigurasies, en om die een te wysig raak nie die ander nie. Voordat jy aanneem die opsie word nie ondersteun nie, stel vas watter tipe inprop die gestoorde profiel werklik gebruik en waar sy waardes woon. Die profiel-UUID is die identifiseerder wat saak maak wanneer jy iets inspekteer of wysig.

Inspekteer die gestoorde verbinding eerder as die oorspronklike invoerlêer. 'n Reël wat in 'n .ovpn-lêer oorleef, bewys niks as die aktiewe bestuurder dit nooit toegepas het nie, en 'n redigeerder sonder 'n merkkasie vir 'n gegewe opsie bewys ook niks oor die protokol se vermoëns nie.

Moenie 'n verpakte inprop pleister om die gedrag by te voeg nie, veral nie met 'n diff wat vir 'n historiese weergawe van 'n onverwante komponent geskryf is nie. As die geïnstalleerde integrasie die instelling werklik nie kan uitdruk nie, is die korrekte stap 'n ondersteunde profiel of 'n ander kliëntpad wat deur die eienaar van die ontplooiing goedgekeur is.

Bewys die oorgang eerder as om dit aan te neem

Hardloop die toets soos die fout gebeur. Koppel, verifieer verkeer deur die tonnel, forseer die buitenste adres om te verander, en kyk dan na drie dinge: die sessie bestaan nog, die aangetekende eweknie-adres het geskuif, en 'n werklike versoek bereik nog sy bestemming. Enigiets minder as al drie is 'n gedeeltelike antwoord.

Hou hersteltoegang beskikbaar terwyl jy toets, want swerfeksperimente het 'n gewoonte om die masjien waarvan jy werk, gestrand te laat. 'n Reekskonsole of 'n buitebandroete maak 'n mislukte toets 'n herstel van vyf minute in plaas van 'n besoek aan die perseel.

Ten slotte, beskryf slegs die geval wat jy uitgeoefen het. 'n Suksesvolle adresverandering tydens 'n sessie is nie bewyse dat DNS-migrasies, 'n ander kliëntimplementering of 'n herboude profiel dieselfde sal optree nie. Die link-options-dokumentasie stel die opsie se omvang presies; jou toetslog moet sê watter deel van daardie omvang jy werklik gedek het.