Heeft elke OpenVPN-peer een remote-regel nodig? Niet bepaald
remote noemt waar het eerste pakket heen gaat; het kiest niet de client-, server- of TLS-rol. Lees de opstelling voordat je die naar beide kanten kopieert.
Twee peer-configuraties worden naast elkaar gelegd, de ene heeft een remote-regel en de andere niet, en de conclusie is dat een van beide stuk is. Die gevolgtrekking is vaak genoeg onjuist om haar uit elkaar te halen. De richtlijn beschrijft waar het eerste pakket heen moet. Zij kiest niet of het proces als initiërende client of als wachtende gateway optreedt, en zij bepaalt niet welke kant haar identiteit aan de andere bewijst.
Wat remote feitelijk aangeeft
Een remote-vermelding noemt een host, optioneel een poort en een transport, en optioneel meerdere zulke vermeldingen die op volgorde worden geprobeerd.
Het ontbreken ervan heeft een bepaalde en niet een onbepaalde betekenis: het proces wacht en reageert niet op pakketten van een adres tenzij die peer zich authenticeert. Een gateway die roaming-gebruikers bedient heeft daarom geen reden om een van hen vooraf te noemen.
Lees de vermelding als een adresrelatie. Of de andere kant vertrouwd is, beantwoorden certificaten en de verificatieopties, niet het feit dat er een adres is opgeschreven.
Drie opstellingen bepalen het antwoord
Een roaming-client heeft een bestemming nodig, omdat hij moet initiëren en zonder bestemming niet weet waar de gateway is. Een gateway voor veel clients heeft geen bestemming per gebruiker nodig, omdat clients aankomen en zich authenticeren. Een bewuste koppeling tussen twee peers met bekende eindpunten kan aan één kant, aan beide kanten of aan geen enkele kant een bestemming hebben, afhankelijk van welke kant initieert.
Een vast clientadres in een algemene gateway plakken is de fout die volgt uit het negeren van die categorieën. Het werkt voor de ene peer wiens adres werd vastgelegd en misleidt alle anderen.
Niets aan de richtlijn maakt van een configuratie een server voor veel clients, en niets aan de aanwezigheid ervan verhindert een serverrol. De OpenVPN 2.6-referentie documenteert de optionele argumenten en het gedrag zonder remote afzonderlijk, wat een aanwijzing is voor hoe onafhankelijk die zijn.
| 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 |
Transportrollen zijn een andere as
Bij TCP wacht de ene kant en kiest de andere. Dat zijn aparte richtlijnen van de bestemming, en ze door elkaar halen levert een paar op waarin beide wachten of beide kiezen.
Er is ook een TCP-bronfilterrol, en daarom is de platte bewering dat een server nooit remote mag bevatten onjuist.
Bij UDP is er geen verbinding op te bouwen, dus beide uiteinden gebruiken het bijbehorende UDP-transport en de richtlijn zegt alleen waarop gericht moet worden. Adreswijzigingen door een geauthenticeerde peer worden door eigen gedrag afgehandeld en niet door meer vermeldingen toe te voegen. Het transport goed hebben is een voorwaarde wil de bestemming iets betekenen, en de twee verwarren levert configuraties op die aannemelijk lijken en nooit een handshake afronden.
Waarom een ontbrekende remote geen open deur is
Een proces zonder bestemming weigert nog steeds verkeer van peers die zich niet authenticeren, en dat is het deel dat mensen missen wanneer ze de ontbrekende regel lezen als een luisteraar die voor iedereen openstaat.
Authenticatie en bestemming zijn onafhankelijk, en de eerste is degene die voor vertrouwen telt.
De omgekeerde fout is gevaarlijker. Een vast bronadres kan als toegangscontrole aanvoelen omdat het specifiek en makkelijk te controleren is, maar het bewijst niets over wie er aan de andere kant zit. Behoud de certificaatverificatie en de identiteitscontroles die een certificaat aan zijn rol binden. Ze vervangen door een adresovereenkomst ruilt een echte controle voor het uiterlijk ervan.
Schrijf op wat de configuratie veronderstelt
Noteer voor elke kant drie dingen: hoe het eerste pakket de peer bereikt, welke kant het transport kan accepteren, en wat elke kant over de andere verifieert.
Die aannames zijn het ontwerp. De richtlijnen zijn alleen de spelling ervan.
Als de twee bestanden verschillen, controleer dan of ze verschillende aannames uitdrukken in plaats van aan te nemen dat een van beide fout is. Een symmetrisch paar bestanden is voor een werkende tunnel niet nodig en niet voldoende, en de asymmetrie is vaak het deel dat een topologie laat werken.