Stjoer mar ien pleatslike websjinst bûten de VPN om, op basis fan 'e poarte

Ien host-tsjinst moat it ynternet oer de fysike opgeande keppeling beantwurdzje wylst al it oare op 'e masjine de tunnel bliuwt brûken. Trije betingsten beslisse oft op belied basearre routing dy lêst drage kin, en elk is goedkeap te kontrolearjen foardat jo in regel skriuwe. De tsjinst moat op dizze host einigje en net efter in DNAT of in trochstjoerde poarte, de eigen regels fan 'e VPN moatte de útsûndering tastean, en jo moatte it antwurd oerienkomme litte ynstee fan it fersyk. Mislukt ien fan 'e trije, dan lade de opdrachten hjirûnder sûnder flaters wylst se neat nuttichs dogge.

Kontrolearje de trije betingsten foardat jo in regel skriuwe

In container dy’t in poarte fia DNAT publisearret, of in tsjinner efter in poartetrochstjoering, produsearret pakketten dy’t net op dizze host ûntsteane. Dy pakketten wurde trochstjoerd, dus in regel dy’t op host-lokale ynfier basearre is, sjocht se nea en it ferkear bliuwt de standertrûte nimmen. Befêstigje wêr't de tsjinst eins draait foardat jo trochgeane, want dat is de betingst dy't minsken it meast ferkeard krije.

De twadde betingst is belied en net meganika. Elke rûte dy't de tunnel omgiet is in útsûndering op it doel fan 'e tunnel, en op in beheard host heart dy beslissing ta wa't it belied besit, net oan 'e persoan dy't in time-out debugt.

Kombinearje it antwurd, net de bestimmingspoarte fan 'e klant

In antwurd fan in tsjinner dy't op TCP 443 harket, ferlit de host mei boarnepoarte 443. In browser op deselde host dy't ferbynt mei in fiere HTTPS-side stjoert in efemere boarnepoarte en bestimmingspoarte 443. Beide binne poarte-443-ferkear en mar ien fan beide soe de WAN-tabel nimme, dêrom soe in oerienkomst op bestimmingspoarte de ferkearde helte gripe.

De antwurd-rjochting is wat jo ûnderskiede kinne. Kombinearje de boarnepoarte, behein de regel ta lokaal oanmakke pakketten, en de regel dekt de eigen antwurden fan 'e tsjinst sûnder de fersiken fan 'e browser oan te reitsjen.

Bou in folsleine retourtabel foardat de regel dernei wiist

In lege tabel betsjut gjin rûte, wat der as in stikken tsjinst útsjocht ynstee fan in stikken belied. Folje it earst, mei in tabelnûmer en prioriteit dy't neat oars op 'e host opeasket:

ip -4 route add table 100 192.0.2.0/24 dev eth0
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 iif lo ipproto tcp sport 443 lookup 100

Lês de nûmers fan 'e libbene host ôf ynstee fan se te kopiearjen. ip -4 rule show fertelt jo hokker prioriteiten nommen binne, en in regel tafoegje op in prioriteit dy't al bestiet feroaret stil de folchoarder fan twa regels dy't los fan elkoar goed lykje.

Twa selekteurs dogge hjir it echte wurk. iif lo is hoe't de kearn pakketten rapportearret dy't de host sels makke hat, sadat de regel net by ûngelok trochstjoerd ferkear fan bûten pakke kin. ipproto tcp sport 443 ferneaut it ta ien transport en ien poarte, wat sa strak is as de eask tastiet. Lit de protokolselekteur weilitte, dan pakt de regel ek UDP 443, dat in oare tsjinst mei oar gedrach is.

Hâld privee-antwurden binnen de tunnel

As deselde listener ek klanten oan 'e priveekant beantwurdet, sil in WAN-standertrûte dy't alles pakt yn tabel 100 besykje dy antwurden oer de opgeande keppeling werom te stjoeren. Foegje de privee-prefiksen ta dy't de WAN-standert net folgje moatte, of lit se trochfalle nei de folgjende beliedsregel:

ip -4 route add table 100 throw 10.90.0.0/24

In throw-rûte einiget it sykjen yn dizze tabel en jout it pakket werom oan 'e regellist, sadat it VPN-belied dat folget syn kâns krijt. It rûtet sels neat de tunnel yn, en as gjin lettere regel in passende rûte hat, mislearret it pakket dochs; ferifiearje it folgjende belied ynstee fan oan te nimmen dat throw in oplossing is.

Filtering fan 'e omkearde paad en brânmuorre-regels fan 'e host jilde noch foar it oankommende fersyk. Sjoch nei har echte útspraken foardat jo de falidaasje fersoepje, want in routing-útsûndering makket net dat rp_filter in werompaad akseptearret dat it ûnmooglik achtet.

Test TCP, dan QUIC, dan in reboot

Iepenje ien ferbining fan in autorisearre eksterne klant en ien fan 'e priveekant, en besjoch dan it antwurd-sykjen mei de echte adressen en poarten. As it eksterne antwurd tabel 100 nimt en it privee-antwurd net, docht it belied wat jo fregen.

HTTP/3 wurdt oer UDP tsjinne en sil net troch in TCP-regel oerienkomme, dus in QUIC-listener hat syn eigen selekteur nedich, oars bliuwt er de tunnel brûken wylst HTTPS wurket. Bewarje hokker regels jo ek fêstlizze by de komponint dy't de interface besit, en befêstigje se nei in ferbining wer of in DHCP-fernieuwing. As in konkurrearjende behearder nei in reboot in runtime-rûte fuorthellet, is dat in eigendom-probleem dat by de boarne oplost wurde moat, net in reden om bredere NAT-regels derop te setten.