LAN-reititin ja VPN-asiakas: kaksi laitetta, kaksi reititystaulua

Kaksi laitetta välittää pakettia ja kumpikin pitää omaa tauluaan. LAN-reititin tietää, että etäprefiksi kuuluu VPN-asiakkaalle, ja VPN-asiakas tietää, miten siihen prefiksiin päästään sen tunnelin kautta. Määritä vain ensimmäinen taulu, niin paketti saapuu koneelle, jolla ei ole vastaavaa reittiä, ja lähtee siksi uudelleen oletusreittiä. Se on koko vika, ja LANin puolelta se näyttää reitityssilmukalta, koska sellainen se melkein on.

Piirrä kaksi hyppyä ennen kuin kosket reittiin

Ota havainnollinen asetelma: LAN-isännät osoitteessa 192.168.50.0/24, tavallinen reititin osoitteessa 192.168.50.1, oma asiakas osoitteessa 192.168.50.15 ja etä-LAN osoitteessa 10.60.0.0/24, joka on tavoitettavissa vain sen tunnelin kautta, jonka asiakas pitää. Kumpikaan yksityisistä alueista ei mene toisen päälle, ja tunnelilla on oma osoitesuunnitelmansa.

Molemmat yksityiset alueet ovat tärkeitä, koska ne ratkaisevat, mikä laite voi vastata. Etäpuoli näkee paketin saapuvan asiakkaan tunneliosoitteesta, ja sen vastauksen on löydettävä tie takaisin osoitteeseen 192.168.50.0/24. Jos vain lähtevä suunta on määritetty, pyyntö voi toimia vastauksen kadotessa.

Vaihe 1: osoita reititin asiakkaaseen, älä tunneliin

Lisää LAN-reitittimeen kohdereitti, jonka seuraava hyppy on asiakkaan LAN-osoite:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

Tämä tietue sanoo ”toimita se koneelle, joka osaa tunneloida”. Se ei kerro mitään siitä, miten tunneli rakennetaan, eikä se korvaa asiakkaan omaa reittiä. Hallitussa reitittimessä vastine elää laitteen staattisten reittien sivulla; Linux-reitittimessä se kuuluu LANin omistavan liitännän asetukseen, ei kuoreen, jonka suljet.

Tarkista toisen komennon vastaus. Jos se ilmoittaa asiakkaan gatewayksi ja LAN-liitännän deviceksi, ensimmäinen hyppy on oikein ja loput työt ovat toisella koneella.

Vaihe 2: anna asiakkaalle oma reitti tunnelin puolella

Asiakas vastaanottaa nyt paketin osoitteelle 10.60.0.0/24 ja katsoo omaa tauluaan. Jos sen tunneliasetus asensi reitin tälle prefiksille, paketti jatkaa salattuna. Jos ei, paketti osuu tavalliseen oletukseen ja palaa osoitteeseen 192.168.50.1, joka lähettää sen takaisin asiakkaalle.

Katso ennen kuin lisäät mitään:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

Puuttuva prefiksireitti kaikissa tauluissa on se löydös, jota etsit. Lisää se tunnelin oman asetuksen kautta, jotta seuraava uudelleenyhdistäminen asentaa sen uudelleen; käsin tehty ip route add katoaa istunnon mukana ja palauttaa vian kaikkein hankalimpaan hetkeen. Seuraava hyppy on tunnelin liitäntä tai osoite, jonka VPN määrittää vertaisekseen asiakkaasta riippuen, ja vertaisen osoitteen pitäisi tulla nykyisestä profiilista eikä vanhasta muistiinpanosta.

Silmukka ei käytännössä ole ääretön: TTL laskee joka kierroksella ja paketti kuolee aikakatkaisuvastauksella. Siksi toistuva traceroute voi viitata sykliin, kun taas asiakas, joka ei yksinkertaisesti välitä, pudottaa saman paketin äänettömästi.

Vaihe 3: salli edelleenlähetys ja valitse paluureitti

Vastaanottaminen ja edelleenlähettäminen ovat eri oikeuksia. net.ipv4.ip_forward=1 asiakkaassa sallii läpikulun ytimen tasolla, ja palomuurisäännön on silti sallittava se LAN-liitännän ja tunnelin välillä. Sääntö, joka sallii pääsyn asiakkaan omaan hallintasivuun, ei salli läpikulkua etä-LANiin, ja ero on helppo jättää huomaamatta, kun sama isäntä vastaa ping-testeihin paikallisesti.

Etäpuolella on peiliongelma. Sen on tiedettävä, että 192.168.50.0/24 on tavoitettavissa tämän todennetun asiakkaan kautta. OpenVPN on tässä tapauksessa yleensä asiakaskohtainen reitti, jonka palvelimen asetukset työntävät, tai palvelimella oleva asiakaskohtainen tiedosto, joka ilmoittaa asiakkaan takana olevan LANin. Ilman sitä etä-LAN joko pudottaa vastauksen tai lähettää sen omalle oletusyhdyskäytävälleen eli internettiin.

Lähdeosoitteen käännös on vaihtoehto, kun LAN-prefiksiä ei voi mainostaa. Asiakkaan rajattu masquerade-sääntö kirjoittaa lähteen tunneliosoitteeksi, ja vastaukset palaavat silloin luonnollisesti. Se myös kätkee, mikä LAN-isäntä pyynnön teki, eikä itsessään salli etäpuolen aloittaa yhteyksiä sisäänpäin. Valitse tämä kompromissi tietoisesti sen sijaan, että lisäisit yleisen masqueraden ja löytäisit sivuvaikutuksen myöhemmin.

Vaihe 4: tee molemmista päätöksistä pysyviä ja testaa sitten todellinen polku

Jokaisella reitillä on omistaja, ja omistaja on asetus, joka luodaan uudelleen käynnistyksessä tai uudelleenyhdistämisessä. Reitittimessä se voi olla staattisen reitin merkintä; asiakkaassa se voi olla VPN-profiili, NetworkManager tai systemd-networkd. Varmista yhdistämällä tunneli uudelleen ja käynnistämällä asiakas uudelleen ja lukemalla taulu sitten uudelleen sen sijaan, että luottaisit muokkaukseen.

Pidä tunnelin ulkoyhteyttä kantava oletusreitti koskemattomana. Sen korvaaminen asetusten ”yksinkertaistamiseksi” katkaisee salatun polun ennen kuin mikään sisäinen liikenne ehtii käyttää sitä, ja oireena on tunneli, joka ei koskaan palaudu muutoksen jälkeen.

Testaa tavallisesta LAN-isännästä, älä asiakkaasta, koska asiakkaalla syntyvä pyyntö ei koskaan harjoita reitittimen ensimmäistä hyppyä. Hae palvelu, joka on olemassa vain etä-LANissa, ja vahvista vastauksen runko, ja katso sitten asiakkaan laskureista tai lokeista, että läpikulku tapahtuu. Yksityiset hypyt näyttävä sisäinen traceroute todistaa edelleenlähetyksen, ei salausta: ulompi polku on erillinen havainto, ja vain tunnelin omat liitännän laskurit näyttävät, mitä sen kautta lähti.