Viesu Wi-Fi joprojām izmanto galveno maršrutu: piešķiriet tam savu izeju

Jūs izveidojāt viesu tīklu, pievienojāt tam maršrutu, un viesi joprojām iziet caur jūsu parasto interneta savienojumu. Tunelis darbojas, galvenais LAN darbojas, un viesu ierīces ziņo adresi jūsu piešķirtajā diapazonā, tāpēc nekas neizskatās salauzts. Parasti trūkst nevis maršruts, bet selektors: maršrutētājs izlemj ceļu pirms tam, kad ņem vērā, pa kuru saskarni pakete ieradās, un ja kaut kas nepārprotami neatbilst viesu trafikam, šis trafiks manto noklusējumu. Risinājums ir segments, politikas noteikums un atbildes ceļš, tieši šajā secībā.

Simptoms: viesi joprojām iziet caur WAN

Pazīme ir izejas adrese. Viesu ierīce, kas sasniedz internetu caur tuneli, ziņos tunļa pakalpojumu sniedzēja adresi, bet tā, kas mantoja noklusējumu, ziņos jūsu parasto savienojumu. Salīdziniet blakus viesu ierīci un galvenā LAN ierīci, jo interesantais gadījums ir tad, kad tās atšķiras no tā, ko konfigurējāt, un sakrīt savā starpā.

Otrā pazīme ir jebkāda trafika trūkums tunļa saskarnē, kamēr viesi pārlūko. Ja skaitītāji nekustas, politika nekad nav piemērota, un paša tuneļa pielāgošana nevar palīdzēt.

1. solis: īsts segments, nevis tikai nosaukums

SSID nosaukums nerada izolāciju. Pārbaudiet, vai viesu tīkls beidzas savā saskarnē, VLAN vai tiltā, un vai adrešu diapazons atšķiras no uzticamā LAN. Daudzos patērētāju piekļuves punktos viesu SSID tiek tiltots tajā pašā segmentā kā viss pārējais, kas padara pārējo darbu neiespējamu, līdz tas tiek izlabots.

Pēc tam apstipriniet viesu diapazonu un tā DHCP serveri, un turiet risinātāja iestatījumus saistītus ar šo segmentu, nevis ar visu maršrutētāju. Viesu apakštīkls, kas pastāv tikai kā komentārs ugunsmūra noteikumā, nav segments, un maršrutētājam nebūs nevienas saskarnes, ar ko saskaņot.

Nesavienojiet viesus ar galveno LAN, lai VPN būtu vieglāk konfigurēt. Tas apmaina vēlamo izolāciju pret maršrutēšanas saīsni, un tas ir ierastais iemesls, kāpēc viesu tīkls galu galā iegūst piekļuvi printerim un NAS.

2. solis: izvēlieties tuneli pēc avota

Maršrutēšanas tabulas izvēlas pēc galamērķa, tāpēc noteikums «sūti 0.0.0.0/0 uz tuneli» attiecas uz visiem. Uz politiku balstīta maršrutēšana pievieno otru dimensiju: izvēlieties tabulu pēc avota adreses. Linux bāzētā maršrutētājā tas ir papildu noteikums un atsevišķa tabula, un secība ir svarīga, jo uzvar pirmais atbilstošais noteikums:

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

Pēdējā komanda tieši atbild uz jautājumu: kuru saskarni šis avots izmantos šim galamērķim. Palaidiet to pirms un pēc izmaiņām, un jūs zināsiet, vai politika ir stājusies spēkā, nepieskaroties pārlūkam.

Lielākā daļa maršrutētāju programmaparatūras izsaka to pašu kā saskarnes noteikumu vai uz avotu balstītu vārtejas izvēli. Lai kādu sintaksi izmantotu jūsu platforma, princips ir identisks: saskaņojiet ar ieejas saskarni vai avota prefiksu, pēc tam pārrakstiet maršrutu tikai šai atbilstībai. Noteikums, kas saskaņojas pēc galamērķa, nevar atšķirt viesi no mājas ierīces.

3. solis: atbildes ceļš un tulkošana

Paketei, kas iziet caur tuneli, ir jāatgriežas. Vai nu tuneļa partneris zina atgriešanās ceļu uz viesu prefiksu, vai maršrutētājs pārtulko viesu avotu tuneļa adresē. Izvēlieties vienu un pierakstiet to, jo kļūmju režīmi izskatās atšķirīgi: trūkstošs atgriešanās ceļš dod savienojumu, kas izveidojas un nekad neatbild, bet trūkstoša tulkošana bieži vien nedod neko.

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

Ja izvēlaties tulkošanu, atcerieties, ka partneris tagad redz vienu adresi visiem viesiem, tāpēc jebkura politika katram klientam tālajā galā pazūd. Ja saglabājat adreses, abiem galiem ir vajadzīgs viesu prefikss to maršrutēšanā un politikā, kas ir vairāk darba un paredzamāk.

IPv6 ir vajadzīgs savs noteikums. IPv4 rakstīta politika neaptver otru saimi, un viesu ierīce ar strādājošu IPv6 labprāt to izmantos, kamēr jūsu rūpīgi maršrutētais IPv4 ceļš stāv dīkā. Maršrutējiet abas saimes vai atspējojiet IPv6 viesu segmentā, bet nepieņemiet, ka uzrakstītais apvienotais noteikums aptver to, ko ierīce patiešām dara. Pārbaudiet ar klientu, kurā iespējotas abas saimes, jo tas ir gadījums, kam dizainam jāiztur. Klēpjdators, kas dod priekšroku IPv6, izskatās pareizi tikai IPv4 testā un noplūst īstajā.

Pārbaudiet izolāciju, ne tikai pārlūkošanu

Pārlūkošana pierāda, ka izeja ir mainījusies. Tā nepierāda, ka segments ir izolēts, un izolācija ir iemesls, kāpēc viesu tīkls pastāv. No viesu ierīces mēģiniet sasniegt maršrutētāja administrēšanas saskarni, uzticamā LAN resursdatoru un pakalpojumu, kuram vajadzētu tikt atteiktam; visiem trim vajadzētu neizdoties, un neveiksmei jābūt politikas lēmumam, nevis taimautam, ko neviens nevar izskaidrot.

Pēc tam pārbaudiet galvenā LAN ierīci un apstipriniet, ka tās izeja nav mainījusies. Tā ir regresija, ko šis dizains visbiežāk izraisa: plašs noteikums, kas paredzēts viesiem, tiek piemērots katrai saskarnei, jo atbilstība tika rakstīta pēc galamērķa.

Visbeidzot, izlemiet, kas notiek, kad tunelis ir izslēgts. Viesi vai nu nesaņem internetu, vai atgriežas jūsu apstiprinātajā ceļā, un šī lēmuma nepieņemšana nozīmē klusu atgriešanos pie parastā savienojuma, kas ir tieši tas noplūde, ko viesu politika bija paredzēta novērst. Interneta trafika maršrutēšanas recepte iziet to pašu ceļa izvēli pfSense bāzētam maršrutētājam.

No maršrutētāja nākošais DNS ir gadījums, kas cilvēkus pārsteidz pēdējais. Ja viesi izmanto maršrutētāju kā savu risinātāju, paša maršrutētāja vaicājumi seko maršrutētāja maršrutam, nevis viesu noteikumam, tāpēc meklēšana var iziet caur parasto savienojumu, kamēr lietojumprogrammas trafiks neiziet. Turiet segmentu, risinātāju un kļūmju politiku vienā piezīmē, un nākamā persona varēs pārbaudīt visus trīs, no jauna neatvasinot dizainu.