To tall dukker opp i samme samtale, og ingen av dem er feil. Serverloggen viser lytteren som tilbyr tjenesten, laptopen viser sockelen som sendte datagrammet, og en ruter imellom kan skrive om den andre på vei ut. Det er mer nyttig å sammenligne endene av samtalen enn å sammenligne sifrene. Sammenligningen nedenfor holder lytteren, klientens sockel og den oversatte kilden atskilt, fordi de svarer på forskjellige spørsmål.

To tall som beskriver motsatte ender

Serverens konfigurerte port er destinasjonen klienten ringer til. Den er fastsatt av policy, står i profilen og må være åpen på serversiden. Klientens kildeport velges lokalt, vanligvis fra det efemære området, og finnes for at svaret skal ha et sted å lande. Den kan endre seg ved hver gjenoppkobling, og ingenting i designet avhenger av at den er stabil.

En ruter imellom kan skrive om den kilden til sin egen 'NAT'-mapping. Derfor har tallet som observeres på serveren ofte ingen relasjon til det laptopen valgte.

Hvor kildetallet endrer seg på vei ut

Ta et oppdiktet IPv4-eksempel: en klient bak en oversettende ruter, en server med én 'UDP'-lytter og et enkelt datagram som krysser begge. Tabellen navngir hvert endepunkt og hva som skjer med det, i stedet for å spille av pakken på tre observasjonspunkter.

EndpointWhat stays fixedWhat changes on reconnectWho owns it
Server listenerThe service port and the address the profile namesNothing; the listener does not follow the clientThe server operator
Client socketThe destination it dialsThe local source port, chosen per socketThe client, or its operating system
Translated sourceUsually the public address of the routerThe port, and sometimes the address after a network switchThe NAT device or the upstream carrier

Destinasjonen er konstant i hver rad, og bare kildens identitet endres. Krav til UDP NAT skiller mellom en intern adresse og port og den eksterne mappingen, som er nøyaktig forskjellen mellom andre og tredje rad. En ruter kan beholde klientens kildeport eller velge en annen; bevaring er ikke noe en applikasjon bør forutsette.

Les de tre endepunktene fra vertene selv

Listene nedenfor kommer fra tre forskjellige maskiner og viser sammen hele samtalen. Kjør den første på serveren, den andre på klienten og den tredje der mappingen finnes. En enkelt logglinje viser aldri alle tre.

ss -lunp 'sport = :1194'
ss -unp | grep 1194
conntrack -L -p udp | grep 1194

Den første listen beviser at serveren er bundet til tjenesteporten, og viser hvilken prosess som eier den. Den andre viser klientens lokale sockel og destinasjonen den ringte. Den tredje viser mappingen ruteren opprettet, og det er det eneste stedet den oversatte kilden vises. Les dem i den rekkefølgen, og de to tallene slutter å se motstridende ut.

Hva en gjenoppkobling endrer, og hva den ikke endrer

Noen rutere beholder klientens kildeport når den er ledig, og andre tildeler en annen hver gang. Begge atferdene er normale, og en applikasjon som krever den første, vil bryte sammen på den andre. En endring av mapping etter en gjenoppkobling eller et nettverksbytte er ikke en serverfeil: klienten åpner en ny sockel, ruteren tildeler det den har, og serveren ser en ny kilde på samme lytter. En feil ville være å forvente at serveren godtar trafikk adressert til en vilkårlig klientport.

Fellesskapets OpenVPN-klienter får denne atferden gjennom nobind, som lar operativsystemet velge den lokale porten; fjernporten kommer fortsatt fra profilen. Å binde eksplisitt er et bevisst valg, ikke et protokollkrav. Serveren fortsetter å tilby ett endepunkt mens klientene velger sine egne lokale identiteter.

Merk lagene hver for seg i registreringen

Inne i tunnelen er det en andre samtale med egne porter. En HTTPS-forespørsel som tunnelen bærer, har destinasjon TCP 443, mens den ytre krypterte forbindelsen bruker UDP 1194, så endring av den ytre kildeporten endrer ingenting i den indre tjenesten.

Selv på det ytre laget betyr protokollen noe. UDP 1194 og TCP 1194 er forskjellige endepunkter, og en 'TCP'-lytter vil aldri motta et UDP-datagram fordi tallet stemmer. Når du dokumenterer en utrulling, merk serverens lytter, klientens sockel og den oversatte kilden som tre forskjellige ting, og legg til transporten på hver.

La så policyen følge rollene. Serveren åpner den tiltenkte transporten på lytteren sin og autentiserer fortsatt motparten; klientens brannmur slipper inn svar på sin egen utgående utveksling uten å publisere en inngående tjeneste. Et tilstandsløst filter trenger returretningen skrevet ut eksplisitt, og det er den praktiske grunnen til at skillet betyr noe utover ryddige diagrammer.

Relaterte artikler