Wi-Fi piekļuves punkts aiz VPN vārtejas: saglabājiet vienu LAN
Tiltots piekļuves punkts vai otrs maršrutētais segments? Atšķirība ir tajā, kam pieder adresācija, DNS un tunelis, un tas nosaka, kur dzīvo politika.
Bezvadu klienti var atrasties aiz VPN, kamēr piekļuves punkts par tuneli nezina neko. Savienojiet radio ar vārtejas LAN tiltā, ļaujiet vārtejai piederēt adresāciju un tuneli, un katra Wi-Fi ierīce manto to pašu politiku. Alternatīva, otrs maršrutētais segments ar savu vārteju, ir cits projekts ar citu kļūmes režīmu.
Abus jauc, jo abi liek kasti starp internetu un jūsu ierīcēm. Salīdzināt, kam katrs pieder, ir ātrākais veids, kā izvēlēties.
Divi veidi, kā novietot VPN Wi-Fi priekšā
Tiltotā izkārtojumā piekļuves punkts pārraida kadrus starp radio un vadu segmentu un neko citu: viens apakštīkls, viena adrešu iestāde, viens maršrutētājs, kas izpilda politiku. Maršrutētā izkārtojumā otrai kastei ir savas adreses, savs DHCP diapazons un savs noklusējuma maršruts, tāpēc trafiks šķērso vēl vienu robežu, pirms sasniedz tuneli. Tiltotais projekts katru bezvadu ierīci padara lokālu vārtejai, tāpēc viens noteikumu kopums aptver visas. Maršrutētais projekts dod segmentu, par ko domāt, un otru vietu, kur politika var noiet greizi.
internet
-> vpn-capable gateway: routing, tunnel, dns, failure policy
-> bridged access point: radio onto the same lan
-> wifi clients
Izvēlieties tilto, ja prasība ir, lai bezvadu ierīces izmantotu to pašu tuneli kā vadu ierīces. Izvēlieties maršrutēto, ja vēlaties segmentu, ko var izolēt, vai ja otrā kaste jau pastāv kā maršrutētājs.
Ko tiltotais izkārtojums patiešām maina
Tiltošana noņem tulkošanas slāni un konkurējošu noklusējuma vārteju, un pievieno pārvaldības problēmu. Piekļuves punktam joprojām vajag adresi, ko varat sasniegt, ko piegādātāja darbplūsma parasti sakārto caur galveno LAN. Tā DHCP pakalpojumam jābūt izslēgtam, citādi divas iestādes izsniegs pretrunīgus nomas līgumus. Vārteja patur tuneli, risinātāja iestatījumus un lēmumu par to, kas notiek, kad tunelis krīt, tāpēc politika dzīvo tieši vienā vietā.
Radio neko no tā automātiski nemanto no tuneļa. Tas vienkārši pārstāj pievienot slāņus, kas to aizsegtu.
Kur iederas otrs maršrutētais segments
Maršrutētais segments pelna savu sarežģītību, kad ierīcēm aiz tā vajadzīga citāda apiešanās nekā pārējam LAN. Viesu tīkls, laboratorija vai klientu kopa, kurai vienmēr jāiziet caur noteiktu valsti, ir visi iemesli likt maršrutētāju ceļā. Cena ir otra adrešu iestāde, otra ugunsmūris, kas jāuztur saskanīgs, un atgriešanās maršruts no galvenā LAN, ja kādam tur jāsasniedz segments. Tie ir pienākumi, nevis konfigurācijas detaļas.
Bieža kļūda ir nejauši uzbūvēt maršrutēto versiju, atkal izmantojot maršrutētāju, kas joprojām darbojas ar savu DHCP un tulkošanu. Tas dod dubultu tulkošanu un politiku, ko neviens nevar izsekot.
Pārbaudiet no Wi-Fi klienta, nevis no vārtejas
Veiksmīgs pieprasījums vārtejā pierāda, ka tunelis darbojas vārtejai. Īstais jautājums ir, vai bezvadu klienta pārsūtītais trafiks to izmanto, un tas jānovēro no klienta. Zemāk esošās komandas pārbauda klienta adresi, tā maršrutu un adresi, ko redz attālināts pakalpojums.
ip -4 addr show wlan0
ip route get 1.1.1.1
curl -sS https://api.ipify.org; echo
traceroute -n -m 4 1.1.1.1
Adrese vārtejas LAN iekšienē apstiprina, ka tilts laiž kadrus cauri, nevis tos tulko. Maršruts, kura pirmais lēciens ir vārteja, apstiprina, ka klients nav ieguvis otru noklusējuma maršrutu no citurienes. Izejas adreses pārbaude atbild uz īsto jautājumu, un īsā pēda parāda, vai pirmie lēcieni ir gaidītie. Ja klienta adrese nāk no cita diapazona, pirmais aizdomās turamais ir apmaldījies DHCP serveris.
Pierakstiet katras kastes lomu, tās adresi un DHCP iestādi. Diagramma ar trim līnijām ir pietiekama, un tā izšķir lielāko daļu strīdu par to, kur pieder noteikums.