Gostujući Wi-Fi i dalje koristi glavnu rutu: dajte mu vlastiti izlaz

Napravili ste gostujuću mrežu, dodali rutu za nju, a gosti i dalje izlaze kroz vašu uobičajenu internet vezu. Tunel je podignut, glavni LAN radi, a gostujući uređaji prijavljuju adresu u rasponu koji ste dodijelili, pa ništa ne izgleda pokvareno. Obično ne nedostaje ruta nego selektor: ruter odlučuje o putu prije nego što uzme u obzir kroz koje je sučelje paket stigao, i ako nešto izričito ne odgovara gostujućem prometu, taj promet nasljeđuje zadano. Rješenje je segment, pravilo politike i povratni put, tim redom.

Simptom: gosti i dalje izlaze kroz WAN

Znak je izlazna adresa. Gostujući uređaj koji do interneta dolazi kroz tunel prijavit će adresu pružatelja tunela, a onaj koji je naslijedio zadano prijavit će vašu uobičajenu vezu. Uporedite gostujući uređaj i uređaj glavnog LAN-a jedan uz drugi, jer je zanimljiv slučaj kada se razlikuju od onoga što ste postavili i međusobno se poklapaju.

Drugi znak je odsustvo bilo kakvog prometa na sučelju tunela dok gosti pregledaju. Ako se brojači ne pomjeraju, politika nikada nije primijenjena, a podešavanje samog tunela ne može pomoći.

Korak 1: pravi segment, ne samo ime

Ime SSID-a ne stvara izolaciju. Provjerite da gostujuća mreža završava na vlastitom sučelju, VLAN-u ili mostu i da se raspon adresa razlikuje od pouzdanog LAN-a. Na mnogim potrošačkim pristupnim točkama gostujući SSID se premosćuje u isti segment kao i sve ostalo, što ostatak ovog posla čini nemogućim dok se to ne ispravi.

Zatim potvrdite gostujući raspon i njegov DHCP server, a postavke razrješivača držite vezane za taj segment, a ne za cijeli ruter. Gostujuća podmreža koja postoji samo kao komentar u pravilu vatrozida nije segment i ruter neće imati sučelje s kojim bi je upario.

Ne premosćujte goste u glavni LAN da bi VPN bio lakši za postavljanje. To mijenja izolaciju koju ste željeli za prečicu u rutiranju, i to je uobičajen razlog zašto gostujuća mreža završi s pristupom printeru i NAS-u.

Korak 2: odaberite tunel po izvoru

Tablice rutiranja biraju se po odredištu, pa pravilo koje kaže da se 0.0.0.0/0 šalje u tunel vrijedi za sve. Usmjeravanje po politici dodaje drugu dimenziju: odaberite tablicu po adresi izvora. Na ruteru zasnovanom na Linuxu to je dodatno pravilo plus namjenska tablica, a redoslijed je važan jer prvo pravilo koje se podudara pobjeđuje:

ip rule add from 192.168.60.0/24 lookup 100 priority 1000
ip route add default dev wg0 table 100
ip route get 1.1.1.1 from 192.168.60.10

Ta posljednja naredba izravno odgovara na pitanje: koje će sučelje ovaj izvor koristiti za ovo odredište. Pokrenite je prije i poslije promjene i znat ćete je li politika stupila na snagu bez dodirivanja preglednika.

Većina firmwarea rutera izražava istu stvar kao pravilo sučelja ili odabir pristupnika po izvoru. Koju god sintaksu vaša platforma koristi, princip je isti: podudarite ulazno sučelje ili prefiks izvora, pa zatim nadjačajte rutu samo za to podudaranje. Pravilo podudareno po odredištu ne može razlikovati gosta od kućnog uređaja.

Korak 3: povratni put i prevođenje

Paket koji izađe kroz tunel mora se vratiti. Ili tunelski partner zna rutu natrag do gostujućeg prefiksa, ili ruter prevodi gostujući izvor u adresu tunela. Odaberite jedno i zapišite, jer načini kvara izgledaju različito: nedostajuća povratna ruta daje vezu koja se uspostavi i nikada ne odgovori, dok nedostajuće prevođenje često ne proizvede ništa.

nft add rule ip nat POSTROUTING ip saddr 192.168.60.0/24 oifname "wg0" masquerade

Ako odaberete prevođenje, zapamtite da partner sada vidi jednu adresu za svakog gosta, pa svaka politika po klijentu na daljem kraju nestaje. Ako umjesto toga sačuvate adrese, oba kraja trebaju gostujući prefiks u svom rutiranju i politici, što je više posla i predvidljivije.

IPv6 treba vlastito pravilo. Politika napisana za IPv4 ne pokriva drugu obitelj, a gostujući uređaj s ispravnim IPv6 rado će ga koristiti dok vaša pažljivo usmjerena IPv4 putanja stoji besposlena. Ili usmjerite obje obitelji ili onemogućite IPv6 na gostujućem segmentu, ali ne pretpostavljajte da kombinirano pravilo koje ste napisali pokriva ono što uređaj stvarno radi. Testirajte s klijentom koji ima omogućene obje obitelji, jer to je slučaj koji dizajn mora izdržati. Prijenosnik koji preferira IPv6 izgleda ispravno u testu samo s IPv4, a curi u stvarnom.

Testirajte izolaciju, ne samo pregledanje

Pregledanje dokazuje da se izlaz promijenio. Ne dokazuje da je segment izoliran, a izolacija je razlog postojanja gostujuće mreže. S gostujućeg uređaja pokušajte dosegnuti administrativno sučelje rutera, pouzdanog hosta u LAN-u i uslugu koja bi trebala biti odbijena; sva tri trebaju pasti, a pad treba biti odluka politike, a ne istek vremena koji nitko ne može objasniti.

Zatim testirajte uređaj glavnog LAN-a i potvrdite da mu se izlaz nije promijenio. To je regresija koju ovaj dizajn najčešće uzrokuje: široko pravilo namijenjeno gostima primijenjeno na svako sučelje jer je podudaranje napisano po odredištu.

Na kraju, odlučite što se događa kad je tunel pao. Gosti ili ne dobiju internet ili se vrate na put koji odobravate, a ostaviti to neodlučenim znači tihi povratak na uobičajenu vezu, što je upravo curenje koje je gostujuća politika trebala spriječiti. recept za usmjeravanje internetskog prometa opisuje isti odabir puta za ruter zasnovan na pfSenseu.

DNS koji potječe s rutera je slučaj koji ljude iznenadi posljednji. Ako gosti koriste ruter kao svoj razrješivač, upiti samog rutera slijede rutinu rutera, a ne gostujuće pravilo, pa pretrage mogu izaći kroz uobičajenu vezu dok promet aplikacija ne izlazi. Držite segment, razrješivač i politiku kvara u jednoj bilješci i sljedeća osoba može provjeriti sve tri bez ponovnog izvođenja dizajna.