OpenVPN kaj HTTPS sur pordo 443: kiu posedas la aŭskultanton?

Du servoj povas ambaŭ respondi sur pordo 443 sen iam konkuri, ĉar aŭskultanto estas ŝlosita laŭ transporto, adreso kaj pordo kune, ne laŭ la numero sola. Metu retservilon kaj OpenVPN sur unu maŝinon, kaj la sola demando inda je unua respondo estas, kiun ingon ĉiu procezo petas de la kerno. Skribu tiun liston antaŭ ol redakti agordon, kaj plej multaj eraroj «adreso jam uzata» klarigos sin mem. Ĉio post la listo estas elekto inter UDP-aŭskultanto, komuna TCP-ingo aŭ frontaĵo, kiu enkursigas laŭ protokolo.

Komencu per la ingo, kiun petas ĉiu procezo

Bind sukcesas aŭ malsukcesas laŭ tiu triopo, do du demonoj kolizias nur kiam ĉiuj tri partoj koincidas. Tial retejo sur TCP 443 kunekzistas senfine kun OpenVPN-aŭskultanto sur UDP 443, kaj tial movi unu el ili al dua loka adreso sur la sama gastiganto ankaŭ finas la disputon. Legu la vivajn aŭskultantojn anstataŭ la dosierojn, kiuj laŭsupoze kreis ilin, ĉar malnova include aŭ forgesita unuodosiero pluvivas la redakton, kiun vi memoras fari.

Rulu ss -lntup kiel root kaj legu ĉiun linion, kiu mencias 443, inkluzive de IPv6-eroj. Ĝentipa aŭskultanto por v6 kutime ankaŭ akceptas v4-trafikon, kaj tiel aŭskultanto, kiun vi forgesis, tenas la pordon okupata post kiam vi ŝanĝas la dosieron, kiun vi kredis respondeca. Se proceza nomo surprizas vin, mallarĝigu la eligon per ss -lntup 'sport = :443' antaŭ ol tuŝi ion ajn.

Ŝaltu la tunelon al UDP, kiam la reto permesas

UDP-aŭskultanto tute evitas la kolizion kaj kutime estas la plej mallonga riparo, ĉar neniu ingo estas kunhavigata kaj neniu aldona produkto aliĝas al la vojo. Sed ĝi ne estas senpaga. Iuj klientaj retoj forĵetas UDP 443 sen sendi reset, do la tunelo ĉesas establiĝi anstataŭ malsukcesi ĉe bind, kaj la uzanto raportas la VPN kiel nefunkcianta sen iu eraro legebla. UDP-aŭskultanto ankaŭ pluvivas restartigon de la reta tavolo, kio gravas sur maŝino, kies retejo ofte reeldoniĝas. Testu el la reto, kie sidas la uzantoj, ĉar ŝelo sur la servilo nur pruvas, ke la servilo povas atingi sin mem.

Ŝanĝu la transporton en la servila agordo kaj en la klienta profilo kune. Profilo, kiu ankoraŭ petas TCP, rondiĝos tra rekonektoj kontraŭ aŭskultanto nur-UDP, kaj tio aspektas kiel reta paneo, ĝis vi komparos la du dosierojn.

Lasu la VPN-procezon posedi TCP 443 kaj plusendu la reston

Community OpenVPN en TCP-servila reĝimo legas la unuajn bajtojn de envenanta konekto kaj plusendas ĉion, kio ne estas ĝia propra protokolo, al HTTPS-malantaŭo, kaj por tio estas la direktivo port-share. La malantaŭo estas ordinara retservilo kun TLS ebligita, nomita per gastiganto kaj pordo en tiu direktivo, ne per URL.

port-share 10.0.0.5 8080

Sur maŝino, kie la retejo tenas duan privatan adreson, tiu linio sendas ne-VPN-an trafikon al 10.0.0.5:8080, do la HTTPS-virtuala gastiganto devas esti ligita tie kaj la fajroŝirmilo devas permesi la lokan salton. La retservilo devas mem fini TLS, ĉar la alvenantaj bajtoj estas la origina manpremo de la retumilo kaj nenio intere malkriptigis ilin. Direktu la direktivon al ordinara HTTP-aŭskultanto kaj la retumilo ricevas eraron de nevalida metodo, kiu legiĝas kiel rompita retejo anstataŭ kiel mislokita malantaŭo. La direktivo ekzistas nur en TCP-servila reĝimo, kaj UDP-aŭskultanto havas neniun fluon por inspekti.

Ĉar la VPN-procezo akceptas ĉiun konekton, la reta aplikaĵo vidas la plusenditan peton alveni de unu el la propraj adresoj de la gastiganto anstataŭ de la vizitanto. Ĉio, kio bezonas la veran klientan adreson, dependas de PROXY-protokola subteno en la malantaŭo aŭ de frontaĵo, kiu aldonas ĝin. Movi la malantaŭon al alia loka adreso ne redonas la adreson de la vizitanto; ĝi nur ŝanĝas, kiun el la adresoj de la gastiganto la retejo registras. Notu tiun limigon en la surlokaj notoj antaŭ ol analiza raporto starigos la demandon.

Inversa prokuro estas la malĝusta ilo; tavolo-kvara enkursigilo ne

HTTP-inversa prokuro finas TLS por povi legi petojn, kio signifas, ke ĝi ne povas trapasi OpenVPN-fluon netuŝite. Tavolo-kvara enkursigilo, kiu plusendas laŭ SNI aŭ laŭ inspekto de la unua paketo, povas stari antaŭ ambaŭ, kondiĉe ke ĝi ne finas la seancon, de kiu la VPN dependas. La du aparatoj aspektas similaj en diagramo kaj kondutas tute alie ĉe la ingo.

Komerca Access Server venas kun propraj agordoj de pordkunhavigo, kaj tiuj ne mapiĝas unu-al-unu al la komunuma direktivo. Identigu la produkton kaj version antaŭ ol adapti gvidilon skribitan por la alia. Kopiita agordo, kiu estas silente ignorata, estas pli malbona ol nenia agordo, ĉar la aŭskultanta listo poste ankoraŭ aspektas kredinda.

Testu la retejon kaj la tunelon kiel du apartajn vojojn

Ŝargu la retejon kaj konektu la tunelon, poste legu la aŭskultantan liston denove por vidi, kiu procezo nun posedas 443. Paĝo, kiu ŝargiĝas, pruvas nenion pri la VPN, kaj tunelo, kiu konektiĝas, pruvas nenion pri la retejo, kvankam ambaŭ uzas la saman numeron. La tri komandoj sube kontrolas la komunan ingon, la retan vojon kaj la VPN-servon en tiu ordo.

ss -lntup 'sport = :443'
curl -sI https://vpn.example.com/ | head -n 1
journalctl -u openvpn-server@server -n 20

Komparu la klientan adreson en la alira protokolo de la malantaŭo kun tiu en la VPN-protokolo por la sama momento. Se la retejo registras ĉiun vizitanton kiel la gastiganton mem, la plusendo funkcias kaj la adresa traktado ne. Se ambaŭ protokoloj silentas, la frontaĵo neniam transdonis la konekton. Ĉiel ajn, la aŭskultanta listo decidas, kiu akceptas la ingon, kaj tio estas la fakto konfirmenda antaŭ ol vi ŝanĝos alian dosieron.

Lasu tiun aŭskultantan mapon apud la agordo, por ke la sekva persono, kiu tuŝos 443, sciu, kiu procezo akceptas kaj kien iris la alia protokolo. Konfirmu posedon post la ŝanĝo anstataŭ fidi tion, kion la redakto intencis fari.