VPN-asiakas LAN-palvelimessa: miksi vastaukset lähtevät väärää tietä

Oireet noudattavat yhtä kaavaa: isäntä toimii, sitten se yhdistää VPN:ään asiakkaana, ja nyt LAN-asiakkaat tavoittavat sen, kun taas sen vastaukset katoavat. Isännällä tehty kaappaus näyttää, että vastaukset lähtevät tunnelilaitteen kautta LAN-liitännän sijaan. Tunnelissa ei ole mitään rikki, ja korjaus on reitti, ei uudelleenyhdistäminen. Käy alla olevat neljä tarkistusta järjestyksessä ja pysähdy ensimmäiseen, joka epäonnistuu.

Vastaus on uusi paketti, ei paluu samaa tietä

Auttaa hylätä ajatus, että vastaus kulkee takaisin sitä tietä, jonka pyyntö otti. Reititys päätetään pakettikohtaisesti ja suuntakohtaisesti lähettävällä isännällä. Pyyntö, joka saapui tunnelin sisällä osoitteesta 10.64.0.23, ei luo paluureittiä; kun isäntä vastaa, vastaus verrataan taulukkoon uutena pakettina ja lähtee sitä reittiä, joka voittaa.

Siksi täystunnelin asiakas koneessa, joka palvelee myös LANia, tuottaa niin hämmentävän vian. Asiakas asentaa oletusreitin tai kaksi puolikasta oletusreittiä, joita jotkin asiakkaat suosivat, ja vastaus LAN-asiakkaalle vastaa nyt tunnelia. Se menee palveluntarjoajalle, jolla ei ole syytä välittää sitä, ja LAN-asiakas näkee aikakatkaisun, vaikka isäntä on käynnissä ja vastaa paikallisesti. Kaappaus tekee sen ilmeiseksi, ja reititystaulukko selittää sen.

Pidä kaksi aliverkkoa mielessäsi lukiessasi loput. Toinen on VPN-osoiteallas, josta etäasiakkaat tulevat, tässä esimerkissä 10.64.0.0/24. Toinen on LAN, jonka on jatkettava toimintaansa, 172.16.24.0/24 reitittimensä kanssa osoitteessa 172.16.24.1. Vika on siinä, että niiden välinen liikenne ratkaistaan oletusreitillä.

Todista se kaappauksella ja haulla

Ennen kuin muutat mitään, varmista, mitä laitetta vastaus käyttää. Haku on nopeampi kuin kaappaus ja vastaa täsmälleen siihen kysymykseen, johon ydin vastaa pakettia rakennettaessa.

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

Lue vastaus kahdessa osassa. Jos se nimeää dev tun0, isäntä kapseloi vastauksen ja luovuttaa sen palveluntarjoajalle, eikä LAN-asiakas näe sitä koskaan. Jos se nimeää dev eth0, mutta asiakas saa silti aikakatkaisun, reitti on jo oikein ja paketti pudotetaan myöhemmin, mikä on eri ongelma ja eri korjaus.

Saman vaiheen kaappaus ratkaisee epäilyksen, jota ping ei voi. LAN-asiakkaalle saapuva kaiun vastaus todistaa, että jokin tie toimii, ei sitä mikä liitäntä sen kuljetti, joten tee kaappaus itse isännällä ja katso, mistä kehykset lähtevät. Samassa aliverkossa oleva tulostin vastaa edelleen, koska sen suora reitti on täsmällisempi kuin tunnelin oletusreitti. Edelleenohjattu portti epäonnistuu täsmälleen kuten mikä tahansa muukin virta, koska liitännän valitsee taulukko eikä yhteys.

Asenna kapein reitti, joka päihittää tunnelin

Ratkaisee etuliitteen pituus, ei metrijärjestelmä, joten reitti asiakasaltaalle LAN-reitittimen kautta voittaa minkä tahansa oletusreitin, jonka VPN-asiakas asentaa. Metriikkakirurgiaa ei tarvita, ja oletusreitti voi pysyä täsmälleen siinä, mihin asiakas sen asetti.

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

Käytä replace-komentoa add-komennon sijaan, koska uudelleen yhdistävä asiakas on asentanut oman merkintänsä ja toinen add epäonnistuu olemassa olevan reitin virheeseen, joka kuulostaa käyttöoikeusongelmalta. Windows-isännällä vastine on route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, jossa -p pitää merkinnän uudelleenkäynnistysten yli, koska asiakas voi rakentaa taulukon uudelleen, kun tunneli palaa. Nykyisellä Windows-isännällä tuettu vastine on New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, ja vanhempi route-komento säilyy perintömuotona.

Yksi yksityiskohta ratkaisee, onko tämä oikein vai vain uskottavaa: seuraavan hypyn on oltava reititin, joka tosiasiassa omistaa tien takaisin asiakkaille. Reitin osoittaminen osoitteeseen, johon itse päästään tunnelin kautta, luo silmukan, joka näkyy ajoittaisena häviönä eikä puhtaana vikana. Varmista ennen rivin vahvistamista, että seuraava hyppy on LAN-aliverkossa.

Säilytä vastaus uudelleenyhdistämisen jälkeen

Käsin lisätty reitti säilyy parhaimmillaan seuraavaan uudelleenyhdistämiseen. Jos asiakasallas on dynaaminen, kiinnitä se palvelimen kokoonpanoon, jotta reitittämäsi etuliite pysyy etuliitteenä, jonka asiakkaat saavat; muuten merkintä osoittaa tyhjään alueeseen ja oire palaa viikkoja myöhemmin ilman ilmeistä syytä. Reitin kirjoittaminen asiakkaan omaan up-skriptiin on toinen luotettava vaihtoehto, koska se ajetaan sen jälkeen, kun asiakas on kirjoittanut taulukon uudelleen.

Tilallinen palomuuri voi silti kukistaa oikean reitin. Jos kaappaus näyttää nyt, että vastaus lähtee eth0:n kautta, ja asiakas saa silti aikakatkaisun, tarkista, pudottaako isäntä paketin ennen lähetystä. Tiukka käänteisen reitin suodatus ja net.ipv4.conf.all.rp_filter arvoon 1 asetettuna pudottavat paketit, joiden lähdettä ei reititettäisi takaisin ulos siltä liitännältä, jolta ne saapuivat, mikä on täsmälleen se epäsymmetrinen tapaus, jonka juuri loit ja sitten korjasit, ja conntrackin tila kertoo saman tarinan edelleenohjatuille porteille.

Viimeinen tarkistus on se, jonka ihmiset ohittavat: toista haku sen jälkeen, kun tunneli on ollut alhaalla ja noussut uudelleen. Neljän arvon pitäisi vastata sitä, mitä kirjoitit muistiin: kohde, seuraava hyppy, laite ja valittu lähde. Jos jokin niistä on liikkunut, asiakas kirjoitti taulukon uudelleen ja korjaus kuuluu sen koukkuihin eikä shellin historiaan.