Cal que cada peer d’OpenVPN tingui una línia remote? No exactament
remote indica on va el primer paquet; no tria el paper de client, servidor o TLS. Llegeix la disposició abans de copiar-la als dos costats.
Es comparen dues configuracions de peer costat a costat, una té una línia remote i l’altra no, i la conclusió és que una d’elles està trencada. Aquesta inferència és incorrecta prou sovint perquè valgui la pena desglossar-la. La directiva descriu on s’ha d’enviar el primer paquet. No selecciona si el procés actua com a client que inicia o com a porta d’enllaç que espera, i no decideix quin costat demostra la seva identitat a l’altre.
Què especifica realment remote
Una entrada remote nomena un host, opcionalment un port i un transport, i opcionalment diverses entrades d’aquest tipus per provar-les en ordre.
La seva absència té un significat definit i no indefinit: el procés espera i no actua sobre paquets d’una adreça tret que aquell peer s’autentiqui. Per tant, una porta d’enllaç que serveix usuaris itinerants no té cap motiu per nomenar-ne cap per endavant.
Llegeix l’entrada com una relació d’adreces. Si es confia en l’extrem llunyà ho responen els certificats i les opcions de verificació, no el fet que s’hagi escrit una adreça.
Tres disposicions decideixen la resposta
Un client itinerant necessita una destinació, perquè ha d’iniciar i no sap on és la porta d’enllaç sense una. Una porta d’enllaç multi-client no necessita destinació per usuari, perquè els clients arriben i s’autentiquen. Un enllaç deliberat entre dos peers amb extrems coneguts pot tenir destinació en un costat, en tots dos o en cap, segons quin costat iniciï.
Enganxar una adreça de client fixa en una porta d’enllaç general és l’error que es deriva d’ignorar aquestes categories. Funciona per a l’únic peer l’adreça del qual es va registrar i enganya tots els altres.
Res de la directiva converteix una configuració en un servidor multi-client, i res de la seva presència impedeix un paper de servidor. La referència d’OpenVPN 2.6 documenta els arguments opcionals i el comportament sense remote per separat, cosa que és una pista de fins a quin punt són independents.
| Arrangement | Needs a destination |
|---|---|
| Roaming client | Yes, which gateway to contact |
| Multi-client gateway | No, peers authenticate on arrival |
| Two known peers | Depends on which side initiates |
Els papers de transport són un altre eix
Amb TCP, un costat espera i l’altre estableix la connexió. Són directives separades de la destinació, i barrejar-les produeix una parella que tots dos esperen o tots dos estableixen la connexió.
També hi ha un paper de filtre d’origen TCP, i per això és incorrecta l’afirmació plana que un servidor no pot contenir mai remote.
Amb UDP no hi ha connexió a establir, així que tots dos extrems fan servir el transport UDP corresponent i la directiva només diu cap on apuntar. Els canvis d’adreça d’un peer autenticat es gestionen amb un comportament dedicat i no afegint més entrades. Encertar el transport és una condició prèvia perquè la destinació signifiqui alguna cosa, i confondre els dos produeix configuracions que semblen plausibles i mai completen un handshake.
Per què un remote absent no és una porta oberta
Un procés sense destinació encara rebutja el trànsit de peers que no s’autentiquen, i aquesta és la part que la gent passa per alt quan llegeix la línia absent com un oient obert a tothom.
L’autenticació i la destinació són independents, i la primera és la que importa per a la confiança.
L’error invers és més perillós. Una adreça d’origen fixa pot semblar un control d’accés perquè és específica i fàcil de comprovar, però no demostra res sobre qui és a l’altre extrem. Conserva la verificació de certificats i les comprovacions d’identitat que lliguen un certificat al seu paper. Substituir-les per una coincidència d’adreces canvia un control real per l’aparença d’un.
Anota què assumeix la configuració
Per a cada costat, registra tres coses: com arriba el primer paquet al peer, quin costat pot acceptar el transport i què verifica cada costat de l’altre.
Aquestes suposicions són el disseny. Les directives només són la seva escriptura.
Si els dos fitxers difereixen, comprova si expressen suposicions diferents en lloc de suposar que un està malament. Una parella simètrica de fitxers no és ni necessària ni suficient per a un túnel funcional, i l’asimetria és sovint la part que fa funcionar una topologia.