VPN-portin avaaminen ei päästä asiakkaita LAN-verkkoon

Tunneli nousee, asiakas todennetaan, mutta yhdyskäytävän takana oleva LAN pysyy näkymättömänä. Sääntö, jonka piti korjata tämä, sallii VPN-portin ja toimii täsmälleen kirjoitetusti, koska se sääntö koskee paketteja, jotka on osoitettu yhdyskäytävälle itselleen. Asiakkaan liikenne yhdyskäytävän takana olevalle isännälle on toinen kohde ja toinen ketju. Onnistunut kirjautuminen ei muuta sitä, kumpaa ketjua ydin tarkistaa.

Kaksi ketjua, kaksi eri kohdetta

Paketin kohtalon ratkaisee se, mihin se menee, ei se, miten se saapui. Yhdyskäytävän osoitteeseen osoitettu liikenne toimitetaan paikallisesti ja arvioidaan syötesäännöillä. Liikenne, jonka yhdyskäytävä välittää eteenpäin, arvioidaan edelleenlähetyssäännöillä. Sama tunneliliitäntä voi tuottaa molempia pakettityyppejä, joten yksi sääntö ei voi kattaa molempia töitä.

Koko myytti yhdessä lauseessa: kuuntelijan salliminen ei kerro mitään sen takana olevan verkon sallimisesta. Ne ovat kaksi erillistä päätöstä erillisine todisteineen, eikä liitännän nimi molemmissa yhdistä niitä.

Mitä kuuntelijan sääntö todella sallii

Kuuntelijan paketit päättyvät VPN-prosessiin, ja juuri se mahdollistaa tunnelin pystyttämisen. Yhdyskäytävän hallintasivu ja paikallinen diagnostiikkavastaus käyttävät myös isännän omaa syötepolkua, siksi testi yhdyskäytävälle onnistuu, kun taas kaikki sen takana epäonnistuu. Molemmat tulokset ovat oikein eikä kumpikaan kerro LAN-verkosta.

Kun prosessi purkaa asiakkaan liikenteen toiseen kohteeseen, paketti astuu edelleenlähetyksen polulle ja tarvitsee siellä luvan. Onnistunut todennus ratkaisee, kuka asiakas on; se ei ratkaise, minne asiakas saa mennä. Kahdella kysymyksellä on eri omistajat, eri lokit ja eri virheilmoitukset.

Testaa asiakkaalta, älä koskaan yhdyskäytävältä

Yhdyskäytävällä luotu testi seuraa isännän omaa lähtöpolkua ja voi onnistua, vaikka edelleenlähetyksen polku on suljettu. Aloita testi asiakkaalta ja seuraa virtauksen molempia päitä.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

Jos pyyntö näkyy tun0-liitännällä eikä mitään saavu kohteeseen, paketti pudotetaan saapumisen jälkeen, mikä viittaa edelleenlähetyssääntöihin tai kohteen omaan suodatukseen. Jos tun0-liitännällä ei näy mitään, asiakas ei edes lähetä sitä tunneliin, ja ongelma on asiakkaan reitityksessä eikä yhdyskäytävän käytännössä. Vertaa sitä pyyntöön, joka lähtee oikein eikä palauta mitään, mikä on paluureitin tapaus.

Edelleenlähetys tarvitsee kolme asiaa, ei yhtä

Ytimen edelleenlähetys on oltava käytössä, suodatinsäännön on hyväksyttävä virtaus ja kohteen on oltava saavutettavissa siten, että vastauksella on paluureitti. Jos jokin kolmesta puuttuu, hiljaisuus on asiakkaan näkökulmasta sama.

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

Lue kolme tulosta yhdessä. Nolla ensimmäisessä tekee kahdesta muusta merkityksettömiä, ja toisessa oleva oletusarvoinen hylkäyskäytäntö pudottaa asiakkaan paketit, kun yhdyskäytävän oma liikenne jatkaa toimintaansa. Kolmas tulos näyttää, miksi kuuntelijan sääntö ei koskaan ollut ongelma.

Pidä kaksi sääntöjoukkoa erillään dokumentaatiossa

Kirjoita kuuntelijan sääntö ja välitetyn palvelun sääntö eri riveille, eri omistajin ja perusteluin. Kun VPN-portti muuttuu tai uusi palvelu julkaistaan, tämä erottelu estää yhtä muutosta hiljaa laajentamasta toista.

Sen sijaan että pitäisit jokaista todennettua vastapuolta luotettuna LAN-jäsenenä, käytä kapeita sääntöjä niille asiakasalueille ja palveluille, jotka niitä tarvitsevat. StrongSwanin edelleenlähetyksen muistiinpanot kuvaavat saman rajan paluureitin ja käännöksen puolen, mikä on jälleen kolmas päätös.

Lopuksi pidä kerrokset suorina, kun käyttäjä hylätään. Jos pyyntö saapuu isännälle ja sovellus hylkää tilin, korjaa sovelluksen käyttöoikeus sillä kerroksella; edelleenlähetyksen laajentaminen ei voi antaa tiedostojen jakamisen tunnusta ja laajentaa pääsyä kaikille muille, jotka yhdistävät onnistuneesti.