Peer-adres midden in de sessie gewijzigd: wat OpenVPN float doet
float laat een geauthenticeerde peer zijn buitenste adres midden in de sessie wijzigen. Het ontdekt geen endpoints, opent geen dode verbinding opnieuw en slaat geen identiteitscontroles over.
De laptop gaat van kantoor-Wi-Fi naar een hotspot op de telefoon, de tunnel blijft nog een paar seconden overeind en dan stopt het verkeer terwijl de interface blijft beweren dat er verbinding is. Op de server toont de statuslijst nog steeds het oude publieke adres. Dit is de situatie waarvoor float bestaat, en tegelijk de situatie waarin mensen er veel meer van verwachten dan het doet. De grens goed trekken maakt van een verwarrende stilstand ofwel een configuratiewijziging van één regel, ofwel een heel ander onderzoek.
Wat float versoepelt en wat het nooit versoepelt
Normaal blijft een sessie praten met het buitenste adres en de poort waarmee hij begon, en pakketten die van elders aankomen worden genegeerd. De optie float haalt die strikte binding weg zodra de peer zich al heeft bewezen, zodat een gewijzigde bronmapping dezelfde sessie kan voortzetten in plaats van te worden weggegooid. Aan de cryptografische controles verandert niets: sleutels, certificaten en elke HMAC-bescherming blijven precies zoals geconfigureerd.
Dit is een beslissing per pakket, geen beleid over wie mag verbinden. Een onbekende machine die een pakket vanaf een nieuw adres stuurt, heeft niets bewezen, en het pakket wordt weggegooid zoals alle andere niet-geauthenticeerde verkeer. Alleen verkeer dat de eigen authenticatie van de sessie doorstaat, kan het vastgelegde peer-adres verplaatsen, en daarom is het veilig float aan te laten staan in omgevingen waar clients rondzwerven.
Het zegt ook niets over de binnenste tunnel. Een verplaatst buitenste adres wijst geen tunneladres opnieuw toe, verandert de pool niet en geeft de peer geen toegang tot iets nieuws. Binnen de tunnel gelden dezelfde identiteit en dezelfde doorgeduwde routes voor en na de verplaatsing. Een roam onderhandelt ook het datakanaal niet opnieuw, dus de onderhandelde cipher en sleutels lopen door.
Het pakket dat een sessie verplaatst, moet zich authenticeren
Start een sessie op de gebruikelijke manier tegen de geconfigureerde externe kant, en float regelt wat er gebeurt als de mapping verandert. Een mobiele provider die midden in de stroom hernummert, een NAT-gateway die zijn poortmapping herschrijft, of een laptop die van uplink wisselt, leveren allemaal dezelfde vorm: geauthenticeerde pakketten uit een nieuwe tuple, die aankomen bij een sessie die nog in de oude gelooft.
Als je wordt gevraagd of float werkt, is het nuttige bewijs een voltooide handshake gevolgd door een geaccepteerde bronwijziging, niet een logregel over het adres alleen. Correleer het oude en het nieuwe buitenste adres met de sessie die in leven bleef, en bevestig daarna dat het verkeer echt door de tunnel is doorgegaan.
Sterft de sessie in plaats van te verplaatsen, dan is het pakket van het nieuwe adres waarschijnlijk op authenticatie gestrand of helemaal niet aangekomen. Beide gevallen zien er vanaf de client identiek uit. Op de server vertelt een capture op de publieke interface je welke van de twee je hebt voordat je enige configuratie aanraakt.
Ontdekking is een volledig apart mechanisme
float lost geen namen op met een timer en volgt geen dynamisch DNS-record. Als de hostnaam van de server naar een nieuw adres begint te resolven, heeft een inactieve client geen reden om dat op te merken en geen pakket van het nieuwe endpoint om te authenticeren. Dat probleem hoort bij herverbindingslogica, bij het eigen herhaalgedrag van de client en bij DNS, niet bij float.
De optie nog eens toevoegen compenseert geen ontbrekende route naar het nieuwe adres. Het helpt ook niet als de peer zwijgt, want een zwijgende peer stuurt nooit het geauthenticeerde pakket dat iets zou verplaatsen.
De onderliggende firewall heeft ook een stem. Een regel die alleen het oude buitenste endpoint toestaat, blokkeert het gewijzigde adres voordat OpenVPN het ooit ziet, en geen enkele clientconfiguratie lost dat op. Bekijk de levenscyclus van toegestane adressen als een eigen taak; de regel verbreden naar elke bron ruilt een klein probleem voor een groot.
Wanneer NetworkManager het profiel bezit
Een commandoregelsprofiel en een geïmporteerde verbinding zijn aparte configuraties, en het ene bewerken raakt het andere niet. Voordat je aanneemt dat de optie niet wordt ondersteund, stel je vast welk plugintype het opgeslagen profiel werkelijk gebruikt en waar de waarden leven. De UUID van het profiel is de identificatie die telt wanneer je iets inspecteert of wijzigt.
Inspecteer de opgeslagen verbinding en niet het oorspronkelijke importbestand. Een regel die in een .ovpn-bestand overleeft, bewijst niets als de actieve beheerder hem nooit heeft toegepast, en een editor zonder vinkje voor een bepaalde optie bewijst evenmin iets over de mogelijkheden van het protocol.
Patch geen verpakt plugin om het gedrag toe te voegen, zeker niet met een diff die voor een historische versie van een niet-verwante component is geschreven. Als de geïnstalleerde integratie de instelling echt niet kan uitdrukken, is de juiste stap een ondersteund profiel of een ander clientpad dat door de eigenaar van de uitrol is goedgekeurd.
Bewijs de overgang in plaats van hem aan te nemen
Voer de test uit zoals de storing gebeurt. Verbind, verifieer verkeer door de tunnel, forceer een wijziging van het buitenste adres en controleer dan drie dingen: de sessie bestaat nog, het vastgelegde peer-adres is verplaatst en een echt verzoek bereikt nog zijn bestemming. Alles minder dan alle drie is een gedeeltelijk antwoord.
Houd hersteltoegang beschikbaar terwijl je test, want roaming-experimenten hebben de gewoonte de machine waarvan je werkt achter te laten. Een seriële console of een out-of-band-route maakt van een mislukte test een herstel van vijf minuten in plaats van een bezoek ter plaatse.
Beschrijf ten slotte alleen het geval dat je hebt beproefd. Een geslaagde adreswijziging tijdens een sessie is geen bewijs dat DNS-migraties, een andere clientimplementatie of een herbouwd profiel zich hetzelfde gedragen. De link-options-documentatie geeft de reikwijdte van de optie precies aan; je testlog hoort te vermelden welk deel van die reikwijdte je werkelijk hebt gedekt.