Ien publike host foar VPN en web: hoe't jo de rollen ferdiele

Ien masine kin alle trije ferletten tagelyk oanpakke: tunnels beëinigje, HTTPS beäntwurdzje en tusken twa private LAN's trochstjoere. Oft dat ferstannich is, komt del op trije dingen dy't jo op papier útwurkje kinne: wa't it publike adres hat, wa't elk pear fan poarte en protokol hat, en hokker proses pakketten trochstjoere mei. Krij jo dy goed, dan is de dielde host gewoan. Krij jo se ferkeard, dan bring jo in wykein troch oan in tsjinst dy't skjin start en nea antwurdet.

Wat folget is in beslútproseduere, gjin boustekening. Eltse stap einiget mei de kontrôle dy't bewissiget dat de rol dy't jo krekt tafoege hawwe echt isolearre is.

Kies de eigner fan it adres foar de poarten

In tunnel-einpunt en in webserver kinne in kernel diele; ien adres, poarte en protokol tagelyk diele is wat misgiet. WireGuard nimt meastentiids UDP 51820, OpenVPN nimt UDP 1194 of TCP 443, en in webserver nimt TCP 443. It pear dat sear docht is OpenVPN oer TCP 443 njonken HTTPS, om't beide deselde socket wolle en de kernel it jout oan wa't earst bûn. Allinnich in demultiplexer derfoar, lykas sslh of in TLS-bewuste proxy, lit har dy poarte diele, en hy foeget in komponint ta wêrfan't de flater krekt op in firewallprobleem liket.

Sjoch nei de eigners foar't jo wat feroarje: ss -lntup prints it lokale adres, de poarte en it proses fan elke harkjende socket. Twa rigen mei 0.0.0.0:443 betsjutte dat de twadde tsjinst nea bûn hat, hoe fleurich har init-skript ek wie. Bridging ferpleatst de eigner ek. As eth0 by br0 komt, ferpleatst it IP nei br0 en elke firewallregel dy't eth0 neamt, stopet mei matsen, dus bûn tsjinsten op de brêge en befêstigje mei ip -br addr.

Deselde eigendomsregel ferklearret in ferrassing dy't by firtuele masines opkomt. In tunniltsjinst dy't yn in gast op itselde LAN draait, hâldt it adres fan 'e gast, dus ferbiningen nei it adres fan 'e host sels bliuwe op 'e host en de tunnel fan 'e gast sjocht se nea, wat it kliïntprofyl ek seit.

Rûte tusken de twa LAN's of NAT ien kant

Twa LAN's dy't inoar net sjogge kinne elk de publike host opskilje, dy't dan tusken de tunnels trochstjoert. Dat routearre ûntwerp freget trije dingen: trochstjoeren oan, in rûte nei elk ôfstânsprefiks en in trochstjoerbelied dat it transit trochlitte. sysctl -w net.ipv4.ip_forward=1 dekt it earste, ip route add 10.20.0.0/24 dev wg1 it twadde, en in nftables-rigel lykas nft add rule inet filter forward iifname "wg0" oifname "wg1" accept it tredde.

Boarne-NAT is makliker oan te setten en hurder om te debuggen. Masquerading skriuwt it adres fan 'e kliïnt oer, dus de fiere kant sjocht de hub ynstee fan de echte host, en syn tagongsregels en logboeken wurde nutteloas foar taskriuwung. As beide netwurken fan jo binne, routearje. As ien kant fan in tredde partij is dy't gjin weromrûte tafoegje sil, is NAT de opsje dy't dizze wike ferstjoerd wurdt. Skriuw yn alle gefallen it adresplan op, want twa oerlappende /24's kinne troch gjin inkelde konfiguraasje routearre wurde.

Neat oan it tsjinjen as internetútgong foar in laptop behinderet deselde bak om ynkommende tunnels te beëinigjen. Allinnich oerlappende adressen dogge dat, en dêrom is it adresplan it dokumint dat ta docht.

Test de splitsing wylst twa rollen stille binne

De nuttige test is ôflûken: stopje twa rollen en befêstigje dat de tredde noch antwurdet. In webfersyk heart te foltôgjen as de tunniltsjinst del is, en in tunnelhandshake heart te foltôgjen as de webserver stoppe is. As beide allinnich wurkje as alles draait, hawwe jo in tafallige ôfhinklikens, lykas in dielde firewaltabel, in fertoarne rûte of in namme dy't nei it ferkearde adres wiist.

Trije kommando's meitsje dy test konkreet. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ bewiist dat de lokale harker antwurdet sûnder eksterne DNS, wg show op 'e kliïnt bewiist dat de handshake foltôge is, en tcpdump -ni any port 51820 op 'e hub skiedt in routearprobleem fan in kaaiprobleem. In handshake dy't nea yn 'e opname ferskynt, stoar foar de host: firewall fan 'e provider, ferkeard publike adres of in NAT-regel ûnderweis.

Werhelje it ôflûken foar de trochstjoerde LAN's. Mei ien peer ôfkeppele heart in ping oer de hub te mislearjen; mei dy wer ferbûn heart de ping te herstellen sûnder in regel oan te reitsjen. In ping dy't pas nei it opnij starten fan 'e tunnel herstelt, wiist op belied ynstee fan berikberens, en dat is in oare oplossing.

Hâld de regelset lêsber wylst jo rollen ôflûke. nft list ruleset heart ien accept-regel per rjochting te toanen dy't jo echt nedich hawwe, en in trochstjoerketen dy't alles akseptearret is gjin skieding, it is in wurkjende demo.

Allinnich IPv6-tagongslinen en IPv4-tsjinsten

Guon tagongslinen jouwe allinnich IPv6-berikberens, en tsjinsten moatte noch hieltyd oer IPv4 publisearre wurde. De tunnel sels giet oer de famylje dy't noch ferkear trochlitte, wylst de publisearre tsjinst op in adres binnen de tunnel sit. Dat keart de gewoane oanname om en brekt stilswijend it tafersjoch: in firewallregel of uptime-kontrôle skreaun foar it IPv4-paad bewekket no in ynterface dat neat draacht.

Test elke famylje apart mei curl -4 en curl -6, want ien suksesfol fersyk seit neat oer it paad dat jo net besocht hawwe. Poarteeigendom feroaret net tusken famyljes, mar de harker wol: ss -lntup listet IPv4- en IPv6-sockets as aparte rigen, en 0.0.0.0:443 dekt [::]:443 net, útsein as it proses in dual-stack-socket frege hat.

In tsjinst dy't op ien famylje antwurdet en op 'e oare wegeret, is meastentiids in harkerprobleem, net in routearprobleem. Befêstigje foar't jo it ûntwerp klear neame dat elke rol syn eigen adres of poarte hat, dat trochstjoeren oan en tastien is, en dat elke rol noch antwurdet mei de oare twa stille.