Tiedostopalvelin avautuu hyvin, ja viereisen ikkunan videopuhelu alkaa pätkiä. Mikään ei ole hidasta eikä mikään MTU ole väärin: asiakkaasi otti vastaan palvelimen antaman reittiluettelon, joten jokainen paketti lähtee nyt toimiston palomuurin kautta. Korjaus ei ole uusi virityslipuke vaan päätös siitä, kenelle asiakkaan reittitaulukko kuuluu. Se päätös kuuluu yhteen paikkaan, ja alla olevat vikatilat kertovat, minkä paikan itse asiassa valitsit.

Päätä, kenelle reittitaulukko kuuluu

Kolme omistajaa on mahdollista. Palvelin voi työntää reittejä ja oletusyhdyskäytävän, jolloin asiakas asentaa mitä käsketään ja muuttuu täystunneliksi. Asiakasprofiili voi ottaa omistajuuden hylkäämällä työnnöt ja kantamalla omat reittirivinsä. Työpöydän yhteyshallinta voi myös omistaa päätöksen omien reitti- ja oletusreittiominaisuuksiensa kautta.

Jokainen valinta epäonnistuu eri tavalla, minkä vuoksi taulukko kannattaa lukea ennen profiilin muokkaamista. Rivi, joka vastaa oirettasi, on omistaja, joka sinulla todella on.

OwnerWhere it livesResult
Serverserver config, redirect-gateway, pushed routesclient becomes a full tunnel
Profileroute-nopull and its own route linestunnel up, office prefix missing
Managernever-default plus its own routesdesktop decides, profile ignored

Valitse yksi ja kirjoita se muistiin. Kahden sekoittaminen jättää isännän, jonka oletuspolku on ristiriidassa oman dokumentaationsa kanssa, eikä seuraava insinööri voi tietää, mikä kerros voitti. Poista häviäjä nimenomaisesti.

route-nopull suodattaa työntöjä, se ei lisää reittejä

route-nopull kuuluu asiakasprofiiliin, ja sen järjestys siinä tiedostossa on merkityksetön, koska se hylkää vain palvelimelta tulevia arvoja. Se hylkää työnnetyt reitit, mukaan lukien työnnetyn oletusreitin, samalla kun tunneli nousee silti normaalisti.

Seuraus, jonka ihmiset ohittavat, on että työnnetyt DHCP-asetukset lähtevät niiden mukana. Myös palvelimen lähettämät DNS-asetukset hylätään, joten sisäiset nimet lakkaavat ratkeamasta, vaikka tunneli on terve ja palvelin on tavoitettavissa osoitteella.

Tämä jättää tunnelin ilman polkua toimiston etuliitteeseen, ellet lisää sitä itse: route-nopull ja sen perään route 10.30.0.0 255.255.0.0 samassa profiilissa. Se rivi kantaa osoitteen ja maskin; se ei nimeä seuraavaa hyppyä.

Vaihtoehtoinen muoto lisää yhdyskäytävämerkin, route 10.30.0.0 255.255.0.0 vpn_gateway, joka osoittaa merkinnän tunneliin nimellä. Tuojat eroavat siinä, kääntävätkö ne tuon muunnelman, joten tarkista tallennettu yhteys, jos merkintä puuttuu ytimen taulukosta.

Vahvista reittihauilla, älä pingillä

Ping kertoo, että jokin vastasi. Reittihaku kertoo, minkä liittymän ydin valitsisi, ja se on kysymys, jonka todella esitit. Neljä lyhyttä komentoa erottaa puuttuvan reitin reitistä, joka osoittaa väärään laitteeseen.

Lue, mitä tunneli asensi komennolla ip route show dev tun0. Täysi tulosteettomuus tarkoittaa nollaa reittiä, mikä ei ole toimiva jaettu tunneli, ja se on tavallinen tulos suodattimen lisäämisestä ilman nimenomaista riviä.

Tarkista sitten yksi toimiston osoite komennolla ip route get 10.30.5.7 ja yksi tavallinen internetosoite komennolla ip route get 1.1.1.1. Toisen pitäisi nimetä fyysinen liittymä; jos se nimeää tunnelin, työntöä ei suodatettu lainkaan.

Lue lopuksi ip rule, koska aiemman yrityksen jättämä käytäntösääntö voi ohittaa juuri korjaamasi taulukon. Oikea profiili, jonka päällä on vanhentunut sääntö, näyttää täsmälleen rikkinäiseltä profiililta. Poista viimeksi lisäämäsi sääntö ennen kuin lisäät toisen.

Päällekkäiset aliverkot näyttävät rikkinäiseltä tunnelilta

Kaksi yksityistä aluetta voi olla asiakkaan näkökulmasta identtisiä, ja juuri siinä jaettua tunnelia syytetään jostain, mitä se ei aiheuttanut. Jos toimisto jakaa saman etuliitteen, jota kotireitittimesi käyttää, tunnelireitti kattaa reitittimen ja kotiverkko näyttää katoavan.

Vertaa oman liittymäsi osoitetta reittiin, jonka profiili asentaa, käyttämällä tavallista osoiteluetteloa ennen kuin muutat mitään. Päällekkäisyys on todellinen, eikä mikään profiilivaihtoehto ratkaise sitä. Sen voit korjata, että nimeäminen on selvää, jotta seuraava henkilö näkee kaksi aluetta yhden sijaan.

Rehelliset korjaukset ovat toisen puolen uudelleennumerointi tai osoitteiden kääntäminen toimistossa. Yhden isäntäreitin kiinnittäminen reitittimeen toimii, kunnes reitittimen osoite muuttuu, ja silloin siitä tulee toinen arvoitus ensimmäisen päälle.

Tee päätöksestä uudelleenyhdistämisen kestävä

Käsin kirjoitetut merkinnät eivät kestä uudelleenyhdistämistä, ja yhteyshallinta rakentaa taulukon uudelleen joka kerta, kun profiili käynnistyy. Laita päätös sinne, missä yhteys luodaan, olipa se profiili tai hallinnan tallennetut asetukset. Käynnistä sitten yhteys kerran tarkoituksella uudelleen sen sijaan, että löytäisit käyttäytymisen puhelun aikana. Profiili, joka toimii vain seuraavaan uudelleenyhdistämiseen asti, ei ole valmis.

Harjoittele kolmea polkua kerralla: toimiston isäntä kirjaimellisella osoitteella, sama isäntä nimellä ja tavallinen julkinen sivusto. Keskimmäinen riippuu nimipalvelusta, jonka määritit hylättyäsi työnnetyt DNS-asetukset, ja juuri se epäonnistuu hiljaa.

Aiheeseen liittyvät artikkelit