hostapd un OpenVPN vienā Pi: kam pieder noklusējuma maršruts?

Tālruņi pievienojas piekļuves punktam, saņem adresi un pēc tam neko nesasniedz, tiklīdz tuneļa savienojums paceļas. hostapd šajā stāvoklī parasti ir vesels, un OpenVPN arī; lūzt noklusējuma maršruts, kas vai nu nekad nav bijis uz tilta, vai arī tunelis to aizstāja, neatstājot ceļu uz pašu VPN serveri. Šī rokasgrāmata atgriež šo maršrutu savā vietā un pierāda rezultātu no klienta, nevis no Pi. Katrs solis ir atgriežams, un nekas šeit nemaina tuneļa konfigurāciju, kamēr nezināt, kādu satiksmi vēlaties tā iekšienē.

Uzskaitiet saskarnes, pirms kaut ko labojat

Pierastais izkārtojums ievieto bezvadu radio un vadu portu br0 iekšienē, palaiž hostapd pret tiltu un izdala nomu no dnsmasq, kamēr OpenVPN klients izveido tun0. Tad trīs atsevišķas prasības izskatās kā viena: piekļuves punkta klientiem vajag Pi kā viņu vārteju, Pi vajag maršrutu uz internetu, lai sasniegtu savu serveri, un tiltam vajag vārtejas adresi, ko šie klienti var izmantot.

Izlasiet pašreizējo stāvokli pirms tā maiņas, jo šīs četras komandas atdala saskarnes problēmu no maršrutēšanas problēmas.

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

Ja br0 nes adresi, bet nav noklusējuma maršruta, klienti sasniedz Pi un neko aiz tā. Ja noklusējuma maršruts norāda uz tun0, kamēr tunelis ir izslēgts, Pi vispār nav strādājoša ceļa, un klienta simptoms izskatās tieši tāpat. Abi gadījumi no tālruņa izskatās vienādi, tāpēc maršrutu tabula jālasa tieši.

Dodiet tiltam noklusējuma maršrutu, kas tam pieder

Raspberry Pi OS bieži atstāj tiltu bez noklusējuma maršruta, ja tilts radās pēc saskarnes faila rakstīšanas. Bloks pieder /etc/dhcpcd.conf, un tam jānosauc augšupējais maršrutētājs, nevis 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

Šajā piemērā 192.168.50.1 ir esošais maršrutētājs, un 192.168.50.2 ir Pi tilta adrese tajā pašā apakštīklā, tāpēc aizstājiet ar savu plānu, nevis kopējiet skaitļus. Tilta dalībniekiem arī nav jāpieprasa maršrutētāji, citādi Pi paliek konkurējoši noklusējuma maršruti, kuru uzvarētājs ir atkarīgs no metrikas un laika, nevis no nodoma.

Pēc systemctl restart dhcpcd ip route show default vienreiz jāuzrāda br0 un bez dublikāta no vadu porta. Apstipriniet meklēšanu, nevis tabulu, jo vecs ieraksts var sēdēt blakus uzvarētājam: ip -4 route get 203.0.113.10 jānosauc br0. Šī adrese nāk no TEST-NET-3 dokumentācijas diapazona, tāpēc tā nevar sadurties ar īstu serveri, kamēr jūs to lasāt.

Apturiet tuneli, lai tas nenolaupītu ceļu uz savu serveri

OpenVPN klients, kas pieņem redirect-gateway, pārņem noklusējuma maršrutu un novirza to tunelī. Tas ir pareizi, kad katram piekļuves punkta klientam jāizmanto VPN, un nepareizi, kad tikai dažiem galamērķiem. Jebkurā gadījumā Pi paša savienojumam ar serveri nav jāceļo tā tuneļa iekšienē, kuru tas vēl būvē. OpenVPN pievieno maršrutu uz attālo pusi caur sākotnējo vārteju, kad novirza noklusējuma maršrutu, un tieši šī uzvedība uztur transportu dzīvu; ja šī maršruta nav, tunelis sabrūk, tiklīdz tas izveidojas.

Ātrs šī transporta ceļa salīdzinājums pirms un pēc savienojuma ir vērtīgs tās desmit sekundes. ip -4 route get 203.0.113.10 abos stāvokļos jānosauc apakšējā slāņa ierīce, mainās tikai metrika. Ja pēc tuneļa pacelšanas tas nosauc tun0, resursdatora maršruts nekad netika instalēts un nākamais atkārtotais savienojums neizdosies.

Kad tuneli drīkst šķērsot tikai atlasīti prefiksi, izmantojiet route-nopull un pievienojiet vajadzīgos maršrutus manuāli, vai arī no servera nosūtiet šaurāku kopu. Šajā projektā tilts saglabā noklusējuma maršrutu, un DNS kļūst par nākamo lēmumu: dnsmasq pāradresācija uz mājas atrisinātāju ir jēgpilna tikai tiem nosaukumiem, kas tur tiešām dzīvo.

Izlemiet par pāradresāciju un NAT

Pilnam tunelim vajag iespējotu pāradresāciju uz Pi un pretējā pusē vārteju, kas gatava maršrutēt piekļuves punkta apakštīklu. Pārbaudiet pāradresāciju pirms visa cita, jo nulle padara jebkuru maršruta maiņu nenozīmīgu.

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 noteikums ir īsceļš, kas darbojas, kad serveris nepieņems piekļuves punkta prefiksu, par cenu, ka katrs klients tālās puses žurnālos parādīsies kā Pi tuneļa adrese. Prefiksa maršrutēšana bez NAT saglabā adreses redzamas un ir atkarīga no atgriešanās maršruta 192.168.50.0/24 mājas pusē.

Pierakstiet izvēli pie ugunsmūra noteikumiem, jo projektā neredzams NAT noteikums pēc sešiem mēnešiem kļūst neizskaidrojams. Turiet IPv6 tajā pašā lēmumā; strādājošs IPv4 ceļš blakus salauztam IPv6 ceļam pārlūkā joprojām lasās kā pa pusei salauzts.

Pārbaudiet no klienta, pēc tam tīri atritiniet

Pārbaudiet šādā secībā no tālruņa vai portatīvā datora piekļuves punktā: noma no dnsmasq, ping uz tilta adresi, tad galamērķis tuneļa otrā pusē. Katrs solis izolē vienu slāni, nevis rada vienu bezjēdzīgu kļūmi.

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

Pēc tam apstipriniet, ka Pi joprojām ir savs izejas ceļš: ip route get 203.0.113.10 jānosauc apakšējā slāņa ierīce, un ping -c 3 -I br0 203.0.113.10 jāatbild, ja serveris atļauj ICMP. Ja pirmie divi klienta soļi izdodas un trešais neizdodas, kļūda ir pāradresācijā vai NAT. Ja otrais solis neizdodas, tilts vai DHCP joprojām nav pilnīgi.

Atritināšana ir viens faila labojums un divas komandas: noņemiet bloku, restartējiet dhcpcd un aizstājiet noklusējuma maršrutu skaidri ar ip route replace default via 192.168.50.1 dev br0. Dariet to pirms apkopes loga aizvēršanas, nevis pēc tam, jo Pi, kas zaudējis noklusējuma maršrutu, nav sasniedzams no tīkla, ko jūs izmantotu tā labošanai.