Miksi Access Serverin asiakkaat eivät ole tavoitettavissa lähiverkosta

Kannettava tietokone yhdistää, tunneli on pystyssä ja pyynnöt sisäiseen palveluun jäävät roikkumaan yhteyden muodostuksessa. Itse palvelussa pyyntö saapuu osoitteesta kuten 10.90.0.25, vastaus lähtee kohti oletusyhdyskäytävää, eikä mitään tule takaisin, koska tuo yhdyskäytävä ei tiedä lainkaan, missä 10.90.0.25 sijaitsee. Toisesta päästä sama vika näyttää sisäiseltä isännältä, joka ei voi pingata yhdistettyä asiakasta. Molemmat ovat yksi puuttuva objekti: paluureitti VPN-asiakaspooliin, jonka vain yksityinen verkko voi lisätä.

Lue lähdeosoite, jonka palvelu näkee

Tuo yksi kenttä ratkaisee kaiken muun. Jos sisäinen palvelu näkee poolin osoitteen, Access Server reitittää sen sijaan että piilottaisi asiakasliikennettä, ja jokainen vastaus täytyy reitittää takaisin pooliin. Jos se näkee sen sijaan palvelimen oman yksityisen osoitteen, palvelin tekee maskeerausta ja paluupolku toimii jo, mutta sen hinta on jokaisen asiakaskohtaisen identiteetin menettäminen palvelun lokeista ja käyttösäännöistä.

Vertaile molempia päitä ennen kuin muutat mitään. Palvelimella listaa tunneliliitännät ja niiden osoitteet; asiakkaalla varmista, minkä noista osoitteista se todella pitää; sisäisellä isännällä katso aktiivista yhteyttä.

ip -br addr show
ss -tnp state established '( dport = :443 )'
ip route get 10.90.0.25

Viimeinen komento on se, joka epäonnistuu rikkoutuneessa tapauksessa: se joko ilmoittaa tunnelin etuliitteen tavoittamattomaksi tai, mikä pahempaa, palauttaa oletusyhdyskäytäväsi, ja niin vastaukset päätyvät internetiin.

Älä oleta vain yhtä poolia. Palvelimella voi olla dynaaminen alue sekä käyttäjäkohtaiset staattiset mappaukset, ja staattinen osoite voi olla kokonaan dynaamisen etuliitteen ulkopuolella. Jos reitität vain sen alueen, jonka muistat, kiinteiden osoitteiden käyttäjät pysyvät rikki ja kaikki muut ilmoittavat ongelman korjatuksi.

Lisää reitti sinne, missä vastauksesta päätetään

Reitti kuuluu yhdyskäytävälle, jota sisäinen palvelu jo käyttää, ei palvelulle, ellei se reititä omaa liikennettään. Osoita se Access Serverin tavoitettavaan yksityiseen osoitteeseen, joka on eri arvo kuin asiakkaan pitämä tunneliosoite.

ip route add 10.90.0.0/24 via 10.0.1.5
ip route get 10.90.0.25

Pilviverkossa sama lause muuttuu reititystaulun merkinnäksi, jonka kohde on instanssi tai verkkoliitäntä, jossa palvelin toimii, ja lähde- ja kohdetarkistus on poistettu käytöstä kyseisessä liitännässä. Huomaa, mitä merkintä ei tee: reitti ei ole käyttöoikeus, joten suojausryhmien, verkon ACL:ien ja isännän palomuurin on edelleen sallittava liikenne.

Tee siitä pysyvä ja pidä poolien koot rehellisinä. Kaksi erillistä poolia tarvitsee kaksi reittiä, ja määritetyn etuliitteen yli kasvava pooli tuottaa hiljaa asiakkaita, joiden vastauksilla ei ole minne mennä. Jos hallitset poolien alueita, valitse yhteenveto, jonka voit reitittää kerran ja jättää rauhaan.

Edelleenlähetys ja suodattimet on sovitettava reitin kanssa

Reititys on vain puoli matkaa. Palvelimelle on sallittava edelleenlähetys tunnelin ja yksityisen liitännän välillä, mikä Linuxissa tarkoittaa net.ipv4.ip_forward plus edelleenlähetysketjua, joka sallii liitäntäparin, ja kovennetulla isännällä yleensä erillinen sääntö kumpaankin suuntaan.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A5 forward

