Asiakkaan lähdeportti vastaan palvelimen kuuntelija VPN-virrassa
Vertaa kahta porttinumeroa yhdessä tunnelissa: palvelimen kiinteää kuuntelijaa ja asiakkaan lyhytaikaista lähdettä sekä reitittimen käännöksen sijaintia niiden välissä.
Samassa keskustelussa esiintyy kaksi numeroa, eikä kumpikaan ole väärä. Palvelimen loki näyttää kuuntelijan, joka tarjoaa palvelun, kannettava näyttää soketin, joka lähetti datagrammin, ja välissä oleva reititin voi kirjoittaa toisen uudelleen ulospäin mennessä. Keskustelun päiden vertaaminen on hyödyllisempää kuin numeroiden vertaaminen. Alla oleva vertailu pitää kuuntelijan, asiakkaan soketin ja käännetyn lähteen erillään, koska ne vastaavat eri kysymyksiin.
Kaksi numeroa, jotka kuvaavat vastakkaisia päitä
Palvelimen määritetty portti on kohde, johon asiakas soittaa. Käytäntö kiinnittää sen, se näkyy profiilissa ja sen on oltava avoin palvelimen puolella. Asiakkaan lähdeportti valitaan paikallisesti, yleensä efemeerisestä alueesta, ja se on olemassa, jotta vastauksella olisi paikka laskeutua. Se voi muuttua joka uudelleenyhdistämisellä, eikä mikään suunnittelussa riipu sen pysyvyydestä.
Välissä oleva reititin voi kirjoittaa tuon lähteen omaan 'NAT'-mappaukseensa. Siksi palvelimella havaittu numero ei useinkaan liity mitenkään siihen, jonka kannettava valitsi.
Missä lähdenumero muuttuu matkalla ulos
Ota keksitty IPv4-esimerkki: asiakas kääntävän reitittimen takana, palvelin, jossa on yksi 'UDP'-kuuntelija, ja yksi datagrammi, joka kulkee molempien läpi. Taulukko nimeää jokaisen päätepisteen ja mitä sille tapahtuu sen sijaan, että paketti toistettaisiin kolmessa havaintopisteessä.
| 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 |
Kohde on vakio jokaisella rivillä, ja vain lähteen identiteetti muuttuu. UDP NAT -vaatimukset erottavat sisäisen osoitteen ja portin ulkoisesta mappauksesta, mikä on täsmälleen toisen ja kolmannen rivin ero. Reititin voi säilyttää asiakkaan lähdeportin tai valita toisen; säilyttäminen ei ole jotain, mitä sovelluksen pitäisi olettaa.
Lue kolme päätepistettä isänniltä itseltään
Alla olevat listaukset tulevat kolmelta eri koneelta ja näyttävät yhdessä koko keskustelun. Aja ensimmäinen palvelimella, toinen asiakkaalla ja kolmas siellä, missä mappaus on olemassa. Yksi lokirivi ei koskaan näytä kaikkia kolmea.
ss -lunp 'sport = :1194'
ss -unp | grep 1194
conntrack -L -p udp | grep 1194Ensimmäinen listaus todistaa, että palvelin on sidottu palveluporttiin, ja näyttää, mikä prosessi sen omistaa. Toinen näyttää asiakkaan paikallisen soketin ja kohteen, johon se soitti. Kolmas näyttää reitittimen luoman mappauksen, ja se on ainoa paikka, jossa käännetty lähde esiintyy. Lue ne tässä järjestyksessä, niin kaksi numeroa lakkaa näyttämästä ristiriitaisilta.
Mitä uudelleenyhdistäminen muuttaa ja mitä ei
Jotkin reitittimet säilyttävät asiakkaan lähdeportin, kun se on vapaa, ja jotkut jakavat joka kerta eri portin. Molemmat käyttäytymiset ovat normaaleja, ja sovellus, joka vaatii ensimmäistä, hajoaa toisella. Mappauksen muutos uudelleenyhdistämisen tai verkonvaihdon jälkeen ei ole palvelinvika: asiakas avaa uuden soketin, reititin jakaa sen, mitä sillä on, ja palvelin näkee uuden lähteen samassa kuuntelijassa. Vika olisi odottaa, että palvelin hyväksyy liikennettä, joka on osoitettu mielivaltaiseen asiakasporttiin.
Yhteisön OpenVPN-asiakkaat saavat tämän käyttäytymisen nobind kautta, mikä antaa käyttöjärjestelmän valita paikallisen portin; etäportti tulee edelleen profiilista. Nimenomainen sitominen on tietoinen valinta, ei protokollan vaatimus. Palvelin tarjoaa edelleen yhtä päätepistettä, kun asiakkaat valitsevat omat paikalliset identiteettinsä.
Merkitse kerrokset erikseen tietueeseen
Tunnelin sisällä on toinen keskustelu omine portteineen. Tunnelin kantaman HTTPS-pyynnön kohde on TCP 443, kun taas ulompi salattu yhteys käyttää UDP 1194:ää, joten ulomman lähdeportin muuttaminen ei muuta sisäisessä palvelussa mitään.
Myös ulommassa kerroksessa protokolla on merkityksellinen. UDP 1194 ja TCP 1194 ovat eri päätepisteitä, eikä 'TCP'-kuuntelija koskaan saa UDP-datagrammia siksi, että numero täsmää. Kun dokumentoit käyttöönoton, merkitse palvelimen kuuntelija, asiakkaan soketti ja käännetty lähde kolmeksi eri asiaksi ja lisää kullekin kuljetuskerros.
Anna sitten käytännön seurata rooleja. Palvelin avaa aiotun kuljetuksen kuuntelijassaan ja todentaa edelleen vastapuolen; asiakkaan palomuuri sallii vastaukset omaan lähtevään vaihtoonsa julkaisematta saapuvaa palvelua. Tilaton suodatin tarvitsee paluusuunnan nimenomaisesti kirjattuna, ja se on käytännön syy siihen, miksi erottelu on tärkeää muutenkin kuin siisteissä kaavioissa.