Reititetty VPN-asiakas tavoittaa palvelimen mutta ei LAN-isäntiä

Tunneli nousee, asiakas pingaa VPN-palvelinta, eikä yhden hypyn päässä olevan koneen jaettu kansio vastaa koskaan. Mikään asiakkaan kokoonpanossa ei selitä sitä, koska pyyntö todella lähti asiakkaasta ja todella saapui perille. Epäonnistui paluumatka, ja epäonnistunut laite on yleensä LAN-yhdyskäytävä eikä VPN-isäntä. Vastauspaketin jäljittäminen selittää koko tämän oireluokan.

Seuraa vastausta, älä pyyntöä

VPN-palvelin purkaa asiakkaan paketin salauksen ja välittää sen LANiin niin, että asiakkaan osoite on yhä lähdekentässä. Kohdeisäntä vastaa tähän osoitteeseen, ja nyt sen oma reititystaulu ratkaisee kaiken. Sen oletusyhdyskäytävä ei tiedä tunnelialtaasta mitään, joten vastaus lähtee kohti internetpalveluntarjoajaa ja hylätään jossain sen reitin varrella.

Asiakkaalla oire on äänetön aikakatkaisu: ei kieltäytymistä, ei nollausta, vain ei mitään. Jaetun kansion selaus jumittuu, ping ilmoittaa, ettei vastausta tule, ja palvelimen lokit näyttävät terveiltä, koska palvelin teki tehtävänsä.

Sijoita paluureitti sinne, minne isännät katsovat

Jokainen LAN-isäntä kysyy oletusyhdyskäytävältään, joten yhdyskäytävä on ainoa laite, jonka täytyy tietää, missä tunneliallas sijaitsee. Lisää sinne staattinen reitti, ja jokainen isäntä perii oikean polun ilman, että siihen kosketaan.

Jos yhdyskäytävä jakaa oman osoitteensa DHCP-vaihtoehtona, jaa reitti sillä tavoin, että uudet koneet ottavat sen automaattisesti. Muuten reitti elää yhdessä kokoonpanotiedostossa ja katoaa seuraavassa uudelleenrakennuksessa.

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

Miksi lähde-NAT näyttää korjaavan asian

Asiakasaltaan naamioiminen VPN-palvelimen osoitteen taakse poistaa ongelman poistamalla asiakkaan osoitteen paketista. Vastaukset palaavat silloin palvelimelle, joka jo tietää, miten tunneliin päästään, ja kaikki toimii. Hinta on, että sisäiset isännät eivät enää näe, kuka asiakas on, ja jokainen yhteys näyttää tulevan yhdeltä koneelta.

Tuo vaihtokauppa on joskus oikea, esimerkiksi kun toimittajan laitteelle ei voida antaa staattista reittiä. Älä tee säännöstä nykyistä allasta leveämpää, sillä /24-verkolle kirjoitettu sääntö lakkaa täsmäämästä sinä päivänä, kun allas numeroidaan uudelleen /16-verkoksi, ja ensimmäinen merkki on joukko uusia asiakkaita, jotka yhdistävät eivätkä tavoita mitään.

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

Pilvipolku vaatii kolme asetusta

VPC:ssä sama aukko palaa eri muodossa, koska aliverkolla ei ole lainkaan reittiä asiakasalueelle. Reititystaulu tarvitsee merkinnän tunnelialtaalle, joka osoittaa instanssin verkkoliitäntään, ja liitännästä on kytkettävä lähde- ja kohdetarkistus pois, jotta alusta hyväksyy paketit, joiden lähde ei ole sen oma osoite. Turvaryhmien ja verkon ACL:ien on myös päästettävä allas läpi molempiin suuntiin.

Jokainen laiminlyönti tuottaa oman osittaisen vian. Jätä reititystaulun merkintä pois, niin yksityiset instanssit vastaavat aliverkkoon, joka ei pysty kuljettamaan vastausta takaisin altaalle. Kun tarkistus on yhä päällä, alusta hylkää vastauksen sen jälkeen, kun instanssi on jo lähettänyt sen. Ilman turvaryhmän sääntöä itse pyyntö ei saavu koskaan, ja asiakas näkee aikakatkaisun yhtä kerrosta aiemmin.

Suorita tarkistukset tässä järjestyksessä

Vahvista edelleenlähetys ja suodatuskäytäntö ennen kuin syytät reititystä, sillä isäntä, joka ei välitä eteenpäin, epäonnistuu samalla äänettömällä tavalla. Lue sitten paluupolun voimassa oleva asetus liitännästä, joka kuljettaa tunnelia, koska tiukka suodatin voi hylätä vastauksia, jotka saapuvat odottamattomasta suunnasta.

Lopeta kaappaukseen LAN-isännältä asiakkaan pingatessa sitä. Pyyntö, joka saapuu ilman vastaavaa vastausta, todistaa paluupolun, ja pyyntö, joka ei saavu koskaan, siirtää vian takaisin palvelimeen tai tunneliin.

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

Lähde- ja kohdetarkistus on dokumentoitu elastisen verkkoliitännän oppaassa. Aseta se liitäntään, joka todella kuljettaa tunneliliikennettä, älä samaan instanssiin liitettyyn asiaankuulumattomaan sovittimeen.