hostapd ja OpenVPN yhdellä Pi:llä: kenen oletusreitti on?

Puhelimet liittyvät tukiasemaan, saavat osoitteen eivätkä sen jälkeen tavoita mitään heti, kun tunneli nousee. hostapd on siinä tilassa yleensä terve, samoin OpenVPN; rikki menee oletusreitti, joka joko ei koskaan ollut sillalla tai jonka tunneli korvasi jättämättä reittiä itse VPN-palvelimelle. Tämä ohje palauttaa reitin paikalleen ja todentaa tuloksen asiakkaalta eikä Pi:ltä. Jokainen vaihe on peruttavissa, eikä mikään tässä muuta tunnelin kokoonpanoa ennen kuin tiedät, mitä liikennettä haluat sen sisälle.

Kartoita liitännät ennen kuin muutat mitään

Tuttu asettelu sijoittaa radioverkon ja kaapeliportin br0:n sisään, käynnistää hostapdin siltaa vasten ja jakaa vuokria dnsmasqista, kun OpenVPN-asiakas luo tun0:n. Sitten kolme erillistä vaatimusta näyttää yhdeltä: tukiaseman asiakkaat tarvitsevat Pi:n yhdyskäytäväkseen, Pi tarvitsee reitin internetiin päästäkseen palvelimelleen, ja silta tarvitsee yhdyskäytäväosoitteen, jota ne asiakkaat voivat käyttää.

Lue nykyinen tila ennen sen muuttamista, koska nämä neljä komentoa erottavat liitäntäongelman reititysongelmasta.

ip -br addr
ip route show
ip link show master br0
bridge link show

Jos br0:ssä on osoite mutta ei oletusreittiä, asiakkaat tavoittavat Pi:n eivätkä mitään sen takaa. Jos oletusreitti osoittaa tun0:een tunnelin ollessa alhaalla, Pi:llä ei ole lainkaan toimivaa reittiä, ja asiakkaan oire näyttää täsmälleen samalta. Molemmat tapaukset näyttävät puhelimesta identtisiltä, siksi reititystaulukko on luettava suoraan.

Anna sillalle oletusreitti, joka kuuluu sille

Raspberry Pi OS jättää sillan usein ilman oletusreittiä, kun silta syntyi vasta liitäntätiedoston kirjoittamisen jälkeen. Lohko kuuluu /etc/dhcpcd.conf:een, ja sen pitäisi nimetä ylävirran reititin eikä Pi.

interface br0
static ip_address=192.168.50.2/24
static routers=192.168.50.1
static domain_name_servers=192.168.50.1

Tuossa esimerkissä 192.168.50.1 on olemassa oleva reititin ja 192.168.50.2 on Pi:n siltaosoite samassa aliverkossa, joten korvaa se omalla suunnitelmallasi sen sijaan että kopioit numerot. Sillan jäsenten ei myöskään pidä pyytää reitittimiä, muuten Pi:lle jää kilpailevat oletusreitit, joiden voittaja riippuu metriikasta ja ajoituksesta eikä aikomuksesta.

Komennon systemctl restart dhcpcd jälkeen ip route show default:n pitäisi listata br0 kerran eikä kaksoiskappaletta kaapeliportista. Vahvista haku eikä taulukko, koska vanhentunut merkintä voi istua voittavan vieressä: ip -4 route get 203.0.113.10:n on nimettävä br0. Osoite tulee TEST-NET-3-dokumentaatioalueelta, joten se ei voi törmätä oikeaan palvelimeen tätä lukiessasi.

Estä tunnelia kaappaamasta reittiä omaan palvelimeensa

