Host publiko bakarra VPN eta webarentzat: nola banatu rolak

Makina batek hiru beharrak aldi berean bete ditzake: tunelak amaitu, HTTPSari erantzun eta bi LAN pribaturen artean birbidali. Zentzuzkoa den hiru gauzatan jokatzen da, paperean erabaki ditzakezunak: nor den helbide publikoaren jabea, nor den portu eta protokolo bikote bakoitzaren jabea, eta zein prozesuri dagoen baimenduta paketeak birbidaltzea. Hori ondo eginez gero, host partekatua ez da deigarria. Gaizki eginez gero, asteburu osoa emango duzu garbi abiarazten den eta inoiz erantzuten ez duen zerbitzu batekin.

Hurrengoa erabaki-prozedura da, ez eraikuntza-orri bat. Urrats bakoitza amaieran daukan egiaztapenarekin amaitzen da, gehitu berri duzun rola benetan isolatuta dagoela frogatzen duena.

Aukeratu helbidearen jabea portuak baino lehen

Tunel baten amaiera-puntuak eta web zerbitzari batek kernel bera partekatu dezakete; helbide, portu eta protokolo bat aldi berean partekatzea da huts egiten duena. WireGuardek normalean UDP 51820 erabiltzen du, OpenVPNek UDP 1194 edo TCP 443 erabiltzen du, eta web zerbitzari batek TCP 443. Mina egiten duen bikotea OpenVPN TCP 443 gainean HTTPSaren ondoan dago, bi-biek socket bera nahi dutelako eta kernelak lehenengo lotu zuenari ematen diolako. Aurrean dagoen demultiplexadore batek bakarrik, sslh edo TLS ezagutzen duen proxy bat bezalakoak, uzten die portu hori partekatzen, eta huts egiten duen osagai bat gehitzen du, zeinaren hutsegitea suebaki-problema baten itxura zehatza baitu.

Begiratu jabeei ezer aldatu aurretik: ss -lntup komandoak entzuten ari den socket bakoitzaren helbide lokala, portua eta prozesua inprimatzen ditu. Bi errenkadak 0.0.0.0:443 erakusten badituzte, bigarren zerbitzuak inoiz lotu ez zuela adierazten dute, bere init scripta poz-pozik zegoen arren. Zubiak jabea ere aldatzen du. Adibidez, eth0 sartzen da honako taldean: br0. Horren ondorioz, IPa br0 helbidera pasatzen da eta suebaki-arau oro, non eth0 aipatzen den, bat ez etortzen hasten da, beraz lotu zerbitzuak zubian eta egiaztatu ip -br addr erabiliz.

Jabetza-arau berak azaltzen du makina birtualekin agertzen den ezustekoa. LAN berean dagoen gonbidatu baten barruan exekutatzen den tunel zerbitzari batek gonbidatuaren helbidea mantentzen du, beraz hostaren beraren helbidera zuzendutako konexioak hostean geratzen dira eta gonbidatuaren tunelak ez ditu inoiz ikusten, bezeroaren profilak dioena edozein dela ere.

Bideratu bi LANen artean edo egin NAT alde bat

Elkar ikusten ez duten bi LANek host publikoari dei diezaiokete, eta hark tunelen artean birbidaltzen du. Bideratze-diseinu horrek hiru gauza behar ditu: birbidaltzea piztuta, urruneko prefiksean seinalatzen duen bide bat eta transitua uzten duen birbidaltze-politika bat. sysctl -w net.ipv4.ip_forward=1 lehenengoa estaltzen du, ip route add 10.20.0.0/24 dev wg1 bigarrena, eta nftables lerro bat honek bezala nft add rule inet filter forward iifname "wg0" oifname "wg1" accept hirugarrena.

