Miksi saman reitittimen takaa yhdistyy vain yksi VPN-asiakas

Kaksi kannettavaa on samassa kotiverkossa, ja toimiston VPN hyväksyy niistä täsmälleen yhden. Toinen joko aikakatkeaa tai odottaa, kunnes ensimmäinen katkaisee, eikä kukaan koskenut asiakasasetukseen kahden yrityksen välillä. Tunnistetiedot ovat samat, jotka toimivat minuutti sitten, ja se on vihje siitä, ettei todennus ole vian syy. Kolme mekanismia tuottaa tämän kuvion, ja palvelimen oma loki kertoo, minkä kanssa olet tekemisissä.

Lue yhdyskäytävän loki ennen kuin kosket asiakkaaseen

Palvelimen kirjaus molemmista yrityksistä vastaa ensimmäiseen kysymykseen, ja se vastaa yhdellä kolmesta tavasta. Jos toinen yritys ei koskaan ilmesty siihen lokiin, paketti ei koskaan saapunut kuuntelijalle, ja ongelman omistaa kotireititin tai palveluntarjoajan reitti. Jos loki kirjaa yrityksen ja hylkää sen, tunneli saapui, joten kyse on identiteetistä, lisenssistä tai istuntokatosta eikä mistään johdolla. Jos loki kirjaa onnistuneen istunnon, kun asiakas yhä ilmoittaa virheestä, katso paluureittiä tai sitä, että kahdelle asiakkaalle annetaan sama tunneliosoite.

Puhelimen yhteyspiste erottaa nuo perheet halvalla: aja toinen asiakas mobiilidatan yli, kun ensimmäinen pysyy yhdistettynä. Menestys siellä viittaa kotiverkkoon, ja sama virhe siellä viittaa yhdyskäytävään, mikä jättää reitittimen syyttömäksi. Kumpikaan tulos ei ole yksin ratkaiseva, mutta kumpikin poistaa puolet hakuavaruudesta yhdellä yrityksellä.

Kirjoita tulos muistiin ennen kuin muutat mitään, koska lokin kolme tulosta johtavat kolmeen toisistaan riippumattomaan korjaukseen. Muistiinpano, joka nimeää, minkä kolmesta näit, on arvokkaampi kuin kuvakaappaus asiakasvirheestä.

Mitä reititin tekee GRE:lle ja NAT-T:lle

PPTP on klassinen syyllinen: ohjauskanava on TCP 1723, kun taas datapolku on GRE, IP-protokolla 47. Moni kuluttajareititin toimittaa PPTP-avustajan, joka seuraa yhtä ohjausyhteyttä, joten toinen asiakas saman NAT:in takana avaa ohjauskanavansa eikä sen jälkeen saa lainkaan datapolkua. TCP-portin numero 47 edelleenohjaus ei tee GRE:lle mitään, koska GRE on protokollanumero eikä portti.

L2TP IPsecin päällä käyttäytyy suunnittelultaan toisin: IKE käyttää UDP 500:tä, NAT-läpäisy siirtää suojatun hyötykuorman UDP 4500:lle, ja kapselointi on olemassa juuri siksi, että useat asiakkaat yhden osoitteen takana voivat tavoittaa saman yhdyskäytävän. Tämä suunnittelu ei estä yhdyskäytävää tai välilaatikkoa asettamasta istuntokattoa osoitetta kohti, ja sohvalta molemmat viat näyttävät samoilta. SoftEtherin oma protokolla kärsii samasta ongelmaluokasta: reititin ilman toimivaa läpäisyä päästää ensimmäisen asiakkaan lähiverkosta ja pudottaa toisen. Testaa reitittimen ALG- tai läpäisykytkintä molemmissa asennoissa, sillä vanhemmalle asiakkaalle kirjoitettu avustaja voi turmella paketteja, joita nykyinen lähettää.

nc -vz 203.0.113.5 1723
sudo tcpdump -ni any proto gre

