Miksi VPN-asiakkaan takana oleva palvelin vastaa tunnelin kautta

Saapuvat yhteydet isäntään, joka myös ajaa VPN-asiakasta, epäonnistuvat hyvin erityisellä tavalla: kättely saapuu, taustaprosessi vastaa ja asiakas ei saa mitään takaisin. Mikään ei estä porttia. Vastaus lähti tunnelin kautta, koska tunneli omistaa oletusreitin ja ydin reitittää vastaukset kohteen mukaan, ei muistin mukaan siitä, mistä pyyntö tuli. Taustaprosessi on kunnossa ja portti on auki.

Vastaus reititetään, ei muisteta

VPN-asiakas, joka asentaa oletusreitin, lisää merkinnän, joka ohittaa LAN-yhdyskäytävän, joko metriikalla tai jakamalla avaruuden kahteen tarkempaan puoliskoon. Lähtevät paketit valitsevat nyt tunnelin rajapinnan. Ydin ei koskaan kysy, mistä vastattava paketti alun perin saapui. Tämä yksi puute selittää jokaisen seuraavan oireen.

Eteenpäin suunta reititetään kohteen mukaan, ja niin myös paluusuunta. Vastaus on osoitettu julkiselle asiakkaalle, jonka tunneli mielellään kuljettaa. Kauempi pää vastaanottaa paketin, jonka lähdettä se ei omista, hylkää sen, ja alkuperäinen asiakas odottaa, kunnes aika loppuu.

Tiukka käänteisen reitin suodatus voi pudottaa saapuvan paketin ennen kuin taustaprosessi edes lukee sen. Tarkista se laskuri ensin, sillä suodattimen pudotus ja reititysvirhe näyttävät ulkoa samoilta.

ip route show default
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.eth0.rp_filter
nft list ruleset | grep -A3 'hook forward'

Ensimmäinen komento näyttää, mikä oletusreitti voittaa juuri nyt. Toinen kertoo, sovelletaanko tiukkaa suodatusta maailmanlaajuisesti vai rajapintakohtaisesti, ja kolmas näyttää minkä tahansa välitysketjun säännön, joka voi olla osallisena.

Kolme tapaa säilyttää paluureitti

Palvelun kohteen jättäminen tunnelin ulkopuolelle on kapein vaihtoehto. LAN-yhdyskäytävään osoitettu isäntäreitti sekä taustaprosessi, joka on sidottu fyysiseen osoitteeseen kaikkien osoitteiden sijaan, pitää sen yhden virtauksen tunnelin ulkopuolella. Muutos on paikallinen ja helppo peruuttaa.

Käytäntöpohjainen reititys on yleinen vastaus. Lähdeosoitteeseen tai palomuurimerkkiin sidottu sääntö valitsee taulun, jonka oletus osoittaa WAN-yhdyskäytävään, kun isännän omat yhteydet jatkavat tunnelin käyttöä. Pidä prioriteetti selkeänä, jotta sääntö ei voi myöhemmin jäädä varjoon.

ip rule add from 203.0.113.25/32 table 100 priority 100
ip route add default via 192.0.2.1 dev eth0 table 100
ip route get 198.51.100.7 from 203.0.113.25

Kaksi ensimmäistä komentoa rakentavat vaihtoehtoisen reitin vastauksille, joiden lähde on julkinen osoite. Kolmas kysyy ytimeltä, minkä reitin juuri tuo lähde ja kohde kulkisi, ja niin vahvistat, että säännöllä on jotain vaikutusta.

Lähteen käännös on kolmas vaihtoehto ja ainoa, joka selviää reitittimestä, joka tekee jo NAT:n palvelun edessä. Vastauksen on palattava sille reitittimelle, ja maskaus WAN-rajapintaan saavuttaa sen piilottaen asiakkaan palvelun lokeista. Oletusreitin vaihtaminen käsin yhteyden jälkeen on diagnostiikkaa, koska asiakas kirjoittaa taulun uudelleen seuraavassa uudelleenyhdistämisessä.

Kun laatikko reitittää myös lähiverkkoa varten

Sama vika ilmaantuu yhden hypyn kauempana, kun isäntä reitittää sen takana oleville laitteille. Saapuva yhteys välitetään sisäiselle laitteelle, jonka ainoa paluureitti on tunneli, ja vastaus saavuttaa ulkoisen asiakkaan tarjoajan osoitteesta. Sisäinen laite toimii oikein koko ajan.

Yhteyksien seuranta näkee silloin vastauksen virtaukselle, jota se ei koskaan kirjannut, ja pudottaa sen. Kohteen käännös toimittaa saapuvan yhteyden laitteelle, ja lähteen käännös saa vastauksen näyttämään reitittimestä itsestään tulevalta.

Käytäntöreitti, joka pitää välitetyn portin WANissa samalla kun reitittimen oma liikenne käyttää tunnelia, on siistimpi vastine. Ilman lähteen käännöstä vastaus on osoitettu ulkoiselle asiakkaalle, eikä sisäisellä laitteella ole sille osoitteelle lainkaan reittiä.

Kolme koetta, jotka erottavat syyt

Tee kolme koetta: yhteys laatikkoon internetistä, yhteys siitä ulos julkiseen isäntään ja nimikysely. Kun kaksi ensimmäistä ovat eri mieltä, paluureitti on syyllinen. Kun nimet epäonnistuvat molempiin suuntiin, ratkaisija on toinen vika, joka vain jakaa tunnelin.

Korjaa ensin reitityskysymys, katso sitten nimiä. Molempien sekoittaminen on tapa, jolla toimiva palvelin saa syyn rikkinäisestä ratkaisijasta.

Kirjaa, minkä rajapinnan poikkeus nimeää, ja pidä kokoonpano versionhallinnassa. Rajapintaa vasten kirjoitettu sääntö, joka nimetään uudelleen päivityksen jälkeen, menee läpi tänään ja epäonnistuu seuraavan uudelleenkäynnistyksen jälkeen.