NAT päättää, minkä lähdeosoitteen VPN-palvelimesi todella näkee

Kuvittelet, että VPN-palvelin lukee kannettavasi osoitteen paketista ja kirjoittaa sen lokiin. Se lukee sen, minkä viimeinen NAT-hyppy asetti ulompaan otsakkeeseen, ja yhteyttä jakavassa puhelimessa se on usein osoite, jonka sadat muut tilaajat jakavat. Oman koneesi osoite 192.168.x.x ei koskaan ylitä internetiä siinä otsakkeessa, ja tunnelin osoitteen palvelin antaa vasta, kun yhteys on jo pystyssä. Kun palvelimen loki ja kannettavan ip addr siis eroavat, kumpikaan ei ole väärässä; ne kuvaavat yhden istunnon eri kerroksia.

Kolme osoitetta, ja vain yksi on lokissa

Hämmennys syntyy siitä, että kolme osoitetta sulautetaan yhdeksi. Jokaisella on eri omistaja, se elää eri otsakkeessa ja saavuttaa palvelimen eri reittiä.

Vain keskimmäinen rivi on tuntematon yhteyden muodostushetkellä. Palvelin kirjoittaa sen vertaistaulukkoonsa, tilariviinsä tai vuolokiinsa daemonista riippuen: WireGuard kutsuu sitä päätepisteeksi, OpenVPN-tilatiedosto merkitsee sen nimellä Real Address ja strongSwan raportoi sen IKE_SA:n etäisäntänä. Tämä arvo päivittyy aina, kun paketti saapuu eri lähteestä, joten se muuttuu ilman, että kukaan käynnistää mitään uudelleen.

Alin rivi on se, minkä ihmiset lukevat väärin identiteettiväitteenä. Se merkitsee paikan palvelimen kokoonpanossa, ei henkilöä, koska palvelin valitsi sen omasta varannostaan. Kaksi käyttäjää voi saada saman tunneliosoitteen eri päivinä, ja yhdellä voi olla kaksi sellaista kahdesta laitteesta.

Miksi lokiin merkitty monikko muuttuu, kun tunneli pysyy pystyssä

Osoitteenmuunnos on taulukko, jossa on ajastin, ei pysyvä sidonta. Kotireititin pitää UDP-kartoituksensa jonkin aikaa viimeisen paketin jälkeen, operaattorin yhdyskäytävä kierrättää portteja oman aikataulunsa mukaan, ja Wi-Fi:stä LTE:hen siirtyvä puhelin palaa täysin eri lähteellä. Linuxin conntrackin oletusarvot ovat tässä hyödyllinen mittapuu: nf_conntrack_udp_timeout on 30 sekuntia ja suoratoistoversio 120, joten hiljainen tunneli voi menettää kartoituksensa kauan ennen kuin käyttäjä huomaa.

Tunneli selviää, koska protokolla todentaa vertaisen, ei osoitetta. WireGuard on kättelyn jälkeen tilaton, joten mikä tahansa todennettu paketti päivittää tallennetun päätepisteen ja uudelleensidonta korjaantuu seuraavalla paketilla; siksi persistent-keepalive = 25 on olemassa, pitämään kartoitus lämpimänä käyttämättömänä aikana. OpenVPN:n --float tekee saman työn ja sallii todennetun asiakkaan jatkaa uudesta osoitteesta ja portista. Versioissa 2.4 ja 2.5, joissa float on oletuksena pois päältä, uudelleensidonta nollaa istunnon ja asiakas yhdistää uudelleen.

IPsec pääsee sinne useammalla liikkuvalla osalla. IKEv2 havaitsee muunnoksen vertaamalla lähteen ja kohteen tiivisteitä NAT-tunnistuksen hyötykuormissa, siirtyy UDP 4500 -kapselointiin ja seuraa keepalive-viestejä uuteen monikkoon. Kun keepalive-viestit estetään, SA pysyy paperilla pystyssä, kun taas liikenne yhteen suuntaan pysähtyy hiljaa.

Mitä palvelin voi kohdistaa ja mitä ei

