VPN-yhdyskäytävä Raspberry Pissä: yksi verkkokortti vai oma asiakasportti
Yksi Pi-portti voi palvella valittuja asiakkaita, tai toinen portti voi sulkea laitteet sisään. Valitse rakenne eristyksen, varapolitiikan ja sen mukaan, kenelle DNS kuuluu.
Sinulla on yksi Pi, yksi toimiva lähtevä VPN-profiili ja kaksi laitetta, joiden pitäisi päästä internetiin sen kautta. Kysymys, joka ratkaisee koko rakennelman, ei ole se, mitä ohjetta noudatetaan, vaan se, kuinka paljon eristystä tarvitset. Yksi portti antaa Pin seisoa noiden laitteiden vieressä reitittimen LANissa ja toimia lisäyhdyskäytävänä; toinen portti antaa sijoittaa ne segmenttiin, jossa Pi on ainoa ulospääsy. Kaikki tuon valinnan jälkeen — DHCP, palomuurin laajuus, DNS, katkostapaus — seuraa siitä.
Miten kaksi rakennetta todella eroavat
Molemmat mallit reitittävät. Ero on siinä, kuka muu on kaapelilla ja mitä tapahtuu, kun käytäntösi on väärä.
| Layout A: Pi on the ISP LAN | Layout B: dedicated client port | |
|---|---|---|
| Cabling | One Ethernet port, existing switch port | Two interfaces: uplink plus a separate LAN port |
| Can a client bypass the Pi? | Yes, by using the ISP router as its gateway | No, unless the device has another radio or link |
| Who hands out addresses | The ISP router, with a per-client setting or a DHCP option | The Pi, on its own LAN interface only |
| Blast radius of a mistake | Any LAN host, if a rule is too broad | The attached segment |
| Good fit for | One laptop, a console, a temporary test client | Appliances, always-on boxes, untrusted devices |
Eristys on todellinen akseli. Rakenne A on neuvoa-antava: laite, joka jättää DHCP:n jakaman yhdyskäytävän huomiotta ja valitsee reitittimen, toimii yhä, mutta salaamattomana. Rakenne B pakotetaan topologialla, koska valittavana ei ole muuta seuraavaa hyppyä.
Rakenne A: Pi lisäyhdyskäytävänä olemassa olevassa LANissa
Oletetaan, että ISP-reititin on 192.168.50.1, Pi on 192.168.50.2 ja valitut asiakkaat osoittavat Piin. Ratkaisevaa on, että kaksi erilaista pakettivirtaa jakaa yhden kaapelin. Asiakkaan sisempi paketti saapuu Pille ja sen on poistuttava tunnelin kautta; Pin oma salattu paketti VPN-kumppanille on poistuttava samaa kaapelia reitittimelle. Ne kulkevat vastakkaisiin suuntiin samalla liitännällä ja tarvitsevat erilaista käsittelyä.
Anna Pille sen osoite asennetun verkkohallinnan kautta, ei vanhan liitäntätiedostoreseptin kautta, joka taistelee sen kanssa laitteesta. Aseta sitten asiakkaat: staattinen yhdyskäytävä yhdelle laitteelle tai DHCP-varaus, joka jakaa 192.168.50.2:n reitittimenä. Älä muuta reitittimen koko DHCP-aluetta kahden laitteen takia äläkä oleta, että asiakas noudattaa vaihtoehtoa — varmista se.
Heikkous on rakenteellinen eikä korjattavissa. Kuka tahansa asiakas tuossa segmentissä voi osoittaa 192.168.50.1:een ja poistua salaamattomana, ja laite, jossa on toinen liitäntä tai matkapuhelinradio, poistuu pakotuspolultasi kokonaan. Jos tuo lause on hyväksymätön kyseiselle laitteelle, sinulla on jo vastaus: käytä rakennetta B.
Rakenne B: oma portti sulkee laitteet sisään
Tässä Pi pitää 192.168.50.2:n ylävirran liitännässä yhdyskäytävänä 192.168.50.1 ja ottaa 10.20.0.1/24 toisella liitännällä liitetyille laitteille. Pi on nyt reititin, jossa on kaksi verkkoa, ja liitetyllä segmentillä on täsmälleen yksi uloskäynti.
Tarkista alue kaikkea muuta vasten ennen sitoutumista: tunnelin oma aliverkko, muut toimipaikkojen väliset etuliitteet ja kaikki VPN:n kautta tavoitettava. 10.20.0.0/24, joka törmää etäiseen LANiin, tuottaa sen puoliksi toimivan tuloksen, jonka diagnosointiin kuluu ilta. Jos toinen portti on USB-sovitin, varmista, että se on tuettu, ja kiinnitä sen nimi verkkohallintaan, jotta uudelleenkäynnistyksen jälkeinen uudelleenjärjestys ei siirrä LAN-osoitettasi.
Aja DHCP-kuuntelija vain tuolla liitännällä. Ylävirrassa vastaava palvelin kilpailee ISP-reitittimen kanssa ja jakaa segmenttisi osoitteet muulle taloudelle. Sido se LAN-liitäntään, rajaa se ilmoitettuun alueeseen ja pidä Pin oma osoite altaan ulkopuolella.
Edelleenlähetys, käännös ja sulkemissääntö vian sattuessa
Neljää asiaa kuvataan usein yhtenä, eivätkä ne ole yksi. Edelleenlähetyksen käyttöönotto (net.ipv4.ip_forward=1) vain kertoo ytimelle, että se saa siirtää paketteja liitäntöjen välillä; se ei itsessään salli mitään eikä takaa mitään polkua. Lähtevän valinta on reitityspäätös. Paketin salliminen on käytäntöpäätös forward-ketjussa. Sen lähteen uudelleenkirjoitus on postrouting-päätös. Rakennelma, joka tekee vain ensimmäisen, tuottaa Pin, joka lähettää asiakasliikennettä iloisesti ulos ylävirran kautta.
Raja sallinta niihin lähteisiin, joita tarkoitit, ja siihen liitäntään, jota liikenteen tulisi käyttää, ja sisällytä paluupolku ja Pin omat tarvitsemat kohteet. Käännä sitten tunnelin lähdössä, jos palveluntarjoaja ei reititä LAN-etuliitettäsi takaisin sinulle. nftables-käsikirja käsittelee edelleenlähetyksen, paikallisen lähdön ja lähdekäännöksen erillisinä toimintoina, mikä on tässä oikea ajatusmalli.
Yleinen vika on laaja masquerade-sääntö fyysisellä liitännällä. Silloin liikenne saavuttaa internetin ISP-polkua pitkin, vaikka se asiakkaan puolelta näyttää täsmälleen toimivalta VPN:ltä. Se ei todista mitään. Pidä käännös sidottuna ilmoitettuun lähtöön ja pidä sääntösi palomuurissa, jota kone jo käyttää, sen sijaan että lisäisit kilpailevan sääntöjoukon, joka tyhjentää jaetun postrouting-ketjun.
Käsittele sitten tunnelin puuttuminen. Asiakasprofiili, joka asentaa laajan oletusreitin, tarkoittaa myös, että kun tunneli putoaa, tavallinen oletus voi palata ja asiakasliikenne palaa hiljaa ylävirtaan. Siellä, missä paluu selkokieliseen tekstiin ei ole hyväksyttävää, forward-käytännön on kiellettävä asiakkaalta ylävirtaan suuntautuva liikenne nimenomaisesti, siinä tilassa, jossa VPN-reitti on poissa. Kirjoita se hylkäyssääntönä, ei oletuksena. Pin oma salattu siirto VPN-kumppanille on erillinen local-output-virta, ja sen on pysyttävä sallittuna, muuten tunneli ei voi koskaan palata.
DNS ja IPv6 tarvitsevat oman vastauksensa
Jos asiakkaat käyttävät Pii ratkaisijana, he osuvat paikalliseen kuuntelijaan ja Pi aloittaa uuden kyselyn. Se ylävirran kysely seuraa Pin omaa reittiä, ei forward-sääntöä, jonka kirjoitit asiakkaille, joten asiakaspolku vain tunnelin kautta plus suoraan lähtevä ratkaisija on vuoto ilman mitään virheilmoitusta. Päätä tietoisesti: tunnelin kautta tavoitettava ratkaisija tai paikallinen, jonka hyväksyt suoraksi, ja sovita Pin oma lähtökäytäntö tähän päätökseen.
IPv6 on taas oma tapauksensa. IPv4:n forward-sääntö ei rajoita mitään IPv6:n osalta, ja ylävirran reitittimen ilmoitukset voivat antaa Pille ja sen kautta liitetylle segmentille toisen oletuksen, joka ohittaa käytäntösi. Anna IPv6:lle joko oma suojattu polkunsa samalla periaatteella tai rajaa se nimenomaisesti asiakassegmentissä ja sano se.
Testaa raja ennen kuin luotat siihen
Hyväksy rakenne vasta neljän erillisen tarkistuksen jälkeen, koska houkutteleva yksittäinen testi — selaimen avaaminen yhdellä asiakkaalla — menee läpi useassa rikkinäisessä tilassa.
Varmista, että yksi todellinen asiakas saavuttaa internetin tunnelin kautta, ja varmista sitten, että sama asiakas ei saavuta internetiä tunnelin ollessa alhaalla. Varmista, että DNS-nimien selvitys toimii ja että kysely lähtee sinne, minne tarkoitit. Varmista, että Pin oma siirto toimii vielä tunnelin uudelleenkäynnistyksen jälkeen ja että palautuminen ei vaadi koneen uudelleenkäynnistystä. Lopuksi tarkista laite, jota et valinnut: rakenteessa A sen pitäisi jatkaa normaalisti ja rakenteessa B sitä ei pitäisi olla lainkaan tuossa segmentissä.
- Kaksi porttia ja hylkäyssääntö antavat pakotuksen; yksi portti ja DHCP-vaihtoehto antavat neuvon.
- Käännös väärällä liitännällä näyttää onnistumiselta eikä ole sitä.
- Pin oma liikenne, DNS ja IPv6 tarvitsevat kukin päätöksen, eivät päätelmää.