Skal hver OpenVPN-peer have en remote-linje? Ikke helt

To peer-konfigurationer sammenlignes side om side, den ene har en remote-linje og den anden ikke, og konklusionen er, at en af dem er brudt. Den slutning er forkert ofte nok til at være værd at pakke ud. Direktivet beskriver, hvor den første pakke skal sendes hen. Det vælger ikke, om processen optræder som en initierende klient eller en ventende gateway, og det afgør ikke, hvilken side der beviser sin identitet over for den anden.

Hvad remote faktisk angiver

En remote-post angiver en vært, eventuelt en port og en transport, og eventuelt flere sådanne poster, der forsøges i rækkefølge.

Dets fravær har en bestemt betydning og ikke en ubestemt: processen venter og handler ikke på pakker fra en adresse, medmindre den peer autentificerer sig. En gateway, der betjener roaming-brugere, har derfor ingen grund til at angive nogen af dem på forhånd.

Læs posten som et adresseforhold. Om den anden ende er betroet, besvares af certifikater og verifikationsindstillingerne, ikke af at der er skrevet en adresse ned.

Tre opstillinger afgør svaret

En roaming-klient har brug for en destination, fordi den skal initiere og ikke aner, hvor gatewayen er, uden en. En gateway til mange klienter har ikke brug for en destination pr. bruger, fordi klienterne ankommer og autentificerer sig. Et bevidst link mellem to peers med kendte endepunkter kan have en destination på den ene side, på begge sider eller på ingen, afhængigt af hvilken side der initierer.

At indsætte en fast klientadresse i en generel gateway er den fejl, der følger af at ignorere disse kategorier. Det virker for den ene peer, hvis adresse blev registreret, og vildleder alle andre.

Intet ved direktivet gør en konfiguration til en server til mange klienter, og intet ved dets tilstedeværelse forhindrer en serverrolle. OpenVPN 2.6-referencen dokumenterer de valgfrie argumenter og adfærden uden remote hver for sig, hvilket er et vink om, hvor uafhængige de er.

Transportroller er en anden akse

Med TCP venter den ene side, og den anden ringer op. Det er separate direktiver fra destinationen, og at blande dem giver et par, hvor begge venter eller begge ringer op.

Der er også en TCP-kildefilterrolle, og derfor er den flade påstand, at en server aldrig må indeholde remote, forkert.

Med UDP er der ingen forbindelse at etablere, så begge ender bruger den tilsvarende UDP-transport, og direktivet siger kun, hvor der skal sigtes. Adresseændringer fra en autentificeret peer håndteres af dedikeret adfærd i stedet for ved at tilføje flere poster. At få transporten rigtig er en forudsætning for, at destinationen betyder noget, og at forveksle de to giver konfigurationer, der ser plausible ud og aldrig fuldfører et håndtryk.

Hvorfor en fraværende remote ikke er en åben dør

En proces uden destination afviser stadig trafik fra peers, der ikke autentificerer sig, og det er den del, folk overser, når de læser den manglende linje som en lytter, der er åben for alle.

Autentificering og destination er uafhængige, og den første er den, der betyder noget for tillid.

Den omvendte fejl er farligere. En fast kildeadresse kan føles som adgangskontrol, fordi den er specifik og let at kontrollere, men den beviser intet om, hvem der er i den anden ende. Behold certifikatverifikationen, og behold identitetskontrollerne, der binder et certifikat til dets rolle. At erstatte dem med et adressematch bytter en reel kontrol for udseendet af en.

Skriv ned, hvad konfigurationen forudsætter

For hver side, noter tre ting: hvordan den første pakke når peeren, hvilken side der kan acceptere transporten, og hvad hver side verificerer om den anden.

De antagelser er designet. Direktiverne er kun deres stavemåde.

Hvis de to filer er forskellige, så tjek, om de udtrykker forskellige antagelser i stedet for at antage, at den ene er forkert. Et symmetrisk par filer er hverken nødvendigt eller tilstrækkeligt for en fungerende tunnel, og asymmetrien er ofte den del, der får en topologi til at fungere.