VPN reitittimessä vai portin edelleenohjaus: kumpi voittaa?

Reititin päättää VPN-yhteyden itse, ja vanha edelleenohjaussääntö lähettää yhä saman UDP-portin lähiverkon koneelle. Vain toinen niistä voi olla todellinen päätepiste, eikä ydin ratkaise asiaa. Kohteen käännös kirjoittaa paketin uudelleen ennen kuin paikalliselta palvelulta kysytään, joten VPN-prosessi odottaa liikennettä, joka on jo lähetetty muualle. Tehtävänä on päättää, kenelle portti kuuluu, ja sen jälkeen saada säännöt sopimaan yhteen.

Yksi portti, kaksi väitettyä omistajaa

Reitittimen sisällä käyvän VPN-palvelimen täytyy saada saapuva lupa, joka johtaa sen omaan pistokkeeseen. Saman portin kohde-NAT-merkintä johtaa aivan muualle: lähiverkon osoitteeseen ja edelleenohjauspäätökseen. Ne ovat eri päätepisteitä, joilla on eri lokit ja eri vikatilat. Tavallinen vihje on, että toinen osoiteperhe toimii ja toinen ei, koska jäljelle jäänyt merkintä kirjoitettiin yhtä perhettä varten eikä sitä koskaan tarkistettu uudelleen.

Kirjoita vaatimus muistiin ennen muokkausta: perhe, ulkoinen osoite, kuljetus, portti ja käännetty kohde.

Käännös tapahtuu ennen paikallista tarkistusta

Kohde-NAT muuttaa paketin kohdetta ennen reititystä, ennen kuin ydin valitsee paikallisen toimituksen ja edelleenohjauksen välillä. Kun kohteena on lähiverkon isäntä, paketti kulkee edelleenohjauksen reittiä. Reitittimen oman pistokkeen saapuvia sääntöjä ei koskaan tutkita, minkä vuoksi VPN-loki pysyy tyhjänä, kun asiakas odottaa aikakatkaisua.

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

Tuo järjestys on koko mekanismi, ja laitteiden käyttöliittymät piilottavat sen valintaruutujen taakse sitä muuttamatta. Kohteen omistaja päättää yhä, minkä reitin paketti ottaa.

Jos lähiverkon isäntä on aiottu päätepiste, edelleenohjaus on oikein, eikä reitittimen pitäisi kuunnella samaa porttia.

Pidä yksi kartoitus ja poista toinen

Listaa kyseisen portin ja perheen NAT-merkinnät ja valitse selviytyjä:

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

Saman numeron TCP-merkintä ei liity UDP-vikaan, ja niiden kohteleminen yhtenä objektina johtaa väärän säännön poistamiseen. Kun paikallisen pistokkeen pitäisi voittaa, ristiriitaisen kartoituksen omistaja poistaa tai kirjoittaa uudelleen juuri tuon merkinnän, ja reitittimen oman portin saapuva lupa pysyy paikallaan. Asiaan kuulumattomat edelleenohjaukset, hallintareitti ja kopio sääntöjoukosta selviytyvät kaikki muutoksesta.

Jos VPN asuu erillisellä isännällä, edelleenohjaus on oikea objekti. Säiliössä tai virtuaalikoneessa oleva palvelu voi tarvita julkaistun portin, vaikka laatikkoa kutsutaan reitittimeksi, joten seuraa pistoketta ja sen nimiavaruutta, älä kotelon tarraa.

Vahvista omistaja ulkopuolelta

Testaa kukin perhe erikseen, koska reitittimelle päättyvä IPv6-yhteys ei kerro mitään IPv4-yhteydestä, jonka vanha sääntö ohjaa uudelleen. Lue vastaanottavan palvelun loki nähdäksesi, mikä päätepiste vastasi, ja pidä asiakkaan onnistumisviestiä heikkona todisteena. Merkityksellinen testi vaatii uuden virtauksen. Lähetä koe ulkoiselta isännältä komennolla nc -zvu 203.0.113.7 1194 ja lue voittajan loki komennolla journalctl -u openvpn@server -n 20. Reitittimen kuuntelija kirjaa yhteyden itse, kun taas lähiverkon isäntä kirjaa sen omassa palvelussaan.

Yhteyksien seuranta pitää olemassa olevat virtaukset alkuperäisessä kartoituksessaan, joten vakiintunut istunto voi elää juuri korjaamaasi sääntöä pidempään.

Kun aiottu päätepiste vastaa tavallisilla henkilöllisyystarkistuksillaan, testaa tunnelin takana olevaa yksityistä resurssia. Ulomman kuuntelijan tavoittaminen on vasta ensimmäinen hyppy; sisäinen reititys ja sovelluksen valtuutus ovat erillisiä tuloksia.