Klienta fonta pordo kontraŭ servila aŭskultanto en VPN-fluo
Komparu la du pordnumerojn en unu tunelo: la fiksan aŭskultanton de la servilo kaj la efemeran fonton de la kliento, kaj kiel la traduko de la enkursigilo situas inter ili.
Du numeroj aperas en la sama konversacio, kaj nek unu el ili estas malĝusta. La servila protokolo montras la aŭskultanton, kiu proponas la servon, la tekkomputilo montras la soketon, kiu sendis la datagramon, kaj enkursigilo intere povas reverki la duan survoje eksteren. Kompari la finojn de la konversacio pli utilas ol kompari la ciferojn. La komparo sube tenas aparte la aŭskultanton, la klientan soketon kaj la tradukitan fonton, ĉar ili respondas malsamajn demandojn.
Du numeroj, kiuj priskribas kontraŭajn finojn
La agordita pordo de la servilo estas la celo, kiun la kliento vokas. Ĝin fiksas politiko, ĝi aperas en la profilo, kaj ĝi devas esti malfermita ĉe la servila flanko. La fonta pordo de la kliento elektiĝas loke, kutime el la efemera intervalo, kaj ekzistas por ke la respondo havu lokon por alveni. Ĝi povas ŝanĝiĝi ĉe ĉiu rekonekto, kaj nenio en la dezajno dependas de tio, ke ĝi restu stabila.
Enkursigilo intere povas reverki tiun fonton en sian propran 'NAT'-mapadon. Tial la numero observata ĉe la servilo ofte havas neniun rilaton al tiu, kiun la tekkomputilo elektis.
Kie la fonta numero ŝanĝiĝas survoje eksteren
Prenu elpensitan IPv4-ekzemplon: kliento malantaŭ tradukanta enkursigilo, servilo kun unu 'UDP'-aŭskultanto, kaj unu sola datagramo trapasanta ambaŭ. La tabelo nomas ĉiun finpunkton kaj kio okazas al ĝi, anstataŭ reludi la paketon ĉe tri observpunktoj.
| Endpoint | What stays fixed | What changes on reconnect | Who owns it |
|---|---|---|---|
| Server listener | The service port and the address the profile names | Nothing; the listener does not follow the client | The server operator |
| Client socket | The destination it dials | The local source port, chosen per socket | The client, or its operating system |
| Translated source | Usually the public address of the router | The port, and sometimes the address after a network switch | The NAT device or the upstream carrier |
La celo estas konstanta en ĉiu vico, kaj nur la identeco de la fonto ŝanĝiĝas. Postuloj de UDP NAT distingas internan adreson kaj pordon de la ekstera mapado, kio estas ĝuste la diferenco inter la dua kaj la tria vicoj. Enkursigilo povas konservi la fontan pordon de la kliento aŭ elekti alian; konservado ne estas io, kion aplikaĵo devus supozi.
Legu la tri finpunktojn el la gastigantoj mem
La listoj sube venas el tri malsamaj maŝinoj, kaj kune ili montras la tutan konversacion. Rulu la unuan ĉe la servilo, la duan ĉe la kliento, kaj la trian tie, kie la mapado ekzistas. Unu protokola linio neniam montras ĉiujn tri.
ss -lunp 'sport = :1194'
ss -unp | grep 1194
conntrack -L -p udp | grep 1194La unua listo pruvas, ke la servilo estas ligita al la serva pordo, kaj montras, kiu procezo posedas ĝin. La dua montras la lokan soketon de la kliento kaj la celon, kiun ĝi vokis. La tria montras la mapadon kreitan de la enkursigilo, kaj tio estas la sola loko, kie la tradukita fonto aperas. Legu ilin laŭ tiu ordo, kaj la du numeroj ĉesas aspekti kontraŭdiraj.
Kion rekonekto ŝanĝas, kaj kion ne
Iuj enkursigiloj konservas la fontan pordon de la kliento, kiam ĝi estas libera, kaj iuj ĉiufoje asignas alian. Ambaŭ kondutoj estas normalaj, kaj aplikaĵo, kiu postulas la unuan, rompiĝos ĉe la dua. Ŝanĝo de mapado post rekonekto aŭ retŝanĝo ne estas servila fuŝo: la kliento malfermas novan soketon, la enkursigilo asignas tion, kion ĝi havas, kaj la servilo vidas novan fonton ĉe la sama aŭskultanto. Fuŝo estus atendi, ke la servilo akceptu trafikon adresitan al arbitra klienta pordo.
Komunumaj OpenVPN-klientoj ricevas ĉi tiun konduton per nobind, kio lasas al la operaciumo la elekton de la loka pordo; la fora pordo ankoraŭ venas el la profilo. Eksplicita ligado estas konscia elekto, ne postulo de la protokolo. La servilo daŭre proponas unu finpunkton, dum klientoj elektas siajn proprajn lokajn identecojn.
Marku la tavolojn aparte en la registro
Ene de la tunelo estas dua konversacio kun propraj pordoj. HTTPS-peto portata de la tunelo havas celon TCP 443, dum la ekstera ĉifrita konekto uzas UDP 1194, do ŝanĝo de la ekstera fonta pordo ŝanĝas nenion en la interna servo.
Eĉ ĉe la ekstera tavolo la protokolo gravas. UDP 1194 kaj TCP 1194 estas malsamaj finpunktoj, kaj 'TCP'-aŭskultanto neniam ricevos UDP-datagramon nur ĉar la numero kongruas. Kiam vi dokumentas starigon, marku la servilan aŭskultanton, la klientan soketon kaj la tradukitan fonton kiel tri apartajn aferojn, kaj aldonu la transporton al ĉiu.
Poste lasu la politikon sekvi la rolojn. La servilo malfermas la celatan transporton ĉe sia aŭskultanto kaj ankoraŭ aŭtentigas la partneron; la fajroŝirmilo de la kliento akceptas respondojn al sia propra elira interŝanĝo sen publikigi eniran servon. Senstata filtrilo bezonas eksplicite skribitan revenan direkton, kaj tio estas la praktika kialo, kial la distingo gravas preter ordigitaj diagramoj.