Изворни порт клијента наспрам слушаоца сервера у VPN току
Упоредите два броја портова у једном тунелу: фиксног слушаоца сервера и краткотрајни извор клијента, и како се између њих налази превод рутера.
У истом разговору појављују се два броја и ниједан није погрешан. Серверски дневник показује слушаоца који нуди услугу, преносни рачунар показује сокет који је послао датаграм, а рутер између може да препише други на излазу. Корисније је упоредити крајеве разговора него саме цифре. Поређење испод држи одвојено слушаоца, клијентски сокет и преведени извор, јер одговарају на различита питања.
Два броја која описују супротне крајеве
Конфигурисани порт сервера је одредиште на које се клијент јавља. Њега фиксира политика, појављује се у профилу и мора да буде отворен на страни сервера. Изворни порт клијента бира се локално, обично из ефемерног опсега, и постоји како би одговор имао где да слети. Може да се промени при сваком поновном повезивању и ништа у дизајну не зависи од тога да остане стабилан.
Рутер између може да препише тај извор у сопствено 'NAT' мапирање. Зато број виђен на серверу често нема никакве везе са оним који је преносни рачунар изабрао.
Где се број извора мења на излазу
Узмите измишљен пример са IPv4: клијент иза рутера који преводи, сервер са једним 'UDP' слушаоцем и један датаграм који прелази оба. Табела именује сваку крајњу тачку и шта се са њом догађа, уместо да поново пушта пакет на три места посматрања.
| 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 |
Одредиште је константно у сваком реду, а мења се само идентитет извора. Захтеви UDP NAT-а разликују унутрашњу адресу и порт од спољашњег мапирања, што је управо разлика између другог и трећег реда. Рутер може да задржи изворни порт клијента или да изабере други; задржавање није нешто што апликација сме да претпостави.
Прочитајте три крајње тачке са самих хостова
Листе испод долазе са три различита рачунара и заједно показују цео разговор. Покрените прву на серверу, другу на клијенту, а трећу где год мапирање постоји. Један ред дневника никада не показује сва три.
ss -lunp 'sport = :1194'
ss -unp | grep 1194
conntrack -L -p udp | grep 1194Прва листа доказује да је сервер везан за сервисни порт и показује који га процес држи. Друга показује локални сокет клијента и одредиште на које се јавио. Трећа показује мапирање које је рутер створио, а то је једино место где се преведени извор појављује. Читајте их тим редом и два броја престају да изгледају противречно.
Шта поновно повезивање мења, а шта не
Неки рутери задрже изворни порт клијента када је слободан, а неки сваки пут доделе други. Оба понашања су нормална, а апликација која захтева прво сломиће се на другом. Промена мапирања после поновног повезивања или промене мреже није квар сервера: клијент отвара нови сокет, рутер додељује шта има, а сервер види нови извор на истом слушаоцу. Квар би био очекивати да сервер прихвати саобраћај адресиран на произвољан клијентски порт.
Клијенти OpenVPN из заједнице добијају ово понашање кроз nobind, што оперативном систему препушта избор локалног порта; удаљени порт и даље долази из профила. Изричито везивање је свесна одлука, а не захтев протокола. Сервер наставља да нуди једну крајњу тачку док клијенти бирају сопствене локалне идентитете.
Означите слојеве одвојено у запису
Унутар тунела постоји други разговор са сопственим портовима. HTTPS захтев који тунел носи има одредиште TCP 443, док спољашња шифрована веза користи UDP 1194, па промена спољашњег изворног порта не мења ништа у унутрашњој услузи.
Чак и на спољашњем слоју протокол је важан. UDP 1194 и TCP 1194 су различите крајње тачке и 'TCP' слушалац никада неће примити UDP датаграм зато што се број поклапа. Када документујете постављање, означите серверски слушалац, клијентски сокет и преведени извор као три различите ствари и додајте транспорт свакој.
Затим нека политика прати улоге. Сервер отвара предвиђени транспорт на свом слушаоцу и даље проверава идентитет друге стране; заштитни зид клијента пропушта одговоре на његову сопствену одлазну размену без објављивања долазне услуге. Филтер без стања треба изричито написан повратни смер, и то је практични разлог зашто је разлика важна и изван уредних дијаграма.