Kliëntbronpoort teenoor bedienerluisteraar in 'n VPN-vloei
Vergelyk die twee poortnommers in een tonnel: die bediener se vaste luisteraar en die kliënt se kortstondige bron, en hoe 'n routervertaling tussen hulle sit.
Twee nommers verskyn in dieselfde gesprek, en nie een van hulle is verkeerd nie. Die bedienerlog wys die luisteraar wat die diens aanbied, die skootrekenaar wys die sokkel wat die datagram gestuur het, en 'n router tussenin kan die tweede een op pad uit herskryf. Dit is nuttiger om die punte van die gesprek te vergelyk as om die syfers te vergelyk. Die vergelyking hieronder hou die luisteraar, die kliëntsokkel en die vertaalde bron apart, want hulle beantwoord verskillende vrae.
Twee nommers wat teenoorgestelde punte beskryf
Die bediener se gekonfigureerde poort is die bestemming wat die kliënt skakel. Dit word deur beleid vasgestel, verskyn in die profiel en moet aan die bedienerkant oop wees. Die kliënt se bronpoort word plaaslik gekies, gewoonlik uit die kortstondige reeks, en bestaan sodat die antwoord êrens kan land. Dit kan by elke herverbinding verander, en niks in die ontwerp hang daarvan af dat dit stabiel bly nie.
'n Router tussenin kan daardie bron in sy eie 'NAT'-kartering herskryf. Daarom het die nommer wat by die bediener waargeneem word dikwels geen verband met die een wat die skootrekenaar gekies het nie.
Waar die brornommer op pad uit verander
Neem 'n uitgedinkte IPv4-voorbeeld: 'n kliënt agter 'n vertalende router, 'n bediener met een 'UDP'-luisteraar, en 'n enkele datagram wat albei kruis. Die tabel noem elke eindpunt en wat daarmee gebeur, eerder as om die pakket by drie waarnemingspunte oor te speel.
| 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 |
Die bestemming is konstant in elke ry, en net die bronidentiteit verander. Die UDP-NAT-vereistes onderskei 'n interne adres en poort van die eksterne kartering, wat presies die gaping tussen die tweede en derde ry is. 'n Router kan die kliënt se bronpoort behou of 'n ander een kies; behoud is nie iets wat 'n toepassing moet aanneem nie.
Lees die drie eindpunte by die gashere self
Die lyste hieronder kom van drie verskillende masjiene, en saam wys hulle die hele gesprek. Voer die eerste op die bediener uit, die tweede op die kliënt, en die derde waar die kartering ook al bestaan. 'n Enkele logreël wys nooit al drie nie.
ss -lunp 'sport = :1194'
ss -unp | grep 1194
conntrack -L -p udp | grep 1194Die eerste lys bewys die bediener is aan die dienspoort gebind en wys watter proses dit besit. Die tweede wys die kliënt se plaaslike sokkel en die bestemming wat dit geskakel het. Die derde wys die kartering wat die router geskep het, wat die enigste plek is waar die vertaalde bron verskyn. Lees hulle in daardie volgorde en die twee nommers lyk nie meer teenstrydig nie.
Wat 'n herverbinding verander, en wat nie
Sommige routers behou die kliënt se bronpoort wanneer dit vry is, en sommige ken elke keer 'n ander een toe. Albei gedrag is normaal, en 'n toepassing wat die eerste vereis, sal op die tweede breek. 'n Verandering van kartering ná 'n herverbinding of 'n netwerkskakeling is nie 'n bedienerfout nie: die kliënt open 'n nuwe sokkel, die router ken toe wat hy het, en die bediener sien 'n nuwe bron op dieselfde luisteraar. Wat 'n fout sou wees, is om te verwag dat die bediener verkeer na 'n willekeurige kliëntpoort aanvaar.
Gemeenskaps-OpenVPN-kliënte kry hierdie gedrag deur nobind, wat die bedryfstelsel die plaaslike poort laat kies; die afgeleë poort kom steeds uit die profiel. Om dit uitdruklik te bind is 'n doelbewuste keuse, nie 'n protokolvereiste nie. Die bediener hou aan om een eindpunt aan te bied terwyl kliënte hul eie plaaslike identiteite kies.
Benoem die vlakke afsonderlik in die rekord
Binne die tonnel is daar 'n tweede gesprek met sy eie poorte. 'n HTTPS-versoek wat deur die tonnel gedra word, het bestemming TCP 443, terwyl die buitenste geënkripteerde verbinding UDP 1194 gebruik, so 'n verandering van die buitenste bronpoort verander niks aan die binneste diens nie.
Selfs op die buitenste vlak maak die protokol saak. UDP 1194 en TCP 1194 is verskillende eindpunte, en 'n 'TCP'-luisteraar sal nooit 'n UDP-datagram ontvang omdat die nommer ooreenstem nie. Wanneer 'n ontplooiing gedokumenteer word, benoem die bedienerluisteraar, die kliëntsokkel en die vertaalde bron as drie afsonderlike dinge, en voeg die transport by elkeen.
Laat dan beleid die rolle volg. Die bediener open die bedoelde transport op sy luisteraar en verifieer steeds die eweknie; die kliënt se vuurmuur laat antwoorde op sy eie uitgaande uitruiling toe sonder om 'n inkomende diens te publiseer. 'n Toestandlose filter het sy terugrigting eksplisiet nodig, wat die praktiese rede is waarom die onderskeid saak maak buite netjiese diagramme.