PPTP:n jaettu tunnelointi ei toimi: korjaa ensin GRE-polku
PPTP:n jaettu tunnelointi epäonnistuu kahdesta eri syystä: GRE on estetty tai sisempi reitti puuttuu. Testaa ensin kuljetus, sitten käytäntö.
Katso, kun PPTP-yhteys nousee, ja on helppo uskoa, että vaikea osa on tehty: asiakas todennetaan, ppp0-sovitin tai WAN Miniport ilmestyy ja tilaikkuna muuttuu vihreäksi. Sitten ensimmäinen pyyntö sisäiseen isäntään aikakatkaistaan ja profiilia syytetään. Käytännössä on kaksi riippumatonta kerrosta selvitettävänä: ulompi kuljetus, joka kuljettaa TCP 1723 ja GRE, sekä sisempi käytäntö, joka päättää, mitkä kohteet käyttävät PPP-liitäntää. Vihreä tila todistaa vain, että ensimmäinen kerros neuvotteli; se ei kerro toisesta mitään.
Seuraa asiakasta profiilista ohjauspistokkeeseen
Avaa asiakkaan loki ja etsi kohta, jossa se ottaa yhteyttä palvelimeen. PPTP avaa ensin TCP-yhteyden porttiin 1723 ja neuvottelee tunnelin parametrit kyseisen kanavan kautta. Jos tämä vaihe epäonnistuu, millään myöhemmällä ei ole väliä, ja virhe yleensä nimeää palvelimen osoitteen tai aikakatkaisun.
Vahvista ohjausyhteys verkossa ennen kuin kosket mihinkään reittiin. Asiakkaassa tai peiliportissa kaappaa TCP 1723 yhtä yhteysyritystä varten:
sudo tcpdump -ni any 'tcp port 1723' -c 20
Valmis kättely ja muodostettu istunto tarkoittavat, että ulompi ohjauskanava toimii. SYN, joka ei koskaan saa SYN-ACKia, viittaa palomuuriin, väärään palvelinosoitteeseen tai portin suodattavaan operaattoriin. Kättelyä seuraava välitön nollaus tarkoittaa usein, että palvelin hylkäsi tunnistetiedot tai tunnelityypin.
GRE on toinen protokolla, ei portti
PPTP kuljettaa PPP-hyötykuorman laajennetun GRE:n sisällä, IP-protokolla 47, jolla ei ole porttinumeroa, jota reititin voisi seurata. Siksi TCP 1723:n salliva sääntö voi silti jättää tunnelin ilman datapolkua. Tilalliset NAT-laitteet tarvitsevat GRE:n sisäisen kutsutunnisteen ymmärtääkseen vastausten takaisinkartoituksen, ja monet eivät sitä tee. PPTP-määritys pitää ohjauskanavan ja GRE-hyötykuorman erillisinä osina, ja niin täytyy testisuunnitelmasi tehdä.
Tarkkaile protokollaa 47 samassa kaappauksessa ja vertaa sitten, mitä lähtee ja mitä palaa:
sudo tcpdump -ni any 'proto gre' -c 20
Paketit, jotka lähtevät ilman vastauksia TCP 1723:n pysyessä terveenä, ovat klassinen estetyn GRE:n allekirjoitus. PPTP-läpivienti kuluttajareitittimessä on juuri sen laiteohjelmiston ominaisuus, joten toimiva hotelliverkko ei todista seuraavasta mitään. Jos reititin ei tarjoa läpivientiä etkä voi muuttaa sitä, ongelma on protokollavalinta, ei reittitaulukko.
Todista, että tunneli siirtää yhden paketin
Kun GRE virtaa, PPP-neuvottelu antaa asiakasliitännälle osoitteen. Lue määritys sen sijaan, että olettaisit sen:
ip -4 addr show ppp0
Pingaa vertaisosoite, joka näytetään piste-piste-yhteyden kohteena. Vastaus tässä vaiheessa todistaa, että kapseloitu polku toimii päästä päähän ja että palvelin vastaa tunnelin sisällä. Jos vertainen vastaa mutta sisäiset isännät eivät, ulompi kuljetus on kunnossa ja vika on siirtynyt sisäänpäin.
Tee tämä ennen minkään jaetun reitin lisäämistä. Rikkoutuneen kuljetuksen aikana tehty reittimuutos luo toisen muuttujan ja piilottaa ensimmäisen.
Kirjoita jaettu käytäntö, DNS mukaan lukien
Jaettu reititys on luettelo päätöksistä, ei valintaruutu. Jokainen yksityinen etuliite, jonka on kuljettava tunnelin läpi, tarvitsee reitin PPP-liitännän kautta, ja jokaisen etuliitteen, jonka on pysyttävä paikallisena, on puututtava siitä. Reitti sovelluksen aliverkkoon ilman vastaavaa reittiä sen yksityiseen ratkaisijaan on yleinen tapa luoda katkos, joka näyttää rikkinäiseltä sovellukselta.
Tarkista päätös, jonka ydin tekee yhdelle osoitteelle kussakin kategoriassa:
ip route get 10.20.5.10
ip route get 203.0.113.25
Ensimmäisen pitäisi nimetä ppp0, toisen tavallinen yhdyskäytävä. Jos molemmat nimeävät saman liitännän, käytäntö ei ole lainkaan jaettu. Lisää DNS-palvelimen oma osoite tunneliluetteloon, muuten sisäisten isäntien nimien selvitys lähtee paikallisen ratkaisijan kautta eikä palauta mitään hyödyllistä.
Toistettava tarkistus viidessä vaiheessa
Aja kerrokset järjestyksessä ja pysähdy ensimmäiseen, joka epäonnistuu: ohjauskanava, GRE:n näkyvyys, PPP-vertaisen vastaus, jaettu reitti yhdelle sisäiselle osoitteelle ja sovelluksen pyyntö tunnelin yli. Jokaisella vaiheella on oma komentonsa, joten vika on kohdistettavissa eikä mystinen.
Kompakti versio Linux-asiakkaalle näyttää tältä:
sudo tcpdump -ni any 'tcp port 1723 or proto gre' -c 40
ip -4 addr show ppp0
ping -c 3 192.0.2.1
ip route get 10.20.5.10
Windowsissa sama järjestys pätee route printin ja asiakkaassa näkyvän sovittimen tilan kanssa. PPTP on vanha protokolla, ja jos palvelin tarjoaa SSTP:n tai IKEv2:n, siirtyminen on yleensä parempaa ajan käyttöä kuin polun virittäminen, joka riippuu protokollan 47 läpäisystä joka hypyssä. Tarkista korvaajan varmenne ja todennussopimus sen sijaan, että kopioit vanhan profiilin uuteen versioon.