Trenger hver OpenVPN-peer en remote-linje? Ikke helt

To peer-konfigurasjoner sammenlignes side om side, den ene har en remote-linje og den andre ikke, og konklusjonen er at en av dem er ødelagt. Den slutningen er feil ofte nok til å være verdt å pakke ut. Direktivet beskriver hvor den første pakken skal sendes. Det velger ikke om prosessen opptrer som en initierende klient eller en ventende gateway, og det avgjør ikke hvilken side som beviser sin identitet overfor den andre.

Hva remote faktisk angir

En remote-oppføring navngir en vert, eventuelt en port og en transport, og eventuelt flere slike oppføringer som prøves i rekkefølge.

Fraværet har en definert og ikke udefinert betydning: prosessen venter og handler ikke på pakker fra en adresse med mindre den peeren autentiserer seg. En gateway som betjener roaming-brukere har derfor ingen grunn til å navngi noen av dem på forhånd.

Les oppføringen som et adresseforhold. Om den andre enden er til å stole på, besvares av sertifikater og verifiseringsvalgene, ikke av at en adresse ble skrevet ned.

Tre oppsett avgjør svaret

En roaming-klient trenger en destinasjon, fordi den må initiere og ikke aner hvor gatewayen er uten en. En gateway for mange klienter trenger ingen destinasjon per bruker, fordi klientene kommer og autentiserer seg. En bevisst to-peer-forbindelse med kjente endepunkter kan ha en destinasjon på én side, på begge sider eller på ingen, avhengig av hvilken side som initierer.

Å lime en fast klientadresse inn i en generell gateway er feilen som følger av å ignorere disse kategoriene. Den virker for den ene peeren hvis adresse ble registrert, og villeder alle andre.

Ingenting ved direktivet gjør en konfigurasjon til en server for mange klienter, og ingenting ved dets tilstedeværelse hindrer en serverrolle. OpenVPN 2.6-referansen dokumenterer de valgfrie argumentene og oppførselen uten remote hver for seg, noe som er et hint om hvor uavhengige de er.

Transportroller er en annen akse

Med TCP venter den ene siden og den andre ringer. Det er separate direktiver fra destinasjonen, og å blande dem gir et par der begge venter eller begge ringer.

Det finnes også en TCP-kildefilterrolle, og derfor er den flate påstanden om at en server aldri kan inneholde remote feil.

Med UDP er det ingen forbindelse å opprette, så begge ender bruker den tilsvarende UDP-transporten, og direktivet sier bare hvor det skal siktes. Adresseendringer fra en autentisert peer håndteres av dedikert oppførsel i stedet for ved å legge til flere oppføringer. Å få transporten riktig er en forutsetning for at destinasjonen skal bety noe, og å forveksle de to gir konfigurasjoner som ser plausible ut og aldri fullfører et håndtrykk.

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

En prosess uten destinasjon avviser fortsatt trafikk fra peers som ikke autentiserer seg, og det er den delen folk overser når de leser den manglende linjen som en lytter som er åpen for alle.

Autentisering og destinasjon er uavhengige, og den første er den som betyr noe for tillit.

Den motsatte feilen er farligere. En fast kildeadresse kan føles som tilgangskontroll fordi den er spesifikk og lett å kontrollere, men den beviser ingenting om hvem som er i den andre enden. Behold sertifikatverifiseringen, og behold identitetskontrollene som binder et sertifikat til rollen sin. Å erstatte dem med en adressematch bytter en reell kontroll mot utseendet av en.

Skriv ned hva konfigurasjonen forutsetter

For hver side, noter tre ting: hvordan den første pakken når peeren, hvilken side som kan akseptere transporten, og hva hver side verifiserer om den andre.

De forutsetningene er designet. Direktivene er bare stavemåten deres.

Hvis de to filene er forskjellige, sjekk om de uttrykker forskjellige forutsetninger i stedet for å anta at den ene er feil. Et symmetrisk par filer er verken nødvendig eller tilstrekkelig for en fungerende tunnel, og asymmetrien er ofte den delen som får en topologi til å fungere.