Takistage VPN-klientidel tunnelis üksteiseni jõuda
Teenuseni jõudmine on marsruut, teise kliendini jõudmine on poliitika. Leidke edastuspunkt, mis otsustab partnerite vahelise liikluse, ja tõestage siis keeld kliendi poolt.
Kaks klienti võivad mõlemad hüppehosti avada ja ikkagi mitte omada asja üksteist avada. Teenuseni jõudmine on edastusotsus, samas kui partnerini jõudmine on poliitikaotsus, ja enamik VPN-pakette hoiab neid eraldi objektides. Miski, mida te esimese jaoks seadistate, ei jõusta teist. Ülesanne ei ole seega reeglit lisada, vaid leida objekt, mis otsustab selles serveris partnerite vahelise liikluse, kirjutada keeld sinna ja tõestada seda kliendi poolt.
Marsruut ühise teenuseni ei ole luba partnerite vahel
Kliendi alamsvõrgu kuulutamine ütleb partnerile, kuidas panna pakett juhtmele teise kliendi aadressi suunas. Kas see pakett toimetatakse kohale, otsustatakse hiljem, selle poolt, mis seda edastab. Linuxi väravas on see FORWARD-ahel; kasutajaruumi deemonis on see tunnelil oma sessioonitabel. Marsruut vastab kättesaadavusele ja jätab loa puutumata.
Seetõttu ei tõesta isolatsioonikontroll, mis loeb ainult marsruute, midagi. /24 saab saata igale kliendile, samal ajal kui iga partnerite vaheline pakett visatakse edastuskonksu juures ära. Ohtlik on vastupidine juht: ühtegi selgesõnalist reeglit ei ole, vaikimisi lubav seade ja isolatsioon, mis on olemas ainult seetõttu, et keegi seda ei testinud.
Kirjutage nõue ühele reale enne terminali avamist. Jõudke teenuseblokini ja hüppehostini, ärge jõudke millessegi muusse kliendibloki sees.
Selgitage välja, kes partneri paketti tegelikult edastab
Kaks serveri käitumist näevad kliendi poolelt ühesugused välja ja nõuavad erinevaid reegleid. Kas tuum edastab paketi uuesti tunneli liidesest välja, või deemon kopeerib selle sessioonide vahel ja tuum ei näe seda kunagi.
WireGuard kuulub esimesse rühma: sellel pole partnerite vahelist lülitit, seega pakett 10.8.0.4-lt 10.8.0.5-le saabub wg0-le, tabab edastuskonksu ja suunatakse uuesti wg0-st välja, kui AllowedIPs katab mõlemad aadressid. OpenVPN on teine rühm, kui serveri konfiguratsioonis on seatud client-to-client, sest see direktiiv annab paketi kasutajaruumis sessioonide vahel edasi. Kontrollige laaditud konfiguratsioonist seda direktiivi enne, kui midagi kirjutate. Tuumareeglit, mis ei näe kunagi liiklust, ei erista töötavast reeglist, ja nii lõpeb juurutus täiesti ilma isolatsioonita.
Lugege tegelikku konfiguratsiooni, mitte faili, mille laadimist eeldate, sest distributsioonipaketid toovad oma kaasamised. Kui deemon edastab, kuulub keeld selle enda kliendipõhistesse juhtseadmetesse, ja hosti tulemüür filtreerib ainult hostile adresseeritud liiklust. Kui tuum edastab, on edastuskonks ainus koht, mis loeb.
Marsruuditud ja tõlgitud juurutused vajavad veel üht kontrolli: allikas, mida kaugel asuv klient näeb, ei pruugi olla see, mida ootate. Siis ei sobi kliendi alamsvõrgule vastav reegel mitte millegagi. Märkige üles aadress, mis tõlkimisest alles jääb, enne vastavuse kirjutamist, ja eelistage liidesepaari sobitamist NAT-aadresside oletamisele.
Andke igale aadressile identiteet, mida saab eraldi tühistada
Isolatsioon variseb kokku niipea, kui kaks seadet jagavad üht volitust. Selle identiteediga seotud reegel ei saa neid eraldada, ja kadunud sülearvuti tühistamine tühistab kogu rühma. Seadmepõhised sertifikaadid või partneripõhised võtmed hoiavad tühistamise kohaliku ja poliitika loetavana, sest iga aadress vastab täpselt ühele inimesele või masinale. Kui disain seda teha ei saa, öelge seda tööjuhendis, mitte ärge kirjeldage reeglit peeneteralisena.
Aadresside jaotamine peab poliitikaga kooskõlas olema. Broneerige blokk teenustele, blokk klientidele, ja jagage kliendi aadresse kogumist, mida kontrollite, mitte vahemikust, kus kes ees, see mees. Kui server tõlgib või sildab, hoidke vastavustabel konfiguratsiooni kõrval, sest just seda tabelit vajab järgmine lugeja reegli uuesti tuletamiseks.
Asetage keeld sinna, kus pakett tunnelit läbib
Väravas, mis edastab WireGuard-liiklust, katavad juhtu kaks reeglit: lubage teenuseblokk, seejärel visake kliendibloki ülejäänu ära. Liidesepaar loeb sama palju kui aadressid, sest ainult sihtkoha järgi sobitamine püüab ka LAN-ist tuleva liikluse. Laadige need selles järjekorras, et luba hinnataks esimesena.
nftablesiga läheb paar olemasolevasse inet filter tabelisse, esmalt luba ja seejärel äraviskamine. Mõlemad vastavused kinnitavad liidesepaari ja ka aadressid.
nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.2.0/24 accept
nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.0.0/24 drop
Lugege ahel pärast laadimist tagasi, selle asemel et usaldada väljumisolekut, ja kinnitage, et mõlemad reeglid seisavad kavatsetud järjekorras. Lisage vastavad ip6-reeglid IPv6-kogumile, muidu on v4-paar kahekihilises tunnelis vaid kaunistus. Kui serveril on juba lubav edastuspoliitika, lisage äraviskamine, mitte ärge asendage ahelat tervikuna.
Kui OpenVPN-is on client-to-client lubatud, ei sobi need edastusreeglid kunagi partnerite vahelise liiklusega ja keeld peab elama deemoni enda juhtseadmetes. Hoidke tuumareeglid hostile adresseeritud liikluse jaoks, kuid ärge arvestage neid isolatsioonijuhtimisena.
Tõestage keeld kliendi, mitte serveri poolt
Väravast testimine ei tõesta midagi, sest kohapeal loodud liiklus võtab väljundtee ega läbi kunagi edastuskonksu. Kasutage kahte päris klienti: üks, mis peaks teenuseni jõudma, üks, mis peaks tagasi lükatama. Käivitage esmalt lubamise juht, et katkine tunnel ei läheks segamini töötava poliitikaga.
Lubatud kliendist kinnitage, et teenus vastab oma pordil. Samast kliendist proovige partneri aadressi ja oodake vaikset äraviskamist, mitte keeldumist:
ping -c 3 -W 2 10.8.0.5
nc -z -w 2 10.8.0.5 22
nft list chain inet filter forward
iptables -vnL FORWARD
ping -6 -c 3 -W 2 fd00:8::5
Äravisatud pakett ja võrguühenduseta partner näevad mõlemad välja nagu aegumine, seega kontrollige lugejaid enne, kui midagi järeldate. Kinnitage, et äraviskamise reegli lugeja kasvab, samal ajal kui partner on tõestatavalt üleval. Korrake IPv6 kaudu, kus puuduv ip6-reegel jätab v4-keelu tõhusana näima. Kirjutage aktsepteeritud ja tagasilükatud tulemused tööjuhendisse kuupäevaga, sest järgmine migratsioon tuletab reegli uuesti.