Identiteettikatot, jotka näyttävät siirtokatkoilta

Reititin ei ole ainoa epäilty, ja loki erottaa sen vaihtoehdosta. Kun OpenVPN-palvelin kiinnittää yhteisen nimen yhteen tunneliosoitteeseen, molemmat laitteet saavat sen osoitteen, ja ilman duplicate-cn uudempi istunto työntää vanhemman ulos. Sen valinnan päälle kytkeminen pitää molemmat yhdistettyinä mutta jättää ne yhdellä identiteetillä, yhdellä varmenteella ja yhdellä mitätöintipäätöksellä, mikä on pahempaa kuin miltä näyttää. Toista laitetta ei silloin voi koskaan mitätöidä yksin, joten mukavuuskytkin poistaa hiljaa hallinnan, jota saatat tarvita myöhemmin.

Lue palvelimen loki ja tilatiedosto yhdessä, sillä toinen näyttää todennuspäätöksen ja toinen sen, kuka on juuri nyt yhdistettynä. Kaksi merkintää, joilla on sama yhteinen nimi ja yksi virtuaaliosoite, vahvistavat identiteettitörmäyksen eikä reitittimen katkoa. Kaupalliset yhdyskäytävät lisäävät omat rajansa, kuten yhden samanaikaisen istunnon salliva paketti, lisenssimäärä tai sääntö, joka sallii yhden istunnon julkista osoitetta kohti, eikä mikään reitittimen asetus muuta niistä mitään.

sudo journalctl -u openvpn-server@server -n 60 --no-pager
cat /run/openvpn/server.status

Sovita korjaus lokimerkintään

Lokin hylkäys vaatii erilliset tunnistetiedot laitetta kohti, korkeamman rajan palvelua ylläpitävältä tai toisen yhdyskäytävän päätepisteen yhdelle koneelle. Jos mikään toinen yritys ei koskaan saavuta palvelinta, pysyvä korjaus on reititin, joka välittää protokollan ja pitää useamman kuin yhden istunnon, tai siirto, jonka reititin hallitsee hyvin, kuten yksi TCP- tai UDP-virta. Näiden välillä valitseminen on päätös laitteiston eliniästä, ei asiakasasetuksista.

Älä kopioi toimivan laitteen profiilia toiselle koneelle ja julista asia valmiiksi. Se muuttaa yhteysongelman pääsynvalvontaongelmaksi, koska kadonnutta kannettavaa ei enää voi erottaa kopiosta, joka on yhä käytössä. Se myös kätkee alkuperäisen vian, joka palaa heti, kun kolmas laite ilmestyy.

Kahden elävän istunnon varmistaminen

Yhdistä molemmat laitteet samaan aikaan, käynnistä aiottu sovellus kummassakin, yhdistä sitten toinen niistä uudelleen ja toista. Toinen kuvake, joka ilmestyy hetkeksi, ei todista liikenteestä mitään, ja istunto, joka putoaa kymmenen minuutin jälkeen, on toinen vika toisella omistajalla. Vertaa sitä, mitä palvelin lopuksi ilmoittaa, siihen, mitä käyttäjät näkivät, koska nämä kaksi kertomusta ovat usein eri mieltä.

Jos molemmat istunnot säilyvät ja kuljettavat liikennettä, korjaus pitää, ja alussa kirjoittamastasi muistiinpanosta tulee kirjaus siitä, mikä oli vialla. Jos vain toinen säilyy, palaa ensimmäiseen vaiheeseen ja tarkista, mikä kolmesta lokituloksesta sinulla nyt on, koska vastaus on voinut muuttua. Reitittimen avustajat voivat peittää ongelman, joka ilmestyy uudelleen toisessa verkossa, kun taas osoitekohtainen katto seuraa käyttäjää eikä laitetta. Toisesta verkosta testaaminen on halvin tapa selvittää, minkä niistä todella korjasit.