Jak teď VPSFree migruje IPv4 adresy do AS24971, tak v průběhu migrace si musím nechat obě IPv4 adresy: Jakmile změním A záznam v DNS, musí mi služby běžet na nové adrese. Zároveň je ještě porůznu nakešovaná stará adresa, takže tam ty služby musí běžet také.
Sice můžu přidat druhou IPv4 adresu ve VPSAdminu, ale jak potom funguje směrování odchozího provozu?
Na Debianu vidím tohle:
root@bee:~# ip -4 a show dev venet0
6: venet0@if659: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link-netnsid 0
inet 77.93.223.253/32 brd 77.93.223.253 scope global venet0
valid_lft forever preferred_lft forever
inet 37.205.15.56/32 scope global venet0
valid_lft forever preferred_lft forever
root@bee:~# ip ro
default via 255.255.255.254 dev venet0
255.255.255.254 dev venet0 scope link
Ale která IPv4 adresa se teda použije pro odchozí provoz? Jestli to dobře chápu, mělo by se to dát nějak nastavit v /etc/network/interfaces.d. Řešil už někdo, jak na to?
díky za upřesnění. Při pohledu do RIPE ještě nechápu roli AS198167 (AppToCloud), ale to do téhle diskuse nepatří.
Děkuji za odpověď. Akorát ip route add nefunguje (RTNETLINK answers: File exists). To je logické, protože výchozí směrování už mám automaticky přidané od VPSAdminu. Funguje tohle:
ip -4 route change default via 255.255.255.254 src 77.93.223.253
Ale z nějakého důvodu mi to nefunguje, když to přidám do skriptu pod /etc/network/interfaces.d. Hm.
pomohlo by přidat konfiguraci sítě i skriptu z /etc/network/interfaces.d.
jinak pokud to je shell skript tak se ujisti, že je spustitelný chmod +x skript.sh
nebo tipuju nějakou chybku v konfiguraci.
Já nevím, už jsem to zase smazal, ale ta vygenerovaná konfigurace od VPSAdminu v /etc/network/interfaces je:
# Autogenerated configuration
auto lo
iface lo inet loopback
auto venet0
iface venet0 inet static
address 77.93.223.253
netmask 255.255.255.255
up ip -4 addr add 37.205.15.56/32 dev venet0
down ip -4 addr del 37.205.15.56/32 dev venet0
up ip -4 route add 255.255.255.254 dev venet0
up ip -4 route add default via 255.255.255.254 dev venet0
iface venet0 inet6 static
address 2a03:3b40:fe:2d4::1
netmask 64
up echo 0 > /proc/sys/net/ipv6/conf/venet0/accept_dad
up ip -6 route add fe80::fc08:82ff:fe2e:c941 dev venet0
up ip -6 route add default via fe80::fc08:82ff:fe2e:c941 dev venet0
Ideálně bych to chtěl nějak upravit, aby tam místo téhle řádky:
up ip -4 route add default via 255.255.255.254 dev venet0
byla tohle (s první nebo druhou IP adresou, podle fáze migrace):
up ip -4 route add default via 255.255.255.254 dev venet0 src 37.205.15.56
To ale neumím, protože ten skript je vygenerovaný a pokud vidím, ifupdown neumí konfigurační direktivy vymazat nebo přebít, jenom přidat další.
Nejspíš se na to vykašlu, na dobu migrace si to přepíšu ručně, použiju radu z komentáře v tom vygenerovaném souboru (chmod u-w /etc/network/interfaces) a až uplyne TTL DNS záznamu s původní IP adresou, tak zase chmod u+w /etc/network/interfaces. Do té doby se nebudu snažit konfiguraci sítě změnit přes VPSAdmin. Jako řešení dobrý, ne?
Nebo můžeš přes vpsAdmin vyměnit pořadí těch adres. Odebereš tu 77.93.223.253 z Interface addresses a pak ji tam zase přidáš, tím se dostane ta druhá adresa na první místo a použije se jako odchozí.
Historicky ma cca 700 lidi pridelene /128 IPv6 adresy z rozsahu Master Internet a asi 350 lidi ma z jejich rozsahu IPv4 adresu; chceme prejit pod svoje ASN s vlastni reputaci (hlavne kvuli spamu), proto ty adresy musime ponahrazovat za jine. Kazdy, koho se to tyka, dostal mail rozeslany pres vpsAdmin, takze jestli Ti nic neprislo, jsi v suchu Na blog jsme se potom chteli pochlubit, az budou meritelny vysledky, mozna jsme preci jen neco mohli postnout pred spustenim ty vymeny, to je pravda…
Na blog jsme se potom chteli pochlubit, az budou meritelny vysledky
Tak první měřitelné výsledky moc přesvědčivě nevypadají:
<ebiederm@xmission.com>: host mx.xmission.com[166.70.12.20] said:
550-XM-RJCT22: [37.205.15.56] is prohibited from connecting to XMission
mail 550-servers due to high spam volume. See the following for more
information: 550
http://postmaster.xmission.com/senders/rbls.php?check_rbl=Submit&address=37.205.15.56
(in reply to RCPT TO command)
Pro srovnání, přeposláno z původní IP adresy (77.93.223.253):
Mar 1 13:41:02 bee postfix/smtp[35431]: 06B301C183E: to=<ebiederm@xmission.com>, relay=mx.xmission.com[166.70.12.20]:25, delay=19, delays=0.08/0.03/12/7, dsn=2.0.0, status=sent (250 OK id=1rg2CC-00FRg2-VP)
A jinak rec byla o reputaci celeho ASN, ne konkretnich IP adres. Docela by mne zajimalo, co je tenhle list zac, protoze ty IP adresy do ted nikdo nepouzival, od doby co je mame assigned od RIPE…
na tom linku se da kliknout na Remove, ale to vyrazi chybu ERROR: Couldn't find IP address in RBL! … coz souhlasi, protoze fakt neni duvod, aby nikdy nepouzivane adresy byly na nejakem listu :))
Ale ne. Já jsem si samozřejmě o delistaci rovnou zažádal, tak už to stihli zpracovat. Nicméně objektivně měřeno mi přechod zatím přináší spíš novou práci. To není obviňování; je mi jasné, že za tohle nemůžeš.
Ten spamlist je asi jen lokální pro schránky na xmission.com. Nemůžu za to, že tam má emailovou schránku Eric W. Biederman, správce subsystému KEXEC v Linuxovém jádře, takže bez něj tam žádný patch nedostanu…
Obecně není moc nosné hledat viníka. Důležité je najít řešení.
