Én offentlig vært til VPN og web: sådan deles rollerne

Én maskine kan klare alle tre behov på én gang: afslutte tunneler, svare på HTTPS og videresende mellem to private LAN. Om det er fornuftigt afhænger af tre ting, du kan afgøre på papiret: hvem der ejer den offentlige adresse, hvem der ejer hvert port- og protokolpar, og hvilken proces der må videresende pakker. Får du det rigtigt, er den delte vært ikke noget særligt. Får du det forkert, bruger du en weekend på en tjeneste, der starter rent og aldrig svarer.

Det følgende er en beslutningsprocedure, ikke en byggevejledning. Hvert trin slutter med den kontrol, der beviser, at den rolle, du netop har tilføjet, faktisk er isoleret.

Vælg ejeren af adressen før portene

Et tunnelendepunkt og en webserver kan dele en kerne; at dele én adresse, port og protokol på samme tid er det, der fejler. WireGuard tager normalt UDP 51820, OpenVPN tager UDP 1194 eller TCP 443, og en webserver tager TCP 443. Det par, der gør ondt, er OpenVPN over TCP 443 ved siden af HTTPS, fordi begge vil have den samme socket, og kernen giver den til den, der bandt først. Kun en demultiplekser foran, som sslh eller en TLS-bevidst proxy, lader dem dele den port, og den tilføjer en komponent, hvis fejl ser præcis ud som et firewallproblem.

Se på ejerne, før du ændrer noget: ss -lntup udskriver den lokale adresse, porten og processen for hver lyttende socket. To rækker med 0.0.0.0:443 betyder, at den anden tjeneste aldrig bandt, hvor muntert dets init-script end var. Broen flytter også ejeren. Når eth0 slutter sig til br0, flytter IP'en til br0 og hver firewallregel, der nævner eth0 holder op med at matche, så bind tjenester på broen og bekræft med ip -br addr.

Den samme ejerskabsregel forklarer en overraskelse, der dukker op med virtuelle maskiner. En tunnelserver, der kører inde i en gæst på samme LAN, beholder gæstens adresse, så forbindelser rettet mod værtens egen adresse bliver på værten, og gæstens tunnel ser dem aldrig, uanset hvad klientprofilen antyder.

Rut mellem de to LAN, eller lav NAT på den ene side

To LAN, der ikke kan se hinanden, kan hver især ringe til den offentlige vært, som derefter videresender mellem tunnelerne. Det rutede design kræver tre ting på plads: videresendelse slået til, en rute mod hvert fjernprefix og en videresendelsespolitik, der lukker transit igennem. sysctl -w net.ipv4.ip_forward=1 dækker det første, ip route add 10.20.0.0/24 dev wg1 det andet, og en nftables-linje som nft add rule inet filter forward iifname "wg0" oifname "wg1" accept det tredje.

Kilde-NAT er lettere at sætte på og sværere at fejlfinde. Maskering omskriver klientens adresse, så den fjerne side ser hubben i stedet for den rigtige vært, og dens adgangsregler og logfiler holder op med at være nyttige til at tilskrive. Når begge netværk er dine, så rut. Når den ene side tilhører en tredjepart, der ikke vil tilføje en returrute, er NAT den mulighed, der kan leveres i denne uge. Under alle omstændigheder skal du skrive adresseplanen ned, for to overlappende /24 kan ikke routes med nogen mængde konfiguration.

Intet ved at fungere som internetudgang for en bærbar forhindrer den samme boks i at afslutte indgående tunneler. Kun overlappende adresser gør det, og det er derfor, adresseplanen er det dokument, der betyder noget.

Test opdelingen, mens to roller er stoppet

Den nyttige test er subtraktion: stop to roller, og bekræft at den tredje stadig svarer. En webforespørgsel bør gennemføres med tunneljenesten nede, og et tunnelhandtryk bør gennemføres med webserveren stoppet. Hvis begge kun virker, når alt kører, har du en tilfældig afhængighed: en delt firewalls tabel, en vildfaren rute eller et navn, der peger på den forkerte adresse.

Tre kommandoer gør den test konkret. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ beviser, at den lokale lytter svarer uden ekstern DNS, wg show på klienten beviser, at handtrykket blev gennemført, og tcpdump -ni any port 51820 på hubben skiller et ruteproblem fra et nøgleproblem. Et handtryk, der aldrig dukker op i optagelsen, døde før værten: udbyderens firewall, forkert offentlig adresse eller en NAT-regel på vejen.

Gentag subtraktionen for de videresendte LAN. Med en peer afbrudt bør en ping gennem hubben fejle; når den er tilsluttet igen, bør pinget komme tilbage uden at røre en regel. Et ping, der først kommer tilbage efter genstart af tunnelen, peger på politik i stedet for rækkevidde, og det er en anden rettelse.

Hold regelsættet læsbart, mens du subtraherer roller. nft list ruleset bør vise én acceptregel pr. retning, du faktisk har brug for, og en forward-kæde, der accepterer alt, er ikke adskillelse, det er en fungerende demo.

Adgangslinjer med kun IPv6 og IPv4-tjenester

Nogle adgangslinjer giver kun IPv6-rækkevidde, og tjenester skal stadig udgives over IPv4. Selve tunnelen rejser over den familie, der stadig fører trafik, mens den udgivne tjeneste ligger på en adresse inde i tunnelen. Det vender den sædvanlige antagelse på hovedet og ødelægger overvågning i det stille: en firewallregel eller uptime-kontrol skrevet til IPv4-stien overvåger nu et interface, der ikke bærer noget.

Test hver familie for sig med curl -4 og curl -6, fordi en vellykket forespørgsel intet siger om den sti, du ikke prøvede. Portejerskab ændrer sig ikke mellem familier, men lytteren gør: ss -lntup viser IPv4- og IPv6-sockets som separate rækker, og 0.0.0.0:443 dækker ikke [::]:443, medmindre processen bad om en dual-stack-socket.

En tjeneste, der svarer på én familie og afviser på den anden, er som regel et lytterproblem, ikke et ruteproblem. Før du kalder designet færdigt, skal du bekræfte, at hver rolle ejer sin egen adresse eller port, at videresendelse er slået til og tilladt, og at hver rolle stadig svarer, når de to andre er stoppet.