Klantboarneport tsjin serversluchter yn in VPN-stream
Fergelykje de twa poartnûmers yn ien tunnel: de fêste sluchter fan de server en de koarte boarne fan de klant, en hoe't routeroersetting tusken har yn sit.
Twa nûmers ferskine yn deselde petear, en gjinien fan beide is ferkeard. De serverlog lit de sluchter sjen dy't de tsjinst oanbiedt, de laptop lit de socket sjen dy't it datagram stjoerd hat, en in router tuskenyn kin it twadde ûnderweis nei bûten oerskriuwe. It fergelykjen fan 'e einen fan 'e petear is better as it fergelykjen fan 'e sifers. De fergeliking hjirûnder hâldt de sluchter, de kliïntsocket en de oerset boarne apart, om't se ferskillende fragen beantwurdzje.
Twa nûmers dy't tsjinoerstelde einen beskriuwe
De konfigurearre poart fan 'e server is de bestimming dêr't de klant hinne belt. Hy wurdt fêstlein troch belied, stiet yn it profyl en moat oan 'e serverkant iepen wêze. De boarneport fan 'e klant wurdt lokaal keazen, meastentiids út it efemêre berik, en bestiet sadat it antwurd earne lânje kin. Hy kin by elke werferbining feroarje, en neat yn it ûntwerp hinget derfan ôf dat er stabyl bliuwt.
In router tuskenyn kin dy boarne oerskriuwe yn syn eigen 'NAT'-mapping. Dêrom hat it nûmer dat op 'e server sjoen wurdt faak gjin ferbân mei dat de laptop keazen hat.
Wêr't it boarnenûmer ûnderweis nei bûten feroaret
Nim in betocht IPv4-foarbyld: in klant efter in oersettende router, in server mei ien 'UDP'-sluchter en ien datagram dat beide krúst. De tabel neamt elk einpunt en wat der mei bart, ynstee fan it pakket op trije observaasjepunten wer te spyljen.
| 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 |
De bestimming is konstant yn elke rige, en allinnich de identiteit fan 'e boarne feroaret. Easken fan UDP NAT ûnderskiede in yntern adres en poart fan 'e eksterne mapping, en dat is krekt it ferskil tusken de twadde en tredde rige. In router kin de boarneport fan 'e klant behâlde of in oare kieze; behâlden is net eat dat in applikaasje oannimme moat.
Lês de trije einpunten fan 'e hosts sels
De listen hjirûnder komme fan trije ferskillende masines en litte tegearre it hiele petear sjen. Rin de earste op 'e server, de twadde op 'e klant en de tredde wêr't de mapping ek bestiet. Ien logrige lit nea alle trije sjen.
ss -lunp 'sport = :1194'
ss -unp | grep 1194
conntrack -L -p udp | grep 1194De earste list bewissiget dat de server oan 'e tsjinstpoart bûn is en lit sjen hokker proses dy besit. De twadde lit de lokale socket fan 'e klant en de bestimming sjen dêr't er hinne belle hat. De tredde lit de mapping sjen dy't de router makke hat, en dat is it iennige plak dêr't de oerset boarne ferskynt. Lês se yn dy folchoarder en de twa nûmers lykje net mear tsjinstridich.
Wat in werferbining feroaret, en wat net
Guon routers hâlde de boarneport fan 'e klant as er frij is, en guon jouwe elk kear in oare. Beide gedrach is normaal, en in applikaasje dy't it earste easket, brekt op it twadde. In feroaring fan mapping nei in werferbining of in netwurkskakeling is gjin serverflater: de klant iepenet in nije socket, de router jout wat er hat, en de server sjocht in nije boarne op deselde sluchter. In flater soe wêze om te ferwachtsjen dat de server ferkear oannimt dat oan in willekeurige klantpoart rjochte is.
Mienskips-OpenVPN-klanten krije dit gedrach troch nobind, dat it bestjoeringssysteem de lokale poart kieze lit; de fiere poart komt noch út it profyl. It eksplisyt binen is in bewuste kar, gjin protokolferplichting. De server bliuwt ien einpunt oanbiede wylst klanten har eigen lokale identiteiten kieze.
Label de lagen apart yn 'e registraasje
Yn 'e tunnel is in twadde petear mei syn eigen poarten. In HTTPS-fersyk dat troch de tunnel droegen wurdt hat bestimming TCP 443, wylst de bûtenste fersifere ferbining UDP 1194 brûkt, dus it feroarjen fan 'e bûtenste boarneport feroaret neat yn 'e binnenste tsjinst.
Sels op 'e bûtenste laach makket it protokol út. UDP 1194 en TCP 1194 binne ferskillende einpunten, en in 'TCP'-sluchter sil nea in UDP-datagram krije om't it nûmer oerienkomt. As jo in útrulling dokumintearje, label dan de serversluchter, de kliïntsocket en de oerset boarne as trije ferskillende dingen, en foegje de transport ta oan elk.
Lit dan belied de rollen folgje. De server iepenet de bedoelde transport op syn sluchter en ferifiearret noch altyd de peer; de firewall fan 'e klant lit antwurden ta op syn eigen útgeande útwikseling sûnder in ynkommende tsjinst te publisearjen. In tastânleaze filter hat de weromrjochting eksplisyt nedich, en dat is de praktyske reden wêrom't it ûnderskie útkomt boppe kreas diagrams.