Wêrom in VPN-klient op it kantoar-LAN elk antwurd ferliest

In laptop sit oer Ethernet op it /24 fan it kantoar en meldt him ek oan by in OpenVPN-tsjinner dy't yn itselde /24 wennet. In kollega pinget it tunneladres; it fersyk komt dúdlik oan, en der giet neat werom. It tunnelogboek is skjin en it browsen wurket noch, dus de tunnel is de ferkearde fertochte. IPv4-boarnefalidaasje op de masine dy't ûntfangt smyt it pakket fuort foardat eat it lêst.

De útsmiterij bart foardat eat it pakket lêst

Boarnefalidaasje stelt ien fraach oer elk ynkommend pakket: as dizze host dy boarne antwurde, soe it antwurd dan fuortgean troch de ynterface dêr't it pakket krekt oan kaam? As it antwurd nee is, smyt de kearn it pakket daliks fuort. Net in socket en net in trochstjoerpaad sjocht it ea, en dêrom registrearret in opname op de tunnel noch altyd in fersyk dat de applikaasje nea ûntfangt.

De klient hjir hat 10.66.0.9 op syn tunnel, en de OpenVPN-tsjinner antwurdet op 192.168.80.10 binnen it kantoarprefiks. In kollega op 192.168.80.25 pinget it tunneladres, dus it fersyk stekt it LAN oer, de tsjinner rûtelet it de tunnel yn, en it komt oan op de tunnelinterface fan de klient mei in kantoarboarneaadres. Yn ’e rûtetabel fan dy masine heart it kantoarprefiks by it Ethernet-apparaat, net by de tunnel. De falidaasje fergeliket de oankomstinterface mei de rûte, fynt in misferhâlding en smyt it pakket fuort, dus de kollega sjocht folslein ferlies wylst beide einen in sûne tunnel melde.

De spegelrjochting hat deselde foarm: as de klient nei it kantoar begjint, kinne antwurden oan de kantoarkant om deselde reden fuortsmiten wurde. In reparaasje dy't mar yn ien rjochting ferifiearre is, komt ornaris werom as in twadde kaartsje.

Bewiis de jildende modus foardat jo in sysctl oanreitsje

Lês de effektive wearden ynstee fan in distribúsje-standert te fertrouwen, want de ynstelling per ynterface is mar de helte fan ’e beslissing. De jildende modus is de hegere fan ’e ynterfacewearde en de wearde fan all, dus in nul op ’e tunnelinterface betsjut neat salang’t all ien is. De beslissing fan ’e strange modus is in rûtbebeslissing, dus fier de syktocht út dy't de kearn útfiert en fergelik it antwurd mei de ynterface dêr't it pakket wier oan kaam.

tcpdump -ni tun0 icmp and host 192.168.80.25
ip route get 192.168.80.25
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.tun0.rp_filter

Werhelje dan de ping wylst jo de flochteller besjen. In oantal dat omheech giet njonken in fersyk dat de opname al sjen lit, is de sinjatuer fan dizze útsmiterij, net fan in ûntbrekkende rûte. Skeakel marsiaanske logging yn wylst jo der binne, sadat de kearn de boarne en de ynterface neamt dy't er wegere. Tegearre slute se de sfir, de firewall en in ûntbrekkende iroute as ferklearrings út.

Skriuw de basisline del foardat jo eat feroarje: beide wearden, it apparaat dat de syktocht keas, en de teller dy't jo folgen. Dat ferslach is wat jo letter fertelt oft de feroaring die wat jo tinke.

Wat elk rp_filter-modus wier akseptearret

De kearn lit trije wearden per ynterface sjen, en it binne net trije skaaimerken fan ien regel. Nul skeakelet de kontrôle út. Ien is strang en easket dat de boarne werom rûtelet wurdt troch de oankomstinterface. Twa is los en easket allinnich dat der in rûte nei de boarne yn ’e tabel stiet, wêr't dy ek hinne wiist.

De rige dy't hjir ta docht is de losse, en wat dy noch wegere. In ferfalske boarne dy't oeral yn jo tabel rûtele wurde kin, giet troch, wylst in boarne sûnder hokker rûte dan ek noch wegere wurdt. Op in laptop is dat in smelle konsesje; op in router dy't ferkear foar oare minsken trochstjoert is it in brede. De modus heart by de host, dus itselde getal draacht ferskillend gewicht op ’e twa plakken.

Hokker rige dizze topology nedich hat, folget út ’e tabel en net út ’e gewoante. It pakket is legitym en syn boarne is rûtele, dus de losse akseptearret it en de strange net. Neat yn ’e saak freget om nul, en nul kieze soe in kontrôle fuortsmite dy't hjir neat kostet.

Kies de lytste feroaring dy't de dûbelsinnigens fuorthellet

De losse modus is de lytste feroaring dy't past, en it is in echte ferleging fan strangens, net in ûnskuldige skeakel. In bettere opsje bestiet wannear't de topology it talit: helje de oerlaap fuort, en de dûbelsinnigens ferdwynt.

Dêr't it kantoarprefiks allinnich oer Ethernet nedich is, helje it fuort út ’e rûtes dy't it profyl lûkt, en it adres wurdt fia ien paad berikber. As beide paden wier njonkeninoar bestean moatte, pin dan de boarne en it apparaat fêst mei in beliedsregel ynstee fan falidaasje op elk ynterface losser te meitsjen. Dat hâldt strange filtering foar al it oare op ’e masine en dokumintearret de útsûndering dêr't de folgjende yngenieur it sykje sil.

Hokker paad jo ek kieze, skriuw it yn in sysctl-drop-in del en net yn in libbene opdracht. Set de kaaiien all en default tegearre, sadat in werferbining de strange modus net stil weromsette kin.

# /etc/sysctl.d/99-rp-filter.conf
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2
sysctl --system

Wat de losse modus priisjout, en wêr

De losse modus wegere noch altyd in boarne dy't gjin rûte berikke koe, en hy hâldt op mei it wegerjen fan in ferfalske boarne dy't tafallich rûtele is. Op in laptop is dat in smelle konsesje. Op in apparaat dat ferkear trochstjoert dat it net besit, is deselde kar in folle bredere. Deselde ynstelling draacht dêrom twa hiel ferskillende betsjuttings, ôfhinklik fan wêr't er rint.

De kontrôle folslein útskeakelje op in host dy't ferkear foar oare minsken trochstjoert, is de iene reparaasje dy't jo mije moatte. Nul smyt de falidaasje fuort dy't de losse modus soarchfâldich hâldt. As de host foar oaren trochstjoert, pleitsje dan foar de beliedsregelopsje út ’e foarige paragraaf.

Lit in notysje efter dy't de twa ynterfaces, it oerlaapjende prefiks en de krekte test neamt dy't no slagget. Dat is foar de folgjende yngenieur nuttiger as in rigel dy't seit dat de filtering oanpast is.