Treng kvar OpenVPN-peer ei remote-linje? Ikkje heilt

To peer-konfigurasjonar blir samanlikna side om side, den eine har ei remote-linje og den andre ikkje, og konklusjonen er at ein av dei er øydelagd. Den slutninga er feil ofte nok til å vere verdt å pakke ut. Direktivet skildrar kvar den første pakken skal sendast. Det vel ikkje om prosessen opptrer som ein initierande klient eller ein ventande gateway, og det avgjer ikkje kva side som provar identiteten sin overfor den andre.

Kva remote faktisk angir

Ei remote-oppføring nemner ein vert, eventuelt ein port og ein transport, og eventuelt fleire slike oppføringar som blir prøvde i rekkjefølgje.

Fraværet har ei definert og ikkje udefinert meining: prosessen ventar og handlar ikkje på pakkar frå ei adresse med mindre den peeren autentiserer seg. Ein gateway som tener roaming-brukarar har derfor ingen grunn til å nemne nokon av dei på førehand.

Les oppføringa som eit adressetilhøve. Om den andre enden er til å stole på, blir svara av sertifikat og verifiseringsvala, ikkje av at ei adresse vart skriven ned.

Tre oppsett avgjer svaret

Ein roaming-klient treng ein destinasjon, fordi han må initiere og ikkje veit kvar gatewayen er utan ein. Ein gateway for mange klientar treng ingen destinasjon per brukar, fordi klientane kjem og autentiserer seg. Ei medvite to-peer-samband med kjende endepunkt kan ha ein destinasjon på éi side, på begge sider eller på inga, avhengig av kva side som initierer.

Å lime ei fast klientadresse inn i ein generell gateway er feilen som følgjer av å ignorere desse kategoriane. Han verkar for den eine peeren kvar adresse vart registrert, og villeder alle andre.

Ingenting ved direktivet gjer ein konfigurasjon til ein tenar for mange klientar, og ingenting ved tilstadeværet hindrar ei tenarrolle. OpenVPN 2.6-referansen dokumenterer dei valfrie argumenta og åtferda utan remote kvar for seg, noko som er eit hint om kor uavhengige dei er.

Transportroller er ein annan akse

Med TCP ventar den eine sida og den andre ringjer. Det er separate direktiv frå destinasjonen, og å blande dei gjev eit par der begge ventar eller begge ringjer.

Det finst òg ei TCP-kjeldefilterrolle, og difor er den flate påstanden om at ein tenar aldri kan innehalde remote feil.

Med UDP er det inga sambinding å opprette, så begge endar brukar den tilsvarande UDP-transporten, og direktivet seier berre kvar det skal siktast. Adresseendringar frå ein autentisert peer blir handsama av dedikert åtferd i staden for ved å leggje til fleire oppføringar. Å få transporten riktig er ein føresetnad for at destinasjonen skal bety noko, og å blande dei to gjev konfigurasjonar som ser trulege ut og aldri fullfører eit handtrykk.

Kvifor ein fråverande remote ikkje er ei open dør

Ein prosess utan destinasjon avviser framleis trafikk frå peers som ikkje autentiserer seg, og det er den delen folk overser når dei les den manglande linja som ein lyttar som er open for alle.

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

Den motsette feilen er farlegare. Ei fast kjeldeadresse kan kjennast som tilgangskontroll fordi ho er spesifikk og lett å kontrollere, men ho provar ingenting om kven som er i den andre enden. Hald på sertifikatverifiseringa, og hald på identitetskontrollane som bind eit sertifikat til rolla si. Å erstatte dei med ein adressematch byter ein reell kontroll mot utsjånaden av ein.

Skriv ned kva konfigurasjonen føreset

For kvar side, noter tre ting: korleis den første pakken når peeren, kva side som kan akseptere transporten, og kva kvar side verifiserer om den andre.

Dei føresetnadene er designet. Direktiva er berre stavemåten deira.

Viss dei to filene er ulike, sjekk om dei uttrykkjer ulike føresetnader i staden for å anta at den eine er feil. Eit symmetrisk par filer er korkje naudsynt eller tilstrekkeleg for ein fungerande tunnel, og asymmetrien er ofte den delen som får ein topologi til å fungere.