Tuo L2TP-osoite on IPCP, ei DHCP-vuokraus lähiverkossa

Yhteys nousee ja sovitin näyttää osoitteen toimiston alueelta, joten luonteva johtopäätös on, että VPN antoi sinulle lähiverkon osoitteen ja asetti sinut siten lähiverkkoon. Kumpikaan puolisko ei ole aivan oikein. L2TP kuljettaa PPP-istuntoa, ja PPP neuvottelee sisemmän IPv4-osoitteen IPCP:n kanssa. Tämä osoite on kahden vertaiskumppanin välillä sovittu istuntoparametri, ei toimiston DHCP-palvelimen myöntämä vuokraus, eikä sen hallussapito tee sinusta naapuria toimiston johdossa.

Kaksi osoitetta yhdessä yhteydessä

L2TP-yhteydessä on kaksi riippumatonta neuvottelua. Ulompi muodostaa suojatun polun laitteesi ja VPN-päätepisteen välille minkä tahansa jo olemassa olevan verkon yli. Sisempi on PPP-istunto, ja siinä sovitaan istuntosi osoite ja vastapuolen osoite. Internet-liikenne voi lähteä kokonaan kolmannen osoitteen, päätepisteen julkisen osoitteen, alta, minkä vuoksi VPN-tarkistussivu ja sovittimen osoite harvoin täsmäävät.

Näiden kolmen roolin erillään pitäminen vastaa useimpiin kysymyksiin, joita ihmiset tuovat tälle kerrokselle. Yksityinen numero VPN-liittymässä on normaalia ja odotettua. Se ei kerro mitään siitä, muuttiko päätepiste julkista lähtöäsi, eikä itsessään päätä, mitkä kohteet liikenteesi saavuttaa.

Mitä IPCP tarkalleen tekee

IPCP on PPP:n IPv4-hallintaprotokolla. Kumpikin osapuoli lähettää Configure-Request-viestejä, jotka kuvaavat haluamansa vaihtoehdot, ja osoitevaihtoehto on yksi niistä. Asiakas, jolla ei vielä ole osoitetta, kysyy yleensä 0.0.0.0:lla, ja palvelin vastaa Configure-Nak-viestillä, joka sisältää osoitteen, jonka se haluaa asiakkaan käyttävän. Sitten asiakas pyytää tätä osoitetta, ja istunto nousee paikallisella ja etäosoitteella.

Tämä vaihto on dokumentoitu PPP- ja IPCP-määrityksissä, ja se selittää yksityiskohdan, joka näyttää virheeltä: osoitteen valitsee palvelin oman käytäntönsä mukaan, joka voi olla allas, käyttäjäkohtainen asetus tai todennettuun identiteettiin sidottu osoite. Kun allas on käytetty loppuun tai käytäntö on ristiriidassa pyynnön kanssa, todennus voi onnistua samalla kun osoiteneuvottelu epäonnistuu, ja asiakas raportoi yhteydestä, joka ei koskaan asetu.

ip addr show ppp0
ip route show default
dmesg | grep -i pppd

pppd-lokin rivi, jossa mainitaan paikallinen ja etäosoite, on tämän neuvottelun onnistunut loppu. Sen puuttuminen onnistuneen todennuksen rinnalla viittaa osoitevaiheeseen eikä tunnistetietoihin.

Miksi lähiverkko ei voi vastata sinulle

Kauemman osapuolen alueelta tuleva osoite luo odotuksen, että kyseisen lähiverkon isännät voivat tavoittaa sinut, eivätkä ne yleensä voi, ellei palvelin reititä istuntosi osoitetta takaisin tunneliin. Altaan sisällä oleminen on väite osoittamisesta, ei topologiasta. Toimiston tiedostopalvelimella ei ole reittiä istuntosi osoitteeseen, ellei VPN-palvelin välitä sitä, eikä se ehkä ole edes sallittua, vaikka välittäisikin.

Siksi päällekkäiset alueet aiheuttavat ongelmia, jotka ovat suhteettomia niiden näennäiseen kokoon. Jos allas on päällekkäinen lähiverkon kanssa, jota asiakas jo käyttää, asiakkaan reititystaulussa on nyt kaksi vaatimusta samasta etuliitteestä, ja väärä voittaa usein syistä, joilla ei ole mitään tekemistä tunnelin kanssa.

Tarkista istunto ja sitten reitti

Tarkista ensin liitäntä, sitten reitit, sitten yksi kohde, jolla on merkitystä. Jokaisella vaiheella on oma vikatilansa, ja kaikkien kolmen testaaminen kerralla tuottaa johtopäätöksen, jota et voi myöhemmin puolustaa.

curl -sS --max-time 5 https://ifconfig.me
ping -c 3 10.50.30.20
ip route get 10.50.30.20

Jos julkinen tarkistus näyttää päätepisteen osoitteen, kun yksityinen kohde aikakatkeaa, tunneli kuljettaa oletusreittiäsi eikä kauempi osapuoli vastaa siitä kohteesta. Jos yksityinen kohde vastaa mutta julkinen tarkistus ei muutu, profiili käyttää jaettua tunnelointia ja vain osa liikenteestä käyttää istuntoa.

Pidä kolme vaihetta erillään

Todennus, osoiteneuvottelu ja välitys epäonnistuvat eri tavoin, ja jokaisella on eri omistaja. Tunnistetiedot ovat identiteettiongelma, IPCP:n loppuminen on palvelinkäytännön ongelma ja puuttuva paluureitti on verkkosuunnittelun ongelma. Kaikkien kolmen ilmoittaminen muodossa “VPN on rikki” takaa hitaan korjauksen.

Kirjaa osoitettu osoite, allas josta se tuli ja se, pitäisikö lähiverkon tavoittaa se. Tämä yksi muistiinpano estää seuraavaa henkilöä olettamasta DHCP-vuokrausta ja etsimästä aluetta, joka ei ollut koskaan mukana.