OpenVPN-asiakas, joka hyväksyy redirect-gateway:n, ottaa oletusreitin ja osoittaa sen tunneliin. Se on oikein, kun jokaisen tukiaseman asiakkaan pitäisi käyttää VPN:ää, ja väärin, kun vain joidenkin kohteiden pitäisi. Kummassakin tapauksessa Pi:n oma yhteys palvelimeen ei saa kulkea sen tunnelin sisällä, jota se yhä rakentaa. OpenVPN lisää isäntäreitin etäpäähän alkuperäisen yhdyskäytävän kautta, kun se uudelleenohjaa oletusreitin, ja juuri tämä käyttäytyminen pitää siirron elossa; jos reitti puuttuu, tunneli romahtaa heti kun se vakiintuu.

Nopea vertailu tuosta siirtoreitistä ennen yhteyttä ja sen jälkeen on kymmenen sekunnin arvoinen. ip -4 route get 203.0.113.10:n pitäisi nimetä alikerroksen laite molemmissa tiloissa, vain metriikka muuttuu. Jos se nimeää tun0:n tunnelin noustua, isäntäreittiä ei koskaan asennettu ja seuraava uudelleenyhdistäminen epäonnistuu.

Kun vain valittujen etuliitteiden pitäisi ylittää tunneli, käytä route-nopull:ää ja lisää haluamasi reitit käsin tai työnnä kapeampi joukko palvelimelta. Silta pitää oletusreitin siinä mallissa, ja DNS:stä tulee seuraava päätös: dnsmasqin välitys kotiresolverille on järkevää vain niille nimille, jotka todella asuvat siellä.

Päätä välityksen ja NAT:in tarina

Täysi tunneli vaatii välityksen käyttöön Pi:llä ja etäpuolen yhdyskäytävän, joka on halukas reitittämään tukiaseman aliverkon. Tarkista välitys ennen kaikkea muuta, koska nolla tekee jokaisesta reittimuutoksesta merkityksettömän.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

NAT-sääntö on oikotie, joka toimii, kun palvelin ei hyväksy tukiaseman etuliitettä, hintana se, että jokainen asiakas näkyy Pi:n tunneliosoitteena etäpuolen lokeissa. Etuliitteen reitittäminen ilman NAT:ia pitää osoitteet näkyvinä ja riippuu paluureitistä 192.168.50.0/24:lle kotipuolella.

Kirjoita valinta palomuurisääntöjen viereen, koska suunnitelmassa näkymätön NAT-sääntö muuttuu selittämättömäksi kuuden kuukauden kuluttua. Pidä IPv6 samassa päätöksessä; toimiva IPv4-reitti rikkinäisen IPv6-reitin vieressä luetaan selaimessa yhä puoliksi rikkinäiseksi.

Vahvista asiakkaalta ja palauta sitten siististi

Testaa tässä järjestyksessä puhelimesta tai kannettavasta tukiasemassa: vuokra dnsmasqista, ping siltaosoitteeseen ja sitten kohde tunnelin etäpuolella. Jokainen vaihe eristää yhden kerroksen sen sijaan että tuottaisi yhden hyödyttömän virheen.

ip -4 route get 203.0.113.10
ping -c 3 -I br0 203.0.113.10

Vahvista sitten, että Pi:llä on yhä oma ulospääsynsä: ip route get 203.0.113.10:n pitäisi nimetä alikerroksen laite, ja ping -c 3 -I br0 203.0.113.10:n pitäisi vastata, jos palvelin sallii ICMP:n. Jos kaksi ensimmäistä asiakasvaihetta menevät läpi ja kolmas epäonnistuu, vika on välityksessä tai NAT:issa. Jos toinen vaihe epäonnistuu, silta tai DHCP on yhä vaillinainen.

Palautus on yksi tiedostomuokkaus ja kaksi komentoa: poista lohko, käynnistä dhcpcd uudelleen ja korvaa oletusreitti nimenomaisesti komennolla ip route replace default via 192.168.50.1 dev br0. Tee se ennen huoltoikkunan sulkeutumista eikä sen jälkeen, koska oletusreittinsä menettänyt Pi on tavoittamaton siitä verkosta, jota käyttäisit sen korjaamiseen.