Wêrom't jo iepenbiere Linux-tsjinst ynstee fia de VPN antwurdet

Neat yn 'e socket ûnthâldt hokker ynterface it fersyk brocht hat, dat in foltunnel-VPN-standertrûte kin in antwurd fange dat by de WAN heart. De tsjinst negearret de ynkommende ynterface net; Linux rûtelet in lokaal generearre antwurd op basis fan bestimming en boarnebelied. In boarnderegel kin ynstee allinnich de antwurden fan 'e tsjinst fia in folsleine WAN-tabel stjoere, en de gewoane útgong op 'e tunnel litte. De poarte bliuwt iepen wylst it antwurd fia it ferkearde paad fuortgiet, en dêrom liket it symptoom iensidich.

De misferstân: antwurden folgje de ynterface wêr't se oankamen

It liket logysk dat in pakket dat op eth0 oankomt, op eth0 fuortgiet. Steatleaze pakketfilters kinne sa skreaun wurde, en tcpdump oan 'e ynkommende kant lit it fersyk krekt sjen wêr't it ferwachte wurdt. Routing wurket net sa foar ferkear dat de host sels makket.

Sadree't de tsjinst de ferbining akseptearret, is har antwurd in nij lokaal generearre pakket. De kernel rieplachtet de routingregels foar de bestimming en boarne fan it antwurd, en de standertrûte fan 'e VPN is in folslein jildich antwurd. Neat yn 'e socket ûnthâldt hokker ynterface it fersyk brocht hat.

Dêrom liket it symptoom iensidich: fersiken komme oan, antwurden ferdwine. Dêrom feroaret in firewallregel foar de ynkommende poarte ek neat. It pakket wurdt net blokkearre op 'e wei nei binnen; it wurdt op 'e wei nei bûten earne oars hinne rûtele. Folgje it antwurd mei in boarne-kwalifisearre syktocht en de omwei wurdt sichtber.

Wat de kernel eins rûtelet: it boarneadres

It hânsel dat jo nedich hawwe is it lokale adres dat de tsjinst foar antwurden brûkt. Op in host mei it yllustrative eth0-adres 192.0.2.10/24 en de gateway 192.0.2.1 is dat adres op 'e ynterface oanwêzich. Op in cloud-VM kin it iepenbiere adres streamop oerset wurde en yn 'e gast ûntbrekke, dus brûk it adres dat de host echt hat.

Undersykje de hjoeddeiske steat foardat jo in tabelnûmer of regelprioriteit reservearje. Besteande beliedsregels kinne in nije oerskade, en in âlde tabel mei itselde nûmer kin al ûnbesibbe rûtes drage:

ip -4 addr show dev eth0
ip -4 rule show
ip -4 route show table all

Kies dan in tabel op basis fan 'e boarne. De regel past by antwurden dy't al 192.0.2.10 drage, krekt it lokaal beëinige ferkear dat jo frijstelle wolle. Trochstjoerd ferkear en pakketten fan oare lokale adressen passe net.

Bou in folsleine weromtabel, net in heal standert

In tabel mei allinnich in standertrûte is net genôch. De kernel moat noch de gateway oplosse, en dy oplossing hat it ferbûne prefiks yn deselde tabel nedich. In tabel dy't dat prefiks mist, mislearret by gateway-oplossing sels as syn standertrûte korrekt liket. Foegje beide ta en rjochtsje dan de boarneregel nei de tabel:

ip -4 route add table 100 192.0.2.0/24 dev eth0 src 192.0.2.10
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 from 192.0.2.10/32 lookup 100

Brûk it echte prefiks en de echte gateway ynstee fan it foarbyld te kopiearjen. In cloud-ynterface konfigurearre as /32 mei in on-link-gateway hat in oare ferbûne rûte nedich, en in tabel boud fan it ferkearde prefiks mislearret by de earste hop. It attribút src neamt de foarkarsboarne foar dy rûte; it ferfangt de boarneregel net.

De folchoarder is ek wichtich. In brede regel mei in leger prioriteitsnûmer wurdt earst beoardiele, dus de boarneregel moat berikt wurde foar elke regel dy't dit ferkear werom nei de haadtabel stjoere soe. Kontrolearje de prioriteiten mei ip rule show nei it tafoegjen, net allinnich by it opstarten.

Ferifiearje mei in boarne-kwalifisearre syktocht

Freegje de kernel om in testbestimming fan it tsjinstadres te rûteljen. It antwurd moat eth0 en de WAN-gateway neame, net de tunnel:

ip -4 route get 198.51.100.25 from 192.0.2.10

Meitsje dan in nije autorisearre ferbining en observearje beide rjochtingen. In syktocht dy't de juste tabel kiest wylst de libbene ferbining noch mislearret, wiist op omkearde-paad-filtering of in firewallregel, net op 'e tabel. Kontrolearje dy kontrôles foardat jo eat globaal útsette.

Pleatstje de definitive rûtes en de regel ûnder de netwurkbehearder dy't de ynterface besit. Adresferoarings, DHCP-ferfanging en VPN-werferbiningen skriuwe allegear de kernelsteat opnij, en in regel dy't mei de hân tafoege is ferdwynt of wiist nei in efterhelle gateway nei it folgjende barren.

Wêr't dizze útsûndering ophâldt

De regel frijstelt lokaal beëinige ferkear fan ien boarneadres. It dekt gjin troch Docker publisearre poarten, DNAT of tsjinsten dy't troch de host trochstjoerd wurde, om't dy pakketten as trochstjoerd ferkear rûtele wurde en nea it lokale boarne fan 'e host op deselde manier drage. Sokke ûntwerpen hawwe meastentiids in mark nedich dy't by de yngong set wurdt en in regel dy't by de mark past.

It makket ek net dat it iepenbiere adres fan 'e host op 'e ynterface ferskynt. As in streamop-NAT dat adres besit, moat it antwurd noch hieltiten fia it paad fuortgean dat dy NAT ferwachtet, en dêrom moat de WAN-tabel de oarspronklike gateway en it prefiks wjerspegelje ynstee fan in rieden iepenbier berik.

Hâld de útsûndering dokumintearre mei har tabelnûmer, regelprioriteit en it krekte boarneadres. De folgjende feroaring oan 'e VPN of de ynterface kin it stil brekke, en in notysje dy't de trije wearden neamt is flugger te kontrolearjen as it symptoom opnij te ûntdekken út in klantrapport.

As de tsjinst noch hieltiten op it ferkearde paad antwurdet nei't de boarne-kwalifisearre syktocht slagge is, fergelykje dan it boarneadres fan 'e libbene socket mei dat yn 'e regel. In tsjinst bûn oan in wildcard-adres kin in oare boarne kieze as it adres dat jo testen, en dy ôfwiking is de oerbleaune kleau.