Myytti, joka kannattaa tappaa, on se, että muunnos piilottaa sinut operaattorilta. Se muuttaa merkintää, ei havaintoa. Operaattorin NAT:n takana oleva yhdyskäytävä näkee 100.64.0.0/10-avaruuden tai yhden julkisen osoitteen, jonka monet tilaajat jakavat, ja voi silti sitoa virran varmenteen subjektiin, WireGuardin julkiseen avaimeen, annettuun tunneliosoitteeseen, tavulaskureihin ja aikaikkunaan. Mikään tästä ei tarvitse LAN-osoitettasi.

Rajat kulkevat myös toiseen suuntaan. Lokiin merkitty jaettu osoite osoittaa yhdyskäytävään, ei kotitalouteen; kaksi istuntoa samasta muunnetusta osoitteesta eri porteilla ovat eri laitteita; sama osoite kahtena eri päivänä voi olla kaksi toisistaan riippumatonta tilaajaa, jos portti kierrätettiin. Palvelin, joka tallentaa vain vertaisten avaimet, ei voi yhdistää niitä asiakkaaseen ilman tilitietokantaa, eikä palvelin, joka tallentaa vain osoitteet, erota kannettavaa puhelimesta saman reitittimen takana.

Vertaa molempia päitä arvaamisen sijaan

Selvitäksesi, mitä tapahtui, tallenna sama yhteys molemmissa päissä samalla hetkellä ja vertaa monikkoa, älä osoitetta. Asiakkaassa, ennen mitään muunnosta:

ss -uapn 'dport = :51820'
ip -4 route get 203.0.113.10
wg show wg0 endpoints

Lue sitten muunnosmerkintä reitittimeltä tai CGNAT-yhdyskäytävältä ja se, mikä lopulta saapuu palvelimelle:

conntrack -L -p udp --dport 51820
tcpdump -ni eth0 udp port 51820

Kolme mallia selittää useimmat eroavaisuudet. Palvelimen lähdeportti eroaa paikallisesta portista, kun taas kohde täsmää: tavallinen portinmuunnos. Palvelimen lähdeosoite kuuluu ISP-lohkoon, joka ei ole sinun: ainakin yksi ylimääräinen NAT-kerros. Paketit pysähtyvät käyttämättömyysjakson jälkeen ja jatkuvat uudella portilla: kartoitus vanheni, ei reititysvika. Jos aikaleimat ovat yli sekunnin tai kaksi erillään, vertaat kahta eri yritystä.

Missä ero rikkoo asioita

Palvelinvialta näyttävät katkokset alkavat yleensä täältä. Kotiosoitteeseesi kiinnitetty käyttösääntö epäonnistuu, kun ISP:n vuokra muuttuu. Muunnettuun osoitteeseen täsmäävä fail2ban-sääntö estää kaikki kyseisen yhdyskäytävän takana olevat tilaajat kerralla. Kiinteän etäosoitteen sivusto-sivustolle-vertainen lopettaa avainten uusimisen, kun mobiiliyhteys muuttuu. Tunnelin protokolla oli kunnossa; oletus ulommasta monikosta ei.

Sama hämmennys näkyy palvelinpäässä. Jos VPN-laatikko itsessään on NAT:n takana, tarvitset portin edelleenohjauksen ja toimivan välityspolun; strongSwanin välitysohje kattaa tämän tapauksen IPsecille. Palvelin, joka on tavoitettavissa vain yksityisestä osoitteesta, ei koskaan näe asiakkaidensa esittämää muunnettua monikkoa, ja se on eri ongelma kuin asiakkaiden muuntaminen.

Käy nämä neljä tarkistusta järjestyksessä ja pysähdy ensimmäiseen, joka epäonnistuu:

• Tallenna molemmissa päissä samaan aikaan; varmista, että lähdeportti, kohdeportti ja aikaleimat täsmäävät.
• Lue palvelimen vertaislistasta osoite, joka sillä on nyt, ei se, jota odotit.
• Tarkista conntrack- tai NAT-taulukosta merkintä ja sen jäljellä oleva elinikä.
• Varmista, että asiakkaan tunneliliitännän osoite vastaa palvelimen antamaa, ei LAN-osoitetta.

Jos molemmat tallenteet täsmäävät monikossa ja tunneli silti epäonnistuu, muunnos ei ole ongelmasi; siirry kättelyyn ja tunnelin sisäiseen reititystaulukkoon.