Iturburuko NAT errazagoa da gehitzen eta zailagoa arazten. Masqueradeak bezeroaren helbidea berridazten du, beraz urrutiko aldeak hub-a ikusten du benetako hostaren ordez, eta bere sarbide-arauak eta erregistroak ez dira erabilgarri geratzen egiletza zehazteko. Bi sareak zureak badira, bideratu. Alde bat hirugarren baten jabetzakoa bada eta itzulera-bidea gehituko ez badu, NAT da aste honetan bidaltzen den aukera. Edozein modutan, idatzi helbide-plana, /24 bi gainjartzen direnak ezin baititu edozein konfiguraziok bideratu.

Ez dago ezer, ordenagailu eramangarri baten internet-irteera izateak kaxa berak sarrerako tunelak amaitzea eragozten duenik. Helbide gainjarriek soilik eragozten dute, eta horregatik da helbide-plana axola duen dokumentua.

Probatu banaketa bi rol geldituta daudenean

Erabilgarria den proba kenketa da: gelditu bi rol eta egiaztatu hirugarrenak oraindik erantzuten duela. Web eskaera batek osatu beharko luke tunel zerbitzua behera dagoenean, eta tunelaren eskukada batek osatu beharko luke web zerbitzaria geldituta dagoenean. Biak dena martxan dagoenean soilik funtzionatzen badute, ustekabeko mendekotasuna duzu, adibidez suebaki-taula partekatua, bide galdua edo helbide okerra seinalatzen duen izena.

Hiru komandok proba hori zehatza egiten dute. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ komandoak frogatzen du tokiko entzuleak kanpoko DNSrik gabe erantzuten duela, wg show bezeroan frogatzen du eskukada osatu zela, eta tcpdump -ni any port 51820 hub-ean bideratze-problema giltza-problemagandik bereizten du. Kapturan inoiz agertzen ez den eskukada hosta baino lehen hil da: hornitzailearen suebakia, helbide publiko okerra edo bidean dagoen NAT araua.

Errepikatu kenketa birbidaltzen diren LANetan. Peer bat deskonektatuta dagoenean, hub-aren zeharkako ping-ak huts egin behar du; berriro konektatuta, ping-ak berreskuratu behar du arazorik ukitu gabe. Tunela berrabiarazi ondoren soilik berreskuratzen den ping-ak politikari seinalatzen dio, ez irisgarritasunari, eta hori beste konponketa bat da.

Mantendu arau-multzoa irakurgarri rolak kentzen dituzun bitartean. nft list ruleset erakusten du benetan behar duzun norabide bakoitzeko onartze-arau bat, eta dena onartzen duen birbidaltze-katea ez da bereiztea, demo bat da.

IPv6 soilik duten sarbide-lerroak eta IPv4 zerbitzuak

Zenbait sarbide-lerrok IPv6 irisgarritasuna soilik ematen dute, eta zerbitzuak IPv4 bidez argitaratu behar dira oraindik. Tunela bera oraindik trafikoa pasatzen duen familiaren bidez doa, argitaratutako zerbitzua tunelaren barruko helbide batean dagoen bitartean. Horrek ohiko ustea alderantzikatzen du eta isilka apurtzen du monitorizazioa: IPv4 bidearako idatzitako suebaki-arauak edo martxa-denboraren egiaztapenak ezer eramaten ez duen interfaze bat zaintzen du orain.

Probatu familia bakoitza bere kabuz honekin: curl -4 eta curl -6, probatu ez duzun bideari buruz ezer esaten ez baitu eskaera arrakastatsu batek. Portuen jabetza ez da aldatzen familien artean, baina entzulea bai: ss -lntup komandoak IPv4 eta IPv6 socketak errenkada bereizietan zerrendatzen ditu, eta 0.0.0.0:443 ez du estaltzen [::]:443, prozesuak dual-stack socket bat eskatu ez badu behintzat.

Familia batean erantzuten duen eta bestean ukatzen duen zerbitzua entzule-problema izan ohi da, ez bideratze-problema. Diseinua amaitutzat eman aurretik, egiaztatu rol bakoitzak bere helbide edo portua duela, birbidaltzea gaituta eta baimenduta dagoela, eta rol bakoitzak oraindik erantzuten duela beste biak geldituta daudela.