Tilallinen suodatus selittää oireen, joka johtaa ihmiset väärälle polulle. Vastaus vakiintuneen vuon sisällä ei tarvitse uutta saapuvan liikenteen sääntöä, joten SYN-ACKin jälkeen roikkuvaa yhteyttä ei estä puuttuva accept-sääntö; se pudotetaan tai reititetään väärin. Pidä tämä ero, koska se erottaa reititysmuutoksen palomuurimuutoksesta.

Epäsymmetriset paluupolut ovat saman ongelman hiljaisempi versio. Jos pooliin pääsee kaksi reittiä ja vastaus valitsee sen, joka lähtee eri liitännästä kuin mistä pyyntö saapui, tiukka paluupolun suodatus pudottaa sen ja vuo epäonnistuu vain osalla asiakkaista.

Reititetty vai maskeerattu: valitse tietoisesti

Reititetty tila säilyttää asiakkaan pooliosoitteen palvelussa, mikä mahdollistaa asiakaskohtaisen lokituksen ja käytännön, ja vastineeksi jokainen sisäinen verkko, jonka on vastattava asiakkaalle, tarvitsee poolin reitin. Maskeerattu tila poistaa tämän vaatimuksen, koska vastaukset palaavat palvelimelle, mutta palvelu ei enää erota yhtä asiakasta toisesta eikä voi aloittaa mitään tiettyä asiakasta kohti.

Tämän käyttäytymisen muuttaminen käyvässä palvelimessa katkaisee olemassa olevat istunnot, joten testaa ensin yhdellä asiakkaalla ja yhdellä vuolla. Jos vaihto on oikea vastaus, se on palvelimen konfiguraatiopäätös, ei jotain, mitä kierretään lisäämällä reittejä, joista tulee tarpeettomia.

Asiakkaan takana oleva aliverkko on erillinen tehtävä

Laitteen tavoittaminen kannettavan omasta lähiverkosta ei ole sama kuin kannettavan tunneliosoitteen tavoittaminen. Se vaatii, että asiakas toimii aliverkon yhdyskäytävänä: ilmoitettu asiakaspuolen verkko, edelleenlähetys käytössä asiakkaan käyttöjärjestelmässä ja reitti kyseisessä lähiverkossa takaisin asiakkaan suuntaan. Yksityisverkon reitin lisääminen kannettavan kotialueelle ei tee tätä, ja se luo ristiriitoja, kun kahdella käyttäjällä on sama kotialue.

Suunta on myös käytäntökysymys. Lupa asiakkaalle avata yhteys sisäiseen palveluun ei automaattisesti salli sisäisen isännän avata yhteyttä kyseiseen asiakkaaseen. Tarkista palvelimen käyttökäytäntö ja asiakkaan isännän palomuuri ennen kuin päättelet polun olevan rikki.

Varmista yhdellä vuolla ja yhdellä kaappauksella

Todista polku yhdellä yhteydellä yleisen tavoitettavuustestin sijaan. Tarkkaile samaa vuota molemmissa päissä: palveluun saapuva pyyntö ja siitä lähtevä vastaus.

tcpdump -ni any host 10.90.0.25 and port 443

Ennen korjausta kaappaus näyttää vastauksen lähtevän kohti yhdyskäytävää, joka ei reititä sitä. Korjauksen jälkeen vastaus lähtee kohti palvelinta ja vuo täydentyy. Vahvista sitten reitti, jota yhdyskäytävä käyttäisi toisen asiakasosoitteen kohdalla, jotta kattamaton pooli näkyy nyt eikä viikon päästä.

Lopeta neljään tarkistukseen, jotka sulkevat asian: palvelun lähdeosoite vastaa tarkoittamaasi tilaa, yhdyskäytävällä on reitti jokaiseen käytössä olevaan pooliin, edelleenlähetys ja suodattimet sallivat molemmat suunnat, ja yksi todellinen vuo kulkee päästä päähän. Access Serverin reitityksen UKK esittää saman periaatteen asennetulle versiolle, jonka tuettu konfigurointiliittymä voi poiketa vanhemmista oppaista.