proto udp aŭ tcp-client: kiun aŭdas via servilo?
La direktivo difinas la transporton por la ekstera konekto. Redakti ĝin loke ne povas krei aŭskultanton sur la servilo, do unue kontrolu la remote-rikordon.
Profilo, kiu funkciis pasintmonate, nun finiĝas pro tempo limo, kaj iu proponas ŝanĝi proto udp al proto tcp-client. Kelkfoje tio estas la ĝusta paŝo, kaj kelkfoje ĝi kreas klienton, kiu konektiĝas al pordo, kie nenio aŭskultas, ĉar la servilo neniam estis agordita por la alia transporto. La direktivo priskribas, kiel via flanko parolas; ĝi ne povas krei aŭskultanton ĉe la alia flanko. Legu la profilon kaj la servilon kune antaŭ ol ŝanĝi iun el ili.
Legu la transporton, kiun uzas la elektita konekto
Profilo povas enhavi plurajn remote-rikordojn, kaj ĉiu povas nomi sian propran transporton. La kliento trairas ilin laŭ ordo, do la linio, kiun vi vidas unue, ne nepre estas la valida.
Trovu la rikordon, kiun oni efektive provas, poste legu ĝian transporton. La ordo gravas, ĉar la kliento ne transiras silente. Kelkaj konstruoj provas la sekvan rikordon nur post tempolimo, do funkcianta alternativo ĉe la fino de la dosiero atingiĝas sekundojn poste ol vi atendas. Observu en la protokolo, kiun finpunkton oni provas, anstataŭ supozi, ke la unua linio venkis.
Se la dosiero havas unu proto-linion proksime al la supro kaj plurajn remote-rikordojn sub ĝi, tiu linio estas la defaŭlto por ĉiu remote, kiu ne superregas ĝin. Loka ŝanĝo de la defaŭlto faras nenion por remote-rikordo, kiu nomas sian propran transporton.
grep -nE '^(remote|proto)\b' client.ovpnUDP kaj TCP ne estas rapidagordo
UDP sendas datagramojn sen konstrui ordigitan fluon, do la propra trafiko de la tunelo ne estas volvita en duan fidindan transporton. TCP donas al vi vojon tra retoj, kiuj faligas aŭ blokas UDP, kontraŭ la kosto de nestita retranssendado, kiu povas igi perdan ligon sentiĝi pli malbona.
Tio estas kompromiso pri atingeblo, ne universala rango. La ĝusta elekto estas tiu, kiun la reto antaŭ la kliento permesas. Vojo, kiu faligas UDP ĉe la VPN-pordo, neniam traktatos, kiom ajn bone la profilo estas skribita. Testu la vojon, poste elektu la transporton.
Elekti inter ili sole laŭ mezuro estas eraro, ĉar la respondo dependas de tio, kion la reto antaŭ vi permesas. Hotelo aŭ entreprena prokura servilo eble permesas eliran TCP ĉe pordo 443 kaj nenion alian, tial provizantoj ofertas tiun varianton. Ĝi restas OpenVPN-konekto ĉe tiu pordo, ne HTTPS-sesio, eĉ se la pordan numero estas la konata.
Kion tcp-client efektive signifas
La direktivo ĉe la klienta flanko nomas la komencan finon de TCP-konekto. La servila flanko uzas sian propran aŭskultan formon, kaj kopii la vorton de la kliento en servilan agordon kreas aŭskultanton, kiu atendas esti vokata, ne unu, kiu akceptas.
Kongrui signifas, ke la du finoj konsentas pri la transporto, ne ke ili dividas la saman ĉenon.
grep -nE '^proto\b' /etc/openvpn/server/server.conf
ss -lntp | grep openvpnDemandu la servilon, kion ĝi aŭskultas, antaŭ ol supozi, ke la profilo malĝustas. UDP-aŭskultanto ne aperas en TCP-inga listo, kaj la malo ankaŭ veras, do rigardu la protokol-specifan vidon anstataŭ ĝeneralan.
Kiam la profilo importiĝas sed neniam konektiĝas
Importita profilo, kiu tuj finiĝas pro tempolimo, kutime malsukcesas antaŭ iu ajn aŭtentigo. La paketo iras al pordo sen aŭskultanto, aŭ la reto faligas ĝin silente.
Testu la vojon la plej simple eble: konektiĝu al la sama gastiganto kaj pordo kun la transporto, kiun la profilo asertas, el la sama reto kiel la malsukcesa kliento.
Se UDP-testo ricevas nenion kaj TCP-testo konektiĝas, la servilo proponas la alian transporton kaj la profilo simple malaktualiĝis. Se neniu respondas, la problemo estas pli supre ol la transporta elekto kaj neniu redakto de la profilo riparos ĝin. Distingi tiujn du kazojn daŭras minuton kaj ŝparas horon da sencimigado de atestiloj, kiu neniam estis grava.
Notu la funkciantan transporton
Iam kombinado funkcias, skribu ĝin kun la servilo, pordo kaj protokolo, kaj notu, el kiu reto ĝi estis testita.
Alie la sekva persono, kiu trafos tempolimon, provos la saman eksperimenton en la alia direkto, kaj eble ŝanĝos servilon, kiu estis bona.
Se la provizanto publikigas ambaŭ variantojn, konservu ambaŭ dosierojn kaj etikedu ilin laŭ la reto, al kiu ili taŭgas. Du klare nomitaj profiloj malhelpas la hazardan miksadon de klienta transporto kun servila aŭskultanto, kiu neniam estis agordita por ĝi.