Klienta avota ports pret servera klausītāju VPN plūsmā
Salīdziniet divus portu numurus vienā tunelī: servera fiksēto klausītāju un klienta īslaicīgo avotu, un kā starp tiem atrodas maršrutētāja tulkojums.
Vienā sarunā parādās divi numuri, un neviens no tiem nav nepareizs. Servera žurnāls rāda klausītāju, kas piedāvā pakalpojumu, klēpjdators rāda ligzdu, kas nosūtīja datagrammu, un maršrutētājs starp tiem var pārrakstīt otro, izejot ārā. Noderīgāk ir salīdzināt sarunas galus, nevis pašus ciparus. Tālāk esošais salīdzinājums šķir klausītāju, klienta ligzdu un tulkoto avotu, jo tie atbild uz dažādiem jautājumiem.
Divi numuri, kas raksturo pretējus galus
Konfigurētais servera ports ir galamērķis, uz kuru klients zvana. To nosaka politika, tas parādās profilā, un tam jābūt atvērtam servera pusē. Klienta avota ports tiek izvēlēts lokāli, parasti no īslaicīgā diapazona, un tas pastāv, lai atbildei būtu kur nolaisties. Tas var mainīties katrā atkārtotā savienojumā, un nekas dizainā nav atkarīgs no tā stabilitātes.
Maršrutētājs starp tiem var pārrakstīt šo avotu savā 'NAT' kartējumā. Tāpēc serverī novērotais numurs bieži vien nav saistīts ar to, ko izvēlējās klēpjdators.
Kur avota numurs mainās, izejot ārā
Ņemiet izdomātu IPv4 piemēru: klients aiz tulkojoša maršrutētāja, serveris ar vienu 'UDP' klausītāju un viens datagramms, kas šķērso abus. Tabula nosauc katru galu un to, kas ar to notiek, nevis atkārto paketi trijos novērojumu punktos.
| 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 |
Galamērķis katrā rindā ir nemainīgs, un mainās tikai avota identitāte. UDP NAT prasības atšķir iekšējo adresi un portu no ārējā kartējuma, un tā ir tieši atšķirība starp otro un trešo rindu. Maršrutētājs var saglabāt klienta avota portu vai izvēlēties citu; saglabāšana nav kaut kas, ko lietotnei vajadzētu pieņemt.
Lasiet trīs galus pašos resursos
Zemāk esošie saraksti nāk no trim dažādām mašīnām un kopā parāda visu sarunu. Pirmo palaidiet serverī, otro klientā, bet trešo tur, kur kartējums pastāv. Viena žurnāla rinda nekad neparāda visus trīs.
ss -lunp 'sport = :1194'
ss -unp | grep 1194
conntrack -L -p udp | grep 1194Pirmais saraksts pierāda, ka serveris ir piesaistīts pakalpojuma portam, un parāda, kurš process to pārvalda. Otrais parāda klienta lokālo ligzdu un galamērķi, uz kuru tas zvanīja. Trešais parāda maršrutētāja izveidoto kartējumu, un tā ir vienīgā vieta, kur parādās tulkais avots. Lasiet tos šādā secībā, un divi numuri pārstās izskatīties pretrunīgi.
Ko maina atkārtots savienojums un ko nemaina
Daži maršrutētāji saglabā klienta avota portu, kad tas ir brīvs, bet citi katru reizi piešķir citu. Abas uzvedības ir normālas, un lietotne, kas pieprasa pirmo, sabruks uz otro. Kartējuma maiņa pēc atkārtota savienojuma vai tīkla maiņas nav servera kļūda: klients atver jaunu ligzdu, maršrutētājs piešķir to, kas tam ir, un serveris tajā pašā klausītājā ierauga jaunu avotu. Kļūda būtu gaidīt, ka serveris pieņems trafiku, kas adresēts patvaļīgam klienta portam.
Kopienas OpenVPN klienti iegūst šo uzvedību ar nobind, kas ļauj operētājsistēmai izvēlēties lokālo portu; attālais ports joprojām nāk no profila. Skaidra piesaiste ir apzināta izvēle, nevis protokola prasība. Serveris turpina piedāvāt vienu galu, kamēr klienti izvēlas savas lokālās identitātes.
Atzīmējiet slāņus atsevišķi ierakstā
Tuneļa iekšpusē notiek otra saruna ar saviem portiem. Tuneļa pārnestais HTTPS pieprasījums ir adresēts TCP 443, bet ārējais šifrētais savienojums izmanto UDP 1194, tāpēc ārējā avota porta maiņa neko nemaina iekšējā pakalpojumā.
Pat ārējā slānī protokolam ir nozīme. UDP 1194 un TCP 1194 ir dažādi gali, un 'TCP' klausītājs nekad nesaņems UDP datagrammu tikai tāpēc, ka numurs sakrīt. Dokumentējot izvietošanu, atzīmējiet servera klausītāju, klienta ligzdu un tulkoto avotu kā trīs atšķirīgas lietas un pievienojiet katram transportu.
Tad lai politika seko lomām. Serveris atver paredzēto transportu savā klausītājā un joprojām autentificē partneri; klienta ugunsmūris pieļauj atbildes uz savu izejošo apmaiņu, nepublicējot ienākošu pakalpojumu. Beztāvokļa filtram ir vajadzīgs skaidri ierakstīts atgriešanās virziens, un tas ir praktiskais iemesls, kāpēc šī atšķirība ir svarīga ārpus kārtīgām diagrammām.