Kjeldeporten til klienten mot lyttaren til tenaren i ein VPN-straum
Samanlikn dei to portnummera i ein tunnel: den faste lyttaren til tenaren og den kortvarige kjelda til klienten, og korleis rutaromsetjinga ligg mellom dei.
To tal dukkar opp i same samtale, og ingen av dei er feil. Tenarloggen viser lyttaren som tilbyr tenesta, laptopen viser sockelen som sende datagrammet, og ein ruter imellom kan skrive om den andre på veg ut. Det er meir nyttig å samanlikne endane av samtalen enn å samanlikne sifra. Samanlikninga nedanfor held lyttaren, klienten sin sockel og den omsette kjelda fråskilde, fordi dei svarar på ulike spørsmål.
To tal som skildrar motsette endar
Den konfigurerte porten til tenaren er destinasjonen klienten ringjer til. Han er fastsett av policy, står i profilen og må vere open på tenarsida. Kjeldeporten til klienten blir vald lokalt, vanlegvis frå det efemære området, og finst for at svaret skal ha ein stad å lande. Han kan endre seg ved kvar gjenoppkopling, og ingenting i designet er avhengig av at han er stabil.
Ein ruter imellom kan skrive om den kjelda til si eiga 'NAT'-mapping. Derfor har talet som blir observert på tenaren ofte ingen relasjon til det laptopen valde.
Kvar kjeldenummeret endrar seg på veg ut
Ta eit oppdikta IPv4-døme: ein klient bak ein omsetjande ruter, ein tenar med éin 'UDP'-lyttar og eitt datagram som kryssar begge. Tabellen namngjev kvart endepunkt og kva som skjer med det, i staden for å spele av pakken på tre observasjonspunkt.
| 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 |
Destinasjonen er konstant i kvar rad, og berre identiteten til kjelda endrar seg. Krav til UDP NAT skil mellom ei intern adresse og port og den eksterne mappinga, som er nøyaktig skilnaden mellom andre og tredje rad. Ein ruter kan halde på kjeldeporten til klienten eller velje ein annan; bevaring er ikkje noko ein applikasjon bør føresette.
Les dei tre endepunkta frå vertane sjølve
Listene nedanfor kjem frå tre ulike maskinar og viser saman heile samtalen. Køyr den første på tenaren, den andre på klienten og den tredje der mappinga finst. Éi logglinje viser aldri alle tre.
ss -lunp 'sport = :1194'
ss -unp | grep 1194
conntrack -L -p udp | grep 1194Den første lista beviser at tenaren er bunden til tenesteporten og viser kva prosess som eig han. Den andre viser den lokale sockelen til klienten og destinasjonen han ringde. Den tredje viser mappinga ruteren oppretta, og det er den einaste staden den omsette kjelda viser seg. Les dei i den rekkjefølgja, og dei to tala sluttar å sjå motstridande ut.
Kva ei gjenoppkopling endrar, og kva ho ikkje endrar
Nokre rutarar held på kjeldeporten til klienten når han er ledig, og andre tildeler ein annan kvar gong. Begge åtferdene er normale, og ein applikasjon som krev den første, vil bryte saman på den andre. Ei endring av mapping etter ei gjenoppkopling eller eit nettverksbyte er ikkje ein tenarfeil: klienten opnar ein ny sockel, ruteren tildeler det han har, og tenaren ser ei ny kjelde på same lyttaren. Ein feil ville vere å vente at tenaren godtek trafikk adressert til ein vilkårleg klientport.
Fellesskapets OpenVPN-klientar får denne åtferda gjennom nobind, som lèt operativsystemet velje den lokale porten; fjernporten kjem framleis frå profilen. Å binde eksplisitt er eit medvite val, ikkje eit protokollkrav. Tenaren held fram med å tilby eitt endepunkt medan klientane vel sine eigne lokale identitetar.
Merk laga kvar for seg i registreringa
Inne i tunnelen er det ein andre samtale med eigne portar. Ein HTTPS-førespurnad som tunnelen ber, har destinasjon TCP 443, medan den ytre krypterte sambindinga brukar UDP 1194, så endring av den ytre kjeldeporten endrar ingenting i den indre tenesta.
Sjølv på det ytre laget betyr protokollen noko. UDP 1194 og TCP 1194 er ulike endepunkt, og ein 'TCP'-lyttar vil aldri ta imot eit UDP-datagram fordi talet stemmer. Når du dokumenterer ein utrulling, merk lyttaren til tenaren, sockelen til klienten og den omsette kjelda som tre ulike ting, og legg til transporten på kvar.
Lat så policyen følgje rollene. Tenaren opnar den tiltenkte transporten på lyttaren sin og autentiserer framleis motparten; brannmuren til klienten slepp inn svar på si eiga utgåande utveksling utan å publisere ei inngåande teneste. Eit tilstandslaus filter treng returretninga skriven ut eksplisitt, og det er den praktiske grunnen til at skiljet betyr noko utover ryddige diagram.