Ĉu ĉiu OpenVPN-peer bezonas linion remote? Ne tute
remote diras, kien iras la unua paketo; ĝi ne elektas la rolon de kliento, servilo aŭ TLS. Legu la aranĝon antaŭ ol kopii ĝin al ambaŭ flankoj.
Du peer-agordoj estas komparataj flanke al flanke, unu havas linion remote kaj la alia ne, kaj la konkludo estas, ke unu el ili estas rompita. Tiu konkludo estas sufiĉe ofte malĝusta por esti inda je analizo. La direktivo priskribas, kien la unua paketo estu sendita. Ĝi ne elektas, ĉu la procezo agas kiel komencanta kliento aŭ kiel atendanta enirejo, kaj ĝi ne decidas, kiu flanko pruvas sian identecon al la alia.
Kion remote fakte specifas
remote-ero nomas gastiganton, laŭeble pordon kaj transporton, kaj laŭeble plurajn tiajn erojn provotajn laŭvice.
Ĝia foresto havas difinitan signifon, ne nedifinitan: la procezo atendas kaj ne agas pri paketoj de adreso krom se tiu peer aŭtentikigas. Enirejo servanta migrantajn uzantojn do ne havas kialon nomi iun el ili anticipe.
Legu la eron kiel adresan rilaton. Ĉu la fora fino estas fidinda, respondas atestiloj kaj la kontrolaj opcioj, ne la fakto, ke adreso estis skribita.
Tri aranĝoj decidas la respondon
Migranta kliento bezonas celon, ĉar ĝi devas komenci kaj sen ĝi ne scias, kie la enirejo estas. Enirejo por multaj klientoj ne bezonas celon por uzanto, ĉar klientoj alvenas kaj aŭtentikigas. Intenca ligo inter du peer kun konataj finpunktoj povas havi celon unuflanke, ambaŭflanke aŭ neniufanke, laŭ tio, kiu flanko komencas.
Alglui fiksan klientan adreson en ĝeneralan enirejon estas la eraro, kiu sekvas el ignorado de tiuj kategorioj. Ĝi funkcias por la sola peer, kies adreso estis registrita, kaj misgvidas ĉiujn aliajn.
Nenio en la direktivo igas agordon servilon por multaj klientoj, kaj nenio en ĝia ĉeesto malhelpas servilan rolon. La OpenVPN 2.6-referenco dokumentas la laŭvolajn argumentojn kaj la konduton sen remote aparte, kio estas aludo al tio, kiom sendependaj ili estas.
| 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 |
Transportaj roloj estas alia akso
Ĉe TCP unu flanko atendas kaj la alia vokas. Tiuj estas apartaj direktivoj de la celo, kaj miksi ilin produktas paron, kiu aŭ ambaŭ atendas aŭ ambaŭ vokas.
Ekzistas ankaŭ rolo de TCP-fontofiltro, pro kio la plata aserto, ke servilo neniam rajtas enhavi remote, estas malĝusta.
Ĉe UDP ne estas konekto establenda, do ambaŭ finoj uzas la respondan UDP-transporton kaj la direktivo nur diras, kien celi. Adresŝanĝoj de aŭtentikigita peer estas traktataj de dediĉita konduto anstataŭ per aldono de pliaj eroj. Ĝuste agordi la transporton estas antaŭkondiĉo por ke la celo signifu ion, kaj konfuzi la du kreas agordojn, kiuj aspektas kredeblaj kaj neniam kompletigas manpremon.
Kial forestanta remote ne estas malfermita pordo
Procezo sen celo tamen rifuzas trafikon de peer, kiuj ne aŭtentikigas, kaj tio estas la parto, kiun homoj maltrafas, kiam ili legas la forestantan linion kiel aŭskultanton malfermitan al ĉiuj.
Aŭtentikigo kaj celo estas sendependaj, kaj la unua estas tiu, kiu gravas por fido.
La inversa eraro estas pli danĝera. Fiksa fontadreso povas sentiĝi kiel alirkontrolo, ĉar ĝi estas specifa kaj facile kontrolebla, sed ĝi pruvas nenion pri tio, kiu estas ĉe la alia fino. Konservu la atestilan kontrolon kaj la identeckontrolojn, kiuj ligas atestilon al ĝia rolo. Anstataŭigi ilin per adresa kongruo interŝanĝas realan kontrolon kontraŭ ĝia aspekto.
Skribu, kion la agordo supozas
Por ĉiu flanko, notu tri aferojn: kiel la unua paketo atingas la peer, kiu flanko povas akcepti la transporton, kaj kion ĉiu flanko kontrolas pri la alia.
Tiuj supozoj estas la dezajno. La direktivoj estas nur ilia literumado.
Se la du dosieroj malsamas, kontrolu, ĉu ili esprimas malsamajn supozojn anstataŭ supozi, ke unu estas malĝusta. Simetria paro de dosieroj estas nek necesa nek sufiĉa por funkcianta tunelo, kaj la nesimetrio ofte estas la parto, kiu igas topologion